5. Host Processing of Old-Style Messages (Traitement des messages de l'ancien style)
5. Host Processing of Old-Style Messages (Traitement des messages de l'ancien style par l'hôte)
Dans cette section, nous décrivons plusieurs stratégies possibles qu'un hôte peut suivre lors de la réception d'un message Datagram Too Big d'un routeur non modifié (c'est-à-dire un où le champ Next-Hop MTU est à zéro). Cette section ne fait pas partie de la spécification du protocole.
La chose la plus simple qu'un hôte peut faire en réponse à un tel message est de supposer que le PMTU est le minimum de son PMTU actuellement supposé et de 576, et de cesser de définir le bit DF dans les datagrammes envoyés sur ce chemin. Ainsi, l'hôte revient au même PMTU qu'il choisirait sous la pratique actuelle (voir section 3.3.3 de "Requirements for Internet Hosts -- Communication Layers" (Exigences pour les hôtes Internet -- Couches de communication) [1]). Cette stratégie a l'avantage de se terminer rapidement, et ne fait pas pire que la pratique existante. Cependant, elle échoue à éviter la fragmentation dans certains cas, et à faire l'utilisation la plus efficace de l'Internet dans d'autres cas.
Des stratégies plus sophistiquées impliquent de "rechercher" une estimation précise du PMTU, en continuant à envoyer des datagrammes avec le bit DF tout en variant leurs tailles. Une bonne stratégie de recherche est celle qui obtient une estimation précise du Path MTU sans causer la perte de nombreux paquets dans le processus.
Plusieurs stratégies possibles appliquent des fonctions algorithmiques à l'estimation PMTU précédente pour générer une nouvelle estimation. Par exemple, on pourrait multiplier l'ancienne estimation par une constante (disons, 0.75). Nous NE recommandons PAS cela; cela converge soit beaucoup trop lentement, soit sous-estime substantiellement le vrai PMTU.
Une approche plus sophistiquée consiste à effectuer une recherche binaire sur la taille du paquet. Cela converge un peu plus rapidement, bien qu'il faille encore 4 ou 5 étapes pour converger d'un MTU FDDI à un MTU Ethernet. Un inconvénient sérieux est qu'elle nécessite une implémentation complexe afin de reconnaître quand un datagramme a atteint l'autre extrémité (indiquant que l'estimation actuelle est trop basse). Nous ne recommandons pas non plus cette stratégie.
Une stratégie qui semble fonctionner assez bien part de l'observation qu'il existe, en pratique, relativement peu de valeurs MTU utilisées dans l'Internet. Ainsi, plutôt que de rechercher aveuglément à travers des valeurs choisies arbitrairement, nous pouvons rechercher uniquement celles qui sont susceptibles d'apparaître. De plus, étant donné que les concepteurs ont tendance à choisir les MTU de manières similaires, il est possible de collecter des groupes de valeurs MTU similaires et d'utiliser la valeur la plus basse du groupe comme notre "plateau" de recherche. (Il est clairement préférable de sous-estimer un MTU de quelques pour cent que de le surestimer d'un octet.)
Dans la section 7, nous décrivons comment nous sommes arrivés à une table de plateaux MTU représentatifs à utiliser dans l'estimation PMTU. Avec cette table, la convergence est aussi bonne que la recherche binaire dans le pire cas, et est bien meilleure dans les cas courants (par exemple, il ne faut que deux temps d'aller-retour pour passer d'un MTU FDDI à un MTU Ethernet). Étant donné que les plateaux se trouvent près des puissances de deux, si un MTU n'est pas représenté dans cette table, l'algorithme ne le sous-estimera pas de plus d'un facteur 2.
Toute stratégie de recherche doit avoir une certaine "mémoire" des estimations précédentes afin de choisir la suivante. Une approche consiste à utiliser l'estimation actuellement mise en cache du Path MTU, mais en fait il y a de meilleures informations disponibles dans le message Datagram Too Big lui-même. Tous les messages ICMP Destination Unreachable, y compris celui-ci, contiennent l'en-tête IP du datagramme original, qui contient la Total Length (longueur totale) du datagramme qui était trop grand pour être transféré sans fragmentation. Étant donné que cette Total Length peut être inférieure à l'estimation PMTU actuelle, mais est néanmoins supérieure au PMTU réel, elle peut être une bonne entrée pour la méthode de choix de la prochaine estimation PMTU.
Note: les routeurs basés sur des implémentations dérivées de 4.2BSD Unix envoient une valeur incorrecte pour la Total Length du datagramme IP original. La valeur envoyée par ces routeurs est la somme de la Total Length originale et de la Header Length originale (exprimée en octets). Étant donné qu'il est impossible pour l'hôte recevant un tel message Datagram Too Big de savoir s'il a été envoyé par l'un de ces routeurs, l'hôte doit être conservateur et supposer qu'il l'est. Si le champ Total Length retourné n'est pas inférieur à l'estimation PMTU actuelle, il doit être réduit de 4 fois la valeur du champ Header Length retourné.
La stratégie que nous recommandons, alors, est d'utiliser comme prochaine estimation PMTU la plus grande valeur de plateau inférieure au champ Total Length retourné (corrigé, si nécessaire, selon la Note ci-dessus).