6.4 TCP Layer Actions (Actions de la couche TCP)
6.4 TCP Layer Actions (Actions de la couche TCP)
La couche TCP doit suivre le PMTU pour la destination d'une connexion; elle ne devrait pas envoyer de datagrammes plus grands que cela. Une implémentation simple pourrait demander cette valeur à la couche IP (en utilisant l'interface GET_MAXSIZES décrite dans [1]) chaque fois qu'elle crée un nouveau segment, mais cela pourrait être inefficace. De plus, les implémentations TCP qui suivent l'algorithme d'évitement de congestion "slow-start" (démarrage lent) [4] calculent et mettent généralement en cache plusieurs autres valeurs dérivées du PMTU. Il peut être plus simple de recevoir une notification asynchrone lorsque le PMTU change, afin que ces variables puissent être mises à jour.
Une implémentation TCP doit également stocker la valeur MSS reçue de son pair (qui est par défaut 536), et ne pas envoyer de segment plus grand que ce MSS, quel que soit le PMTU. Dans les implémentations dérivées de 4.xBSD, cela nécessite d'ajouter un champ supplémentaire à l'enregistrement d'état TCP.
Enfin, lorsqu'un message Datagram Too Big est reçu, cela implique qu'un datagramme a été abandonné par le routeur qui a envoyé le message ICMP. Il suffit de traiter cela comme n'importe quel autre segment abandonné, et d'attendre que le temporisateur de retransmission expire pour provoquer la retransmission du segment. Si le processus de PMTU Discovery nécessite plusieurs étapes pour estimer le bon PMTU, cela pourrait retarder la connexion de nombreux temps d'aller-retour.
Alternativement, la retransmission pourrait être effectuée en réponse immédiate à une notification que le Path MTU a changé, mais uniquement pour la connexion spécifique spécifiée par le message Datagram Too Big. La taille du datagramme utilisée dans la retransmission ne devrait, bien sûr, pas être plus grande que le nouveau PMTU.
Note: On NE DOIT PAS retransmettre en réponse à chaque message Datagram Too Big, puisqu'une rafale de plusieurs segments surdimensionnés donnera lieu à plusieurs tels messages et donc plusieurs retransmissions des mêmes données. Si le nouveau PMTU estimé est toujours incorrect, le processus se répète, et il y a une croissance exponentielle du nombre de segments superflus envoyés!
Cela signifie que la couche TCP doit être capable de reconnaître quand une notification Datagram Too Big diminue réellement le PMTU qu'elle a déjà utilisé pour envoyer un datagramme sur la connexion donnée, et devrait ignorer toutes les autres notifications.
Les implémentations TCP modernes incorporent des algorithmes "congestion avoidance" (évitement de congestion) et "slow-start" (démarrage lent) pour améliorer les performances [4]. Contrairement à une retransmission causée par un délai de retransmission TCP, une retransmission causée par un message Datagram Too Big ne devrait pas changer la fenêtre de congestion. Cependant, elle devrait déclencher le mécanisme de démarrage lent (c'est-à-dire, un seul segment devrait être retransmis jusqu'à ce que les accusés de réception commencent à arriver à nouveau).
Les performances TCP peuvent être réduites si la taille maximale de fenêtre de l'émetteur n'est pas un multiple exact de la taille de segment en cours d'utilisation (ce n'est pas la taille de fenêtre de congestion, qui est toujours un multiple de la taille de segment). Dans de nombreux systèmes (tels que ceux dérivés de 4.2BSD), la taille de segment est souvent réglée à 1024 octets, et la taille maximale de fenêtre (le "send space" (espace d'envoi)) est généralement un multiple de 1024 octets, donc la relation appropriée est maintenue par défaut. Si PMTU Discovery est utilisé, cependant, la taille de segment peut ne pas être un sous-multiple de l'espace d'envoi, et elle peut changer pendant une connexion; cela signifie que la couche TCP peut avoir besoin de changer la taille de fenêtre de transmission lorsque PMTU Discovery change la valeur PMTU. La taille maximale de fenêtre devrait être réglée au plus grand multiple de la taille de segment (PMTU - 40) qui est inférieur ou égal à la taille de l'espace tampon de l'émetteur.
PMTU Discovery n'affecte pas la valeur envoyée dans l'option TCP MSS, car cette valeur est utilisée par l'autre extrémité de la connexion, qui peut utiliser une valeur PMTU non liée.