7. La méthode de sondage

Cette section décrit les détails de la méthode de sondage MTU, y compris comment envoyer des sondes et traiter les indications d'erreur nécessaires pour rechercher le MTU de chemin.

7.1. Plages de taille de paquets

Ce document décrit la méthode de sondage utilisant trois variables d'état:

search_low: La plus petite taille de sonde utile, moins un. Le réseau est censé pouvoir délivrer des paquets de taille search_low.

search_high: La plus grande taille de sonde utile. Les paquets de taille search_high sont censés être trop grands pour que le réseau puisse les délivrer.

eff_pmtu: Le PMTU effectif pour ce flux. C'est le plus grand paquet non-sonde permis par PLPMTUD pour le chemin.

search_low          eff_pmtu         search_high
    |                   |                  |
...------------------------>
plage de taille non-sonde
    <-------------------------------------->
                plage de taille de sonde

Lors de la transmission de non-sondes, la couche de paquetisation DEVRAIT (SHOULD) créer des paquets d'une taille inférieure ou égale à eff_pmtu.

Lors de la transmission de sondes, la couche de paquetisation DOIT (MUST) sélectionner une taille de sonde plus grande que search_low et inférieure ou égale à search_high.

Lors du sondage vers le haut, eff_pmtu égale toujours search_low. Dans d'autres états, tels que les conditions initiales, après le traitement des messages ICMP PTB ou suite à PLPMTUD sur un autre flux partageant la même représentation de chemin, eff_pmtu peut être différent de search_low. Normalement, eff_pmtu sera supérieur ou égal à search_low et inférieur à search_high. Il est généralement attendu mais non requis que la taille de sonde soit supérieure à eff_pmtu.

Pour les conditions initiales lorsqu'il n'y a pas d'information sur le chemin, eff_pmtu peut être supérieur à search_low. La valeur initiale de search_low DEVRAIT (SHOULD) être conservativement basse, mais les performances peuvent être meilleures si eff_pmtu commence à une valeur plus élevée, moins conservatrice. Voir Section 7.2.

Si eff_pmtu est plus grand que search_low, il est explicitement permis d'envoyer des paquets non-sondes plus grands que search_low. Lorsqu'un tel paquet est acquitté, c'est effectivement une "sonde implicite" et search_low DEVRAIT (SHOULD) être élevé à la taille du paquet acquitté. Cependant, si une "sonde implicite" est perdue, elle NE DOIT PAS (MUST NOT) être traitée comme un échec de sonde comme le serait une vraie sonde. Si eff_pmtu est trop grand, cette condition ne sera détectée qu'avec des messages ICMP PTB ou la découverte de trou noir (voir Section 7.7).

7.2. Sélection des valeurs initiales

La valeur initiale pour search_high DEVRAIT (SHOULD) être le plus grand paquet possible pouvant être supporté par le flux. Cela peut être limité par le MTU de l'interface locale, par un mécanisme de protocole explicite tel que l'option TCP MSS, ou par une limite intrinsèque telle que la taille d'un champ de longueur de protocole. De plus, la valeur initiale pour search_high PEUT (MAY) être limitée par une option de configuration pour empêcher le sondage au-dessus d'une certaine taille maximale. Search_high est susceptible d'être le même que le MTU de chemin initial tel que calculé par l'algorithme classique de découverte du MTU de chemin.

Il est RECOMMANDÉ (RECOMMENDED) que search_low soit initialement défini sur une taille MTU susceptible de fonctionner sur une très large gamme d'environnements. Compte tenu des technologies d'aujourd'hui, une valeur de 1024 octets est probablement suffisamment sûre. La valeur initiale pour search_low DEVRAIT (SHOULD) être configurable.

Un fonctionnement correct de la découverte du MTU de chemin est essentiel au fonctionnement robuste et efficace d'Internet. Tout changement majeur (comme décrit dans ce document) a le potentiel d'être très perturbateur s'il provoque des changements inattendus dans les comportements de protocole. La sélection de la valeur initiale pour eff_pmtu détermine dans quelle mesure le comportement d'une implémentation PLPMTUD ressemble à PMTUD classique dans les cas où la méthode classique est suffisante.

Une configuration conservatrice consisterait à définir eff_pmtu à search_high, et à s'appuyer sur les messages ICMP PTB pour réduire eff_pmtu de manière appropriée. Dans cette configuration, PMTUD classique est pleinement fonctionnel et PLPMTUD n'est invoqué que pour récupérer des trous noirs ICMP par la procédure décrite dans la Section 7.7.

Dans certains cas, où il est connu que PMTUD classique est susceptible d'échouer (par exemple, si les messages ICMP PTB sont administrativement désactivés pour des raisons de sécurité), l'utilisation d'un petit eff_pmtu initial évitera les coûteux timeouts requis pour la détection de trou noir. Le compromis est que l'utilisation d'un eff_pmtu initial plus petit que nécessaire pourrait causer une réduction des performances.

Notez que l'eff_pmtu initial peut être n'importe quelle valeur dans la plage search_low à search_high. Un eff_pmtu initial de 1400 octets pourrait être un bon compromis car il serait sûr pour presque tous les tunnels sur tous les équipements réseau communs, et pourtant proche du MTU optimal pour la majorité des chemins dans Internet aujourd'hui. Cela pourrait être amélioré en utilisant quelques statistiques d'autres flux récents: par exemple, l'eff_pmtu initial pour un flux pourrait être défini à la médiane de la taille de sonde pour toutes les sondes réussies récentes.

Étant donné que le coût de PLPMTUD est dominé par les surcharges spécifiques au protocole de génération et de traitement des sondes, il est probablement souhaitable que chaque protocole ait ses propres heuristiques pour sélectionner l'eff_pmtu initial. Il est particulièrement important que les protocoles sans connexion et d'autres protocoles qui peuvent ne pas recevoir d'indications claires de trous noirs ICMP utilisent des valeurs initiales conservatrices (plus petites) pour eff_pmtu, comme décrit dans la Section 10.3.

Il DEVRAIT (SHOULD) y avoir des options de configuration par protocole et par route pour remplacer les valeurs initiales pour eff_pmtu et d'autres variables d'état PLPMTUD.

7.3. Sélection de la taille de sonde

La sonde peut avoir une taille n'importe où dans la "plage de taille de sonde" décrite ci-dessus. Cependant, plusieurs facteurs affectent la sélection d'une taille appropriée. Une stratégie simple pourrait être de faire une recherche binaire divisant par deux la plage de taille de sonde à chaque sonde. Cependant, pour certains protocoles, tels que TCP, les sondes échouées sont plus coûteuses que celles réussies, car les données dans une sonde échouée devront être retransmises. Pour de tels protocoles, une stratégie qui augmente la taille de sonde par incréments plus petits pourrait avoir une surcharge inférieure. Pour de nombreux protocoles, tant au niveau qu'au-dessus de la couche de paquetisation, le bénéfice de l'augmentation des tailles MTU peut suivre une fonction en escalier de sorte qu'il n'est pas avantageux de sonder dans certaines régions du tout.

Comme optimisation, il peut être approprié de sonder à certaines tailles MTU communes ou attendues, par exemple, 1500 octets pour Ethernet standard, ou 1500 octets moins les tailles d'en-tête pour les protocoles de tunnel.

Certains protocoles peuvent utiliser d'autres mécanismes pour choisir les tailles de sonde. Par exemple, les protocoles qui ont certaines tailles de blocs de données naturelles pourraient simplement assembler des messages à partir d'un nombre de blocs jusqu'à ce que la taille totale soit inférieure à search_high, et si possible supérieure à search_low.

Chaque couche de paquetisation DOIT (MUST) déterminer quand le sondage a convergé, c'est-à-dire quand la plage de taille de sonde est suffisamment petite pour que le sondage supplémentaire ne vaille plus son coût. Lorsque le sondage a convergé, un temporisateur DEVRAIT (SHOULD) être défini. Lorsque le temporisateur expire, search_high devrait être réinitialisé à sa valeur initiale (décrite ci-dessus) afin que le sondage puisse reprendre. Ainsi, si le chemin change, augmentant le MTU de chemin, alors le flux en profitera finalement. La valeur pour ce temporisateur NE DOIT PAS (MUST NOT) être inférieure à 5 minutes et il est recommandé qu'elle soit de 10 minutes, selon RFC 1981.

7.4. Préconditions de sondage

Avant d'envoyer une sonde, le flux DOIT (MUST) remplir au moins les conditions suivantes:

• Il n'a pas de sondes ou de pertes en cours.
• Si la dernière sonde a échoué ou était non concluante, alors le timeout de sonde a expiré (voir Section 7.6.2).
• La fenêtre disponible est supérieure à la taille de sonde.
• Pour un protocole utilisant des données en bande pour le sondage, suffisamment de données sont disponibles pour envoyer la sonde.

De plus, les algorithmes de détection de perte opportune dans la plupart des protocoles ont des pré-conditions qui DEVRAIENT (SHOULD) être satisfaites avant d'envoyer une sonde. Par exemple, TCP Fast Retransmit n'est pas robuste à moins qu'il n'y ait suffisamment de segments suivant une sonde; c'est-à-dire que l'émetteur DEVRAIT (SHOULD) avoir suffisamment de données en file d'attente et une fenêtre de récepteur suffisante pour envoyer la sonde plus au moins Tcprexmtthresh [RFC2760] segments supplémentaires. Cette restriction peut inhiber le sondage dans certains états de protocole, comme trop près de la fin d'une connexion, ou lorsque la fenêtre est trop petite.

Les protocoles PEUVENT (MAY) retarder l'envoi de non-sondes afin d'accumuler suffisamment de données pour satisfaire les pré-conditions de sondage. L'algorithme d'envoi retardé DEVRAIT (SHOULD) utiliser une technique d'auto-échelle pour limiter de manière appropriée le temps pendant lequel les données sont retardées. Par exemple, les ACK retournants peuvent être utilisés pour empêcher la fenêtre de tomber de plus que la quantité de données nécessaires pour la sonde.

7.5. Conduite d'une sonde

Une fois qu'une taille de sonde dans la plage appropriée a été sélectionnée, et que les préconditions ci-dessus ont été remplies, la couche de paquetisation PEUT (MAY) conduire une sonde. Pour ce faire, elle crée un paquet de sonde tel que sa taille, y compris les en-têtes IP les plus externes, soit égale à la taille de sonde. Après avoir envoyé la sonde, elle attend une réponse, qui aura l'un des résultats suivants:

Succès: La sonde est acquittée comme ayant été reçue par l'hôte distant.

Échec: Un mécanisme de protocole indique que la sonde a été perdue, mais aucun paquet dans la fenêtre avant ou arrière n'a été perdu.

Échec de timeout: Un mécanisme de protocole indique que la sonde a été perdue, et aucun paquet dans la fenêtre avant n'a été perdu, mais il est incapable de déterminer si des paquets dans la fenêtre arrière ont été perdus. Par exemple, la perte est détectée par un timeout, et la retransmission go-back-n est utilisée.

Non concluant: La sonde a été perdue en plus d'autres paquets dans les fenêtres avant ou arrière.

7.6. Réponse aux résultats de sonde

Lorsqu'une sonde est terminée, le résultat DEVRAIT (SHOULD) être traité comme suit, catégorisé par le type de résultat de la sonde.

7.6.1. Succès de sonde

Lorsque la sonde est délivrée, c'est une indication que le MTU de chemin est au moins aussi grand que la taille de sonde. Définir search_low à la taille de sonde. Si la taille de sonde est supérieure à eff_pmtu, élever eff_pmtu à la taille de sonde. La taille de sonde pourrait être inférieure à eff_pmtu si le flux n'a pas utilisé le MTU complet du chemin car il est soumis à une autre limitation, comme les données disponibles dans une session interactive.

Notez que si les paquets d'un flux sont routés via plusieurs chemins, ou sur un chemin avec un MTU non déterministe, la livraison d'un seul paquet de sonde n'indique pas que tous les paquets de cette taille seront délivrés. Pour être robuste dans un tel cas, la couche de paquetisation DEVRAIT (SHOULD) effectuer une vérification MTU comme décrit dans la Section 7.8.

7.6.2. Échec de sonde

Lorsque seule la sonde est perdue, elle est traitée comme une indication que le MTU de chemin est plus petit que la taille de sonde. Dans ce seul cas, la perte NE DEVRAIT PAS (SHOULD NOT) être interprétée comme un signal de congestion.

En l'absence d'autres indications, définir search_high à la taille de sonde moins un. L'eff_pmtu pourrait être plus grand que la taille de sonde si le flux n'a pas utilisé le MTU complet du chemin car il est soumis à une autre limitation, comme les données disponibles dans une session interactive. Si eff_pmtu est plus grand que la taille de sonde, eff_pmtu DOIT (MUST) être réduit à pas plus que search_high, et DEVRAIT (SHOULD) être réduit à search_low, car l'eff_pmtu a été déterminé comme étant invalide, similaire à après un timeout d'arrêt complet (voir Section 7.7).

Si un message ICMP PTB est reçu correspondant au paquet de sonde, alors search_high et eff_pmtu PEUVENT (MAY) être définis à partir de la valeur MTU indiquée dans le message. Notez que le message ICMP peut être reçu soit avant soit après l'indication de perte de protocole.

Un événement d'échec de sonde est la seule situation dans laquelle la couche de paquetisation DEVRAIT (SHOULD) ignorer la perte comme signal de congestion. Parce qu'il y a un petit risque que la suppression du contrôle de congestion puisse avoir des conséquences imprévues (même pour une perte isolée), il est REQUIS (REQUIRED) que les événements d'échec de sonde soient moins fréquents que la période normale pour les pertes sous contrôle de congestion standard. Spécifiquement, après un événement d'échec de sonde et un contrôle de congestion supprimé, PLPMTUD NE DOIT PAS (MUST NOT) sonder à nouveau jusqu'à un intervalle plus grand que l'intervalle attendu entre les événements de contrôle de congestion. Voir Section 4 pour les détails. L'estimation la plus simple de l'intervalle jusqu'au prochain événement de congestion est le même nombre de tours que la fenêtre de congestion actuelle en paquets.

7.6.3. Échec de timeout de sonde

Si la perte a été détectée avec un timeout et réparée avec une retransmission go-back-n, alors une réduction de la fenêtre de congestion sera nécessaire. Le prix relativement élevé d'une sonde échouée dans ce cas peut mériter un intervalle de temps plus long jusqu'à la prochaine sonde. Un intervalle de temps qui est cinq fois le cas d'échec sans timeout (Section 7.6.2) est RECOMMANDÉ (RECOMMENDED).

7.6.4. Sonde non concluante

La présence d'autres pertes près de la perte de la sonde peut indiquer que la sonde a été perdue en raison de la congestion plutôt qu'en raison d'une limitation MTU. Dans ce cas, les variables d'état eff_pmtu, search_low et search_high NE DEVRAIENT PAS (SHOULD NOT) être mises à jour, et la sonde de même taille DEVRAIT (SHOULD) être tentée à nouveau dès que les préconditions de sondage sont remplies (c'est-à-dire une fois que la couche de paquetisation n'a pas de pertes non récupérées en cours). À ce stade, il est particulièrement approprié de re-sonder car la fenêtre de congestion du flux sera à son point le plus bas, minimisant la probabilité de pertes congestives.

7.7. Timeout d'arrêt complet

Dans toutes les conditions, un timeout d'arrêt complet (également connu sous le nom de "timeout persistant" dans d'autres documents) DEVRAIT (SHOULD) être considéré comme une indication d'un événement significativement perturbateur dans le réseau, tel qu'une défaillance de routeur ou un changement de routage vers un chemin avec un MTU plus petit. Pour TCP, cela se produit lorsque le seuil de timeout R1 décrit par [RFC1122] expire.

S'il y a un timeout d'arrêt complet et qu'il n'y avait pas de message ICMP indiquant une raison (PTB, réseau inaccessible, etc., ou le message ICMP a été ignoré pour une raison quelconque), la première action de récupération RECOMMANDÉE (RECOMMENDED) est de traiter cela comme un trou noir ICMP détecté tel que défini dans [RFC2923].

La réponse à un trou noir détecté dépend des valeurs actuelles pour search_low et eff_pmtu. Si eff_pmtu est plus grand que search_low, définir eff_pmtu à search_low. Sinon, définir à la fois eff_pmtu et search_low à la valeur initiale pour search_low. Sur des timeouts successifs supplémentaires, search_low et eff_pmtu DEVRAIENT (SHOULD) être divisés par deux, avec une limite inférieure de 68 octets pour IPv4 et 1280 octets pour IPv6. Des limites inférieures encore plus basses PEUVENT (MAY) être permises pour supporter un fonctionnement limité sur des liens avec des MTU plus petits que permis par les spécifications IP.

7.8. Vérification MTU

Il est possible pour un flux de traverser simultanément plusieurs chemins, mais une implémentation ne pourra garder qu'une seule représentation de chemin pour le flux. Si les chemins ont des MTU différents, stocker le MTU minimum de tous les chemins dans la représentation de chemin du flux entraînera un comportement correct. Si les messages ICMP PTB sont délivrés, alors PMTUD classique fonctionnera correctement dans cette situation.

Si la livraison ICMP échoue, cassant PMTUD classique, la connexion s'appuiera uniquement sur PLPMTUD. Dans ce cas, PLPMTUD peut également échouer car il suppose qu'un flux traverse un chemin avec un seul MTU. Une sonde avec une taille supérieure au minimum mais inférieure au maximum des MTU de chemin peut réussir. Cependant, en élevant le PMTU effectif du flux, le taux de perte augmentera significativement. Le flux peut encore progresser, mais le taux de perte résultant est susceptible d'être inacceptable. Par exemple, lors de l'utilisation du striping bidirectionnel round-robin, 50% des paquets de taille complète seraient supprimés.

Le striping de cette manière est souvent opérationnellement indésirable pour d'autres raisons (par exemple, en raison de la réorganisation des paquets) et est généralement évité en hachant chaque flux à un seul chemin. Cependant, pour augmenter la robustesse, une implémentation DEVRAIT (SHOULD) implémenter une certaine forme de vérification MTU, de sorte que si l'augmentation d'eff_pmtu entraîne une forte augmentation du taux de perte, elle reviendra à l'utilisation d'un MTU inférieur.

Une stratégie RECOMMANDÉE (RECOMMENDED) serait de sauvegarder la valeur d'eff_pmtu avant de l'élever. Ensuite, si le taux de perte s'élève au-dessus d'un seuil pendant une période de temps (par exemple, le taux de perte est supérieur à 10% sur plusieurs intervalles de timeout de retransmission (RTO)), alors le nouveau MTU est considéré comme incorrect. La valeur sauvegardée d'eff_pmtu DEVRAIT (SHOULD) être restaurée, et search_high réduit de la même manière qu'en cas d'échec de sonde. Les implémentations PLPMTUD DEVRAIENT (SHOULD) implémenter la vérification MTU.