5. PMTUD de la couche de packetisation des datagrammes

Cette section spécifie la PLPMTUD pour datagrammes (DPLPMTUD). La méthode peut être introduite à divers points de la pile de protocoles IP pour découvrir le PLPMTU afin qu'une application puisse utiliser un MPS approprié pour le chemin réseau actuel.

DPLPMTUD DEVRAIT être effectuée uniquement à une couche entre une paire de points d'extrémité. Par conséquent, lorsque DPLPMTUD est activée à une couche inférieure, un PL de couche supérieure ou une application devrait éviter d'utiliser DPLPMTUD. Un PL DOIT ajuster le MPS indiqué par DPLPMTUD pour tenir compte de tout surcoût supplémentaire introduit par le PL.

Exemples d'emplacement d'implémentation DPLPMTUD

Application Data  *
   ↓
QUIC/RTP         * (Peut implémenter DPLPMTUD)
   ↓
UDP              * (Peut implémenter DPLPMTUD)
   ↓
IP Layer
   ↓
Network Interface

L'idée centrale de DPLPMTUD est le sondage par l'émetteur. Des paquets de sonde sont envoyés pour trouver la taille maximale du message utilisateur qui peut être complètement transféré de l'émetteur à la destination.

Les sections suivantes identifient les composants requis pour l'implémentation, fournissent un aperçu des phases opérationnelles et spécifient la machine à états et l'algorithme de recherche.

5.1. Composants DPLPMTUD

Cette section décrit les temporisateurs, les constantes et les variables de DPLPMTUD.

5.1.1. Temporisateurs

La méthode utilise jusqu'à trois temporisateurs:

PROBE_TIMER

• Configuration: Délai d'attente supérieur au temps maximum pour recevoir un accusé de réception d'un paquet de sonde
• Minimum: NE DOIT PAS être inférieur à 1 seconde
• Recommandé: DEVRAIT être supérieur à 15 secondes
• Référence: La section 3.1.1 des directives d'utilisation UDP [BCP145] fournit des conseils sur la sélection des valeurs de temporisateur

PMTU_RAISE_TIMER

• Fonction: La période pendant laquelle un émetteur continuera à utiliser le PLPMTU actuel, après quoi il rentre dans la phase de recherche
• Période: 600 secondes, comme recommandé par PLPMTUD [RFC4821]
• Optimisation: DPLPMTUD PEUT inhiber l'envoi de paquets de sonde lorsqu'aucune donnée d'application n'a été envoyée depuis le dernier paquet de sonde. Un PL préférant utiliser le dernier PMTU lors de l'envoi à nouveau de données utilisateur peut choisir de continuer la découverte PMTU pour chaque chemin. Cependant, cela entraînera l'envoi de paquets supplémentaires

CONFIRMATION_TIMER

• Applicabilité: NE DOIT PAS être utilisé lorsqu'un PL acquitté est utilisé
• Fonction: Pour les autres PL, configuré comme la période pendant laquelle un émetteur PL attend avant de confirmer que le PLPMTU actuel est toujours pris en charge
• Relation: Plus petit que PMTU_RAISE_TIMER, utilisé pour réduire le PLPMTU (par exemple, lorsqu'un trou noir est rencontré)
• Fréquence: La confirmation doit être suffisamment fréquente pour que le PL émetteur ne mette pas en trou noir une grande quantité de trafic lorsque les données circulent
• Référence: La section 3.1.1 des directives d'utilisation UDP [BCP145] fournit des conseils sur la sélection des valeurs de temporisateur
• Optimisation: DPLPMTUD PEUT inhiber l'envoi de paquets de sonde lorsqu'aucune donnée d'application n'a été envoyée depuis le dernier paquet de sonde

Note: DPLPMTUD spécifie divers temporisateurs; cependant, une implémentation peut choisir de réaliser ces fonctions de temporisateur en utilisant un seul temporisateur.

5.1.2. Constantes

Les constantes suivantes sont définies:

MAX_PROBES

• Définition: La valeur maximale du compteur PROBE_COUNT
• Signification: Représente une limite sur le nombre de tentatives de sonde consécutives de toute taille
• Avantage: Une valeur MAX_PROBES supérieure à 1 peut fournir une robustesse face à la perte de paquets isolée
• Défaut: 3

MIN_PLPMTU

• Définition: La plus petite taille PLPMTU que DPLPMTUD tentera d'utiliser
• Configuration: Un point d'extrémité peut avoir besoin de configurer MIN_PLPMTU pour fournir de l'espace pour les en-têtes d'extension et autre encapsulation aux couches sous le PL
• Dépendance du chemin: Cette valeur peut dépendre de l'interface et du chemin
• IPv6: Cette taille est supérieure ou égale à la taille au PL qui résulte en un paquet IPv6 de 1280 octets, comme spécifié dans [RFC8200]
• IPv4: Cette taille est supérieure ou égale à la taille au PL qui résulte en un paquet IPv4 de 68 octets
  • Note: Les routeurs IPv4 sont tenus de pouvoir transférer un datagramme de 68 octets sans autre fragmentation. C'est la taille combinée d'un en-tête IPv4 et la taille minimale de fragment de 8 octets. De plus, les récepteurs sont tenus de pouvoir réassembler des datagrammes fragmentés d'au moins 576 octets, comme indiqué dans la section 3.3.3 de [RFC1122]

MAX_PLPMTU

• Définition: La plus grande taille PLPMTU
• Limitation: Doit être inférieure ou égale à la taille maximale du paquet PL qui peut être envoyé sur l'interface sortante (contrainte par l'interface MTU locale)
• Considération: Devrait également être inférieure à la taille maximale du paquet PL que le point d'extrémité distant peut recevoir (contrainte par EMTU_R) lorsque cela est connu
• Limitation de conception: Peut être limitée par la conception ou la configuration du PL utilisé
• Limitation d'application: Une application ou un PL PEUT choisir un MAX_PLPMTU plus petit lorsqu'il n'y a pas besoin d'envoyer des paquets plus grands qu'une taille spécifique

BASE_PLPMTU

• Définition: Une taille configurée censée fonctionner pour la plupart des chemins
• Plage: Égale ou supérieure à MIN_PLPMTU et inférieure à MAX_PLPMTU
• Recommandé: Pour la plupart des PL, un BASE_PLPMTU approprié sera supérieur à 1200 octets
• IPv4: Lors de l'utilisation d'IPv4, il n'y a pas de taille équivalente actuellement spécifiée, un BASE_PLPMTU par défaut de 1200 octets est RECOMMANDÉ

5.1.3. Variables

Cette méthode utilise un ensemble de variables:

PROBED_SIZE

• Définition: La taille du paquet de sonde actuel telle que déterminée au PL
• Nature: Il s'agit d'une valeur provisoire pour le PLPMTU, en attente de confirmation

PROBE_COUNT

• Définition: Un décompte du nombre de paquets de sonde infructueux successifs qui ont été envoyés
• Réinitialisation: Ceci est mis à zéro chaque fois qu'un paquet de sonde est acquitté
• Note: Une certaine perte de sondes est attendue lors d'une recherche, donc la perte d'une seule sonde n'est pas une indication d'un problème de PMTU

Diagramme de relation de taille de paquet

MAX_PLPMTU ────────┐
                   │
                   ↓
PROBED_SIZE ───────┤ (En cours de sonde)
                   │
                   ↓
PLPMTU ────────────┤ (Actuellement utilisé)
                   │
                   ↓
BASE_PLPMTU ───────┤ (Ligne de base)
                   │
                   ↓
MIN_PLPMTU ────────┘ (Minimum)

Le diagramme ci-dessus illustre la relation entre les constantes et variables de taille de paquet lorsque l'algorithme DPLPMTUD effectue un sondage de chemin pour augmenter la taille PLPMTU. Des paquets de sonde de taille PROBED_SIZE ont été envoyés. Une fois acquittés, le PLPMTU sera relevé à PROBED_SIZE, permettant à l'algorithme DPLPMTUD d'augmenter davantage PROBED_SIZE, se dirigeant vers l'envoi de paquets de sonde de la taille PMTU réelle.

5.1.4. Aperçu des phases DPLPMTUD

Cette section fournit une vue informative de haut niveau de la méthode DPLPMTUD en décrivant le mouvement de la méthode à travers plusieurs phases opérationnelles. Plus de détails peuvent être trouvés dans la machine à états (Section 5.2).

Diagramme de flux de phase DPLPMTUD

Initial → Phase de base → Phase de recherche → Phase de recherche complète
  ↓                                            ↑
  └──────→ Phase d'erreur ←────────────────────┘

Phase de base

• Objectif: La phase de base utilise des paquets de taille BASE_PLPMTU pour confirmer la connectivité au pair distant
• Confirmation de connexion: Pour un PL orienté connexion, la confirmation de connexion est implicite (peut être effectuée dans la poignée de main de connexion PL). Un PL sans connexion envoie des paquets de sonde et utilise l'accusé de réception de ce paquet de sonde pour confirmer que le pair distant est joignable
• Confirmation PLPMTU: L'émetteur confirme également que le chemin réseau prend en charge BASE_PLPMTU. Cela peut être réalisé en utilisant des mécanismes PL (par exemple, en utilisant un paquet de poignée de main de taille BASE_PLPMTU) ou en envoyant un paquet de sonde de taille BASE_PLPMTU et en confirmant la réception de ce paquet de sonde
• Timing de sonde: Un paquet de sonde de taille BASE_PLPMTU peut être envoyé immédiatement à l'entrée dans la phase de base (suivant la vérification de connexion). Un PL ne souhaitant pas prendre en charge les chemins avec un PLPMTU inférieur à BASE_PLPMTU peut simplifier cette phase en une seule étape en effectuant la vérification de connexion à l'aide d'une sonde de taille BASE_PLPMTU
• Succès: Une fois confirmé, DPLPMTUD entre dans la phase de recherche
• Échec: Si la phase de base ne parvient pas à confirmer BASE_PLPMTU, DPLPMTUD entre dans la phase d'erreur

Phase de recherche

• Objectif: La phase de recherche utilise un algorithme de recherche pour envoyer des paquets de sonde afin de chercher à augmenter le PLPMTU
• Terminaison: L'algorithme se termine en entrant dans la phase de recherche complète lorsqu'un PLPMTU approprié est trouvé
• Réponse PTB: Le PL peut répondre aux messages PTB en utilisant des messages PTB pour faire avancer ou terminer la recherche, voir Section 4.6

Phase de recherche complète

• État: La phase de recherche complète est entrée lorsque le PLPMTU est pris en charge sur un chemin réseau
• Confirmation périodique: Le PL peut utiliser le CONFIRMATION_TIMER pour répéter périodiquement les paquets de sonde de la taille PLPMTU actuelle
• Détection de trou noir: Si l'émetteur ne peut pas confirmer la joignabilité (par exemple, si le CONFIRMATION_TIMER expire) ou si le PL signale un manque de joignabilité, alors un trou noir est détecté et DPLPMTUD entre dans la phase de base
• Recherche périodique: Le PMTU_RAISE_TIMER est utilisé pour reprendre périodiquement la phase de recherche pour découvrir si le PLPMTU peut être augmenté

Phase d'erreur

• Déclenchement: La phase d'erreur est entrée lorsque les informations PLPMTU pour un chemin sont contradictoires ou invalides (par exemple, ne peuvent pas prendre en charge BASE_PLPMTU), ce qui empêche DPLPMTUD de continuer et réduit le PLPMTU
• Atténuation: Cet état implémente une méthode pour atténuer les oscillations dans le moteur d'événements d'état. Il signale une valeur MPS conservatrice aux couches supérieures via le PL
• Sortie: Cet état est quitté lorsque les paquets de sonde ne détectent plus d'erreur. L'émetteur PL entre alors dans l'état de recherche

Robustesse: Une méthode se contentant de réduire le PLPMTU à une taille appropriée est suffisante pour assurer un fonctionnement fiable, mais pourrait être très inefficace lorsque le PMTU réel change ou lorsque la méthode (pour quelque raison que ce soit) fait un choix sous-optimal pour le PLPMTU.

Implémentation complète: Une implémentation complète de DPLPMTUD fournit un algorithme qui permet à un émetteur DPLPMTUD d'augmenter le PLPMTU suite à des changements dans les caractéristiques du chemin, par exemple lorsqu'un lien est reconfiguré avec un MTU plus grand, ou lorsqu'il y a un changement dans l'ensemble des liens traversés par un flux de bout en bout (par exemple, après une décision de basculement de routage ou de chemin).

5.2. Machine à états

La machine à états pour DPLPMTUD est représentée ci-dessous. Si le multichemin ou le multihoming est pris en charge, une machine à états est nécessaire pour chaque chemin.

Note: Pour plus de clarté, le diagramme ne montre pas toutes les transitions.

Diagramme de machine à états

        [DISABLED]
            ↓ ↑
      Connexion établie/Perdue
            ↓ ↑
         [BASE] ←──────────────┐
            ↓                   │
        Succès de sonde       Détection de trou noir
            ↓                   │
       [SEARCHING] ─────────────┤
            ↓                   │
      Sonde complète/Échec      │
            ↓                   │
    [SEARCH_COMPLETE] ──────────┘
            ↑ ↓
      Élévation périodique/Détection de trou noir

        [ERROR]
      (Gestion d'erreur)

Définitions d'état

DISABLED

• État initial: L'état initial avant le début du sondage
• Condition d'entrée: Entré depuis tout autre état lorsque le PL indique une perte de connectivité
• Condition de sortie: Quitter cet état une fois que le PL indique la connectivité au PL distant
• Transition: Lors de la transition vers l'état BASE, un paquet de sonde de taille BASE_PLPMTU peut être envoyé immédiatement

BASE

• Objectif: Utilisé pour confirmer que le chemin réseau prend en charge la taille BASE_PLPMTU, destiné à permettre à une application de continuer à fonctionner lorsque le PMTU réel est temporairement réduit. Il cherche également à éviter qu'un émetteur utilisant DPLPMTUD ne sache pas que les paquets ne sont pas livrés en raison d'un trou noir de paquets ou d'ICMP pendant une période prolongée pendant laquelle il recherche un PLPMTU plus grand
• À l'entrée: PROBED_SIZE est défini sur la taille BASE_PLPMTU et PROBE_COUNT est mis à zéro
• Sondage: Chaque fois qu'un paquet de sonde est envoyé, le PROBE_TIMER est démarré
• Sortie réussie: L'état est quitté lorsqu'un paquet de sonde est acquitté, l'émetteur PL entre dans l'état SEARCHING
• Sortie d'échec: L'état est également quitté lorsque PROBE_COUNT atteint MAX_PROBES ou qu'un message PTB validé est reçu. Cela amène l'émetteur PL à entrer dans l'état ERROR

SEARCHING

• État principal: C'est l'état de sondage principal
• Condition d'entrée: Entré lorsqu'une sonde de BASE_PLPMTU se termine
• Sonde réussie: Chaque fois qu'un paquet de sonde est acquitté, PROBE_COUNT est mis à zéro, PLPMTU est défini sur PROBED_SIZE, et PROBED_SIZE est ensuite augmenté en utilisant l'algorithme de recherche (comme décrit dans Section 5.3)
• Échec de sonde: Lorsqu'un paquet de sonde est envoyé sans être acquitté dans la période PROBE_TIMER, PROBE_COUNT est incrémenté et une nouvelle sonde est transmise
• Condition de sortie: Sortie lorsque PROBE_COUNT atteint MAX_PROBES pour entrer dans SEARCH_COMPLETE, un PTB validé est reçu correspondant à la dernière taille de sonde réussie (PL_PTB_SIZE = PLPMTU), ou une sonde de taille MAX_PLPMTU est acquittée (PLPMTU = MAX_PLPMTU)
• Détection de trou noir: Lorsqu'un trou noir est détecté alors qu'il est dans l'état SEARCHING, cela amène l'émetteur PL à entrer dans l'état BASE

SEARCH_COMPLETE

• Indicateur d'achèvement: Indique que la recherche est terminée. C'est l'état de maintenance normal où le PL ne sonde pas pour mettre à jour le PLPMTU
• Durée: DPLPMTUD reste dans cet état jusqu'à ce que soit le PMTU_RAISE_TIMER expire soit qu'un trou noir soit détecté
• PL non acquitté: Lorsque DPLPMTUD utilise un PL non acquitté et est dans l'état SEARCH_COMPLETE, le CONFIRMATION_TIMER réinitialise périodiquement PROBE_COUNT et planifie un paquet de sonde de taille PLPMTU. Si MAX_PROBES paquets de sonde consécutifs de taille PLPMTU ne sont pas acquittés, la méthode entre dans l'état BASE
• PL acquitté: Lorsqu'il est utilisé avec un PL acquitté (par exemple, SCTP), DPLPMTUD NE DEVRAIT PAS continuer à générer des sondes PLPMTU dans cet état

ERROR

• Situation d'échec: Indique que le chemin réseau n'est pas connu pour prendre en charge un PLPMTU d'au moins la taille BASE_PLPMTU ou qu'il existe des informations contradictoires sur le chemin réseau qui pourraient autrement faire osciller excessivement le signal MPS vers les couches supérieures
• Atténuation d'oscillation: Cet état implémente une méthode pour atténuer les oscillations dans le moteur d'événements d'état
• Valeur conservatrice: Il signale une valeur MPS conservatrice aux couches supérieures via le PL
• Sortie: Cet état est quitté lorsque les paquets de sonde ne détectent plus d'erreur. L'émetteur PL entre alors dans l'état SEARCHING
• Fragmentation de point d'extrémité: L'implémentation permet d'activer la fragmentation de point d'extrémité si DPLPMTUD ne peut pas valider MIN_PLPMTU dans les sondes PROBE_COUNT
• Désactivation: Si DPLPMTUD ne peut pas valider MIN_PLPMTU, les implémentations passeront à l'état DISABLED
• Note: MIN_PLPMTU peut être identique à BASE_PLPMTU, simplifiant le fonctionnement de cet état

5.3. Recherche pour augmenter le PLPMTU

Cette section décrit les algorithmes utilisés par DPLPMTUD pour rechercher un PLPMTU plus grand.

5.3.1. Sondage pour un PLPMTU plus grand

Les implémentations utilisent un algorithme de recherche sur la plage de recherche pour déterminer si le chemin réseau peut prendre en charge un PLPMTU plus grand.

La méthode découvre la plage de recherche en confirmant le PLPMTU minimum puis en utilisant le sondage pour sélectionner un PROBED_SIZE inférieur ou égal à MAX_PLPMTU. Le MAX_PLPMTU est le minimum de la MTU locale et EMTU_R (lorsqu'il est appris du point d'extrémité distant). MAX_PLPMTU PEUT être réduit par une application qui définit un maximum à la taille des datagrammes qu'elle enverra.

Lorsque la première sonde de taille supérieure ou égale à PLPMTU est envoyée, PROBE_COUNT est initialisé à zéro. Chaque paquet de sonde envoyé avec succès au pair distant est confirmé par un accusé de réception du PL (voir Section 4.1).

Chaque fois qu'un paquet de sonde est envoyé à la destination, le PROBE_TIMER est démarré. Le temporisateur est annulé lorsque le PL reçoit un accusé de réception que le paquet de sonde a été envoyé avec succès sur le chemin (Section 4.1). Cela confirme que PROBED_SIZE est pris en charge, et la valeur PROBED_SIZE est ensuite attribuée à PLPMTU. L'algorithme de recherche peut continuer à envoyer des sondes ultérieures de taille croissante.

Si le temporisateur expire avant qu'un paquet de sonde ne soit acquitté, la sonde a échoué à confirmer PROBED_SIZE. Chaque fois que le PROBE_TIMER expire, PROBE_COUNT est incrémenté, le PROBE_TIMER est réinitialisé, et une nouvelle sonde de la même taille ou de toute autre taille (tel que déterminé par l'algorithme de recherche) peut être envoyée. Un nombre maximum de sondes échouées consécutives (MAX_PROBES) est configuré. Si la valeur de PROBE_COUNT atteint MAX_PROBES, le sondage s'arrêtera, et l'émetteur PL entre dans l'état SEARCH_COMPLETE.

5.3.2. Sélection des tailles de sonde

L'algorithme de recherche détermine l'augmentation minimale utile du PLPMTU. Il n'est pas constructif pour l'émetteur PL de tenter de sonder toutes les tailles. Cela imposerait une charge inutile sur le chemin. Les implémentations DEVRAIENT sélectionner un ensemble de tailles de paquets de sonde pour maximiser le gain en PLPMTU de chaque étape de recherche.

Les implémentations peuvent optimiser la procédure de recherche en sélectionnant des tailles d'étape à partir d'un tableau de tailles PMTU communes. Lors de la sélection d'une taille suivante appropriée à rechercher, les implémenteurs devraient également considérer les tailles MPS communes que les applications pourraient chercher à utiliser et qu'il pourrait y avoir des tailles MTU communes en usage dans le réseau.

5.3.3. Résilience aux informations de chemin incohérentes

La décision d'augmenter le PLPMTU doit être résiliente à la possibilité d'incohérence dans les informations qui ont été apprises sur le chemin réseau. L'incohérence dans le chemin peut survenir lorsque les paquets de sonde sont perdus pour des raisons autres que la taille du paquet (c'est-à-dire une perte non liée à la taille) ou en raison de changements de chemin fréquents. Les changements de chemin fréquents pourraient résulter d'une "gigue" inattendue -- où certains paquets d'un flux sont livrés le long d'un chemin, mais d'autres paquets suivent un chemin différent avec des propriétés différentes.

Un émetteur PL est capable de détecter l'incohérence à partir d'une séquence de sondes PLPMTU acquittées ou d'une séquence de messages PTB qu'il reçoit. Un émetteur PL peut utiliser un modèle de recherche alternatif lorsqu'il détecte des informations de chemin incohérentes, un qui limite le MPS qui est fourni à une valeur plus petite pendant une période de temps. Cela évite une perte de paquets inutile.

5.4. Robustesse aux chemins incohérents

Certains chemins pourraient être incapables de soutenir des paquets de taille BASE_PLPMTU. L'état d'erreur peut être implémenté pour fournir une robustesse pour de tels chemins. Cela permet un repli vers un PLPMTU plus petit que souhaité plutôt que de subir une défaillance de connexion. Cela peut utiliser des méthodes telles que la fragmentation IP de point d'extrémité pour permettre à l'émetteur PL de communiquer en utilisant des paquets plus petits que BASE_PLPMTU.

Résumé de l'algorithme

Éléments clés de l'algorithme DPLPMTUD:

1. Démarrage conservateur: Commencer à partir de BASE_PLPMTU
2. Sondage progressif: Augmenter progressivement la taille de sonde
3. Mécanisme de confirmation: Vérifier que chaque taille est disponible
4. Détection de trou noir: Répondre rapidement aux problèmes de chemin
5. Maintenance périodique: Maintenir le PLPMTU à jour
6. Récupération d'erreur: Gérer les situations exceptionnelles

Ces mécanismes ensemble garantissent que DPLPMTUD peut fonctionner de manière fiable et efficace dans diverses conditions réseau.