Mon blog

Le protocole TCP a une option nommée MSS (Maximum Segment Size, RFC 793, section 3.1) qui indique la taille maximale des segments (les paquets, au niveau TCP) qu'on peut recevoir. Quelle valeur y indiquer ? Faut-il tenir compte des options IP et TCP, dont la taille est variable ? Ce RFC a depuis été intégré dans la norme TCP, le RFC 9293.

Le RFC 879 semblait répondre clairement : on ne compte que le segment lui-même, pas les en-têtes IP ou TCP. Mais le reste du RFC 879 détaillait des exemples qui ne correspondaient pas à cette règle. Donc le RFC 1122 (section 4.2.2.6 et l'annexe A de notre RFC, pour l'historique) revenait là-dessus. En effet, les options IP et TCP sont de taille variable et peuvent changer pendant une connexion TCP. La MSS ne sera alors pas optimum. La MSS ne pouvant pas facilement changer en cours de connexion (elle est normalement envoyée avec le paquet SYN), il était nécessaire d'avoir une meilleure règle pour sa détermination. Cela n'a pas empêché des RFC ultérieurs comme le RFC 2385 de se prendre les pieds dans le tapis et de formuler les règles incorrectes pour la prise en compte des options variables (option d'authentification, dans le cas du RFC 2385).

Notre RFC 6691 réécrit donc la règle. La nouvelle (section 2) est « La MSS devrait être la MTU moins les en-têtes fixes d'IP et de TCP, sans les options de taille variable ». Notez le « fixes ». Si l'envoyeur des données met des options IP ou TCP, il doit donc diminuer la taille des données TCP, afin de respecter la MSS. Le but est d'éviter la fragmentation IP. Autrement, en-têtes fixes + options variables + MSS pouvaient dépasser la MTU, menant à la fragmentation.

L'en-tête fixe fait 20 octets en IPv4 et 40 en IPv6. L'en-tête TCP fixe est de 20 octets. Si la MTU est de 1500 octets (celle d'Ethernet), cela donnera une MSS de 1460 octets en IPv4 et 1440 en IPv6. Comme indiqué plus haut, si on rajoute des options IP (augmentant ainsi la taille de l'en-tête), on ne pourra pas envoyer 1460 (ou 1440) octets en TCP, il faudra se serrer (diminuer le nombre d'octets envoyés). C'est le comportement actuel de toutes les mises en œuvre de TCP, désormais officiellement documenté.

La règle est simple et bien exprimée. Le reste du RFC est consacrée à la justifier.

Pour résumer (section 4), il y a quatre choix possibles lorsque des options variables sont ajoutées à un paquet (comme l'option d'authentification du RFC 2385) :

• L'expéditeur des paquets a réduit le nombre d'octets pour faire de la place et la MSS transmise par son pair tenait déjà compte des options : le paquet sera trop court et n'utilisera donc pas le réseau de manière optimum.
• L'expéditeur des paquets a réduit le nombre d'octets pour faire de la place et la MSS transmise par son pair ne tenait pas compte des options (la règle recommandée par notre RFC) : le paquet est de la bonne taille.
• L'expéditeur des paquets n'a pas réduit le nombre d'octets pour faire de la place mais la MSS transmise par son pair tenait déjà compte des options : le paquet sera de la bonne taille.
• L'expéditeur des paquets n'a pas réduit le nombre d'octets pour faire de la place alors que la MSS transmise par son pair ne tenait pas compte des options : le cas le plus ennuyeux car le paquet sera trop long et devra être fragmenté.

Comme celui qui envoie des données ne sait pas si son pair a tenu compte des options ou pas, dans la MSS qu'il a indiquée, la seule solution sûre est donc, si on utilise les options, de décroître la quantité de données envoyées. (Rappelez-vous que seul l'envoyeur des données connait avec certitude les options utilisées. Le récepteur, qui avait indiqué dans l'option MSS la taille qu'il acceptait, ne sait pas s'il y aura des options variables.) Mais, si tout le monde fait cela, ajuster la MSS pour les options ne sert plus à rien. D'où la décision de notre RFC de ne pas tenir compte des options variables dans le calcul de la MSS.

La section 5 décrit d'ailleurs d'autres raisons derrière cette décision comme le fait qu'avec la nouvelle règle, la MSS peut être diminuée par la PMTUD. Par contre, elle ne peut pas être augmentée. Il vaut donc mieux ne pas la mettre trop bas, comme cela arriverait si on essayait de tenir compte des options variables. Elle traite aussi les cas de la compression ROHC (RFC 5795) et des « jumbogrammes » du RFC 2675.