6. Propriétés communes de paquetisation
Cette section décrit les propriétés et caractéristiques générales de la couche de paquetisation nécessaires pour implémenter PLPMTUD. Elle décrit également certains problèmes d'implémentation communs à toutes les couches de paquetisation.
6.1. Mécanisme de détection de perte
Il est important que la couche de paquetisation dispose d'un mécanisme opportun et robuste pour détecter et signaler les pertes. PLPMTUD effectue des ajustements MTU sur la base des pertes détectées. Tout retard ou inexactitude dans la notification de perte est susceptible d'entraîner des décisions MTU incorrectes ou une convergence lente. Il est important que le mécanisme puisse distinguer de manière robuste entre la perte isolée d'une seule sonde et d'autres pertes dans les fenêtres avant et arrière de la sonde.
Il est préférable que les protocoles de paquetisation utilisent un mécanisme de détection de perte explicite tel qu'un tableau de bord d'accusé de réception sélectif (SACK) [RFC3517] ou un vecteur ACK [RFC4340] pour distinguer les pertes réelles des données réordonnées, bien que les mécanismes implicites tels que le comptage des accusés de réception en double de style TCP Reno soient suffisants.
PLPMTUD peut également être implémenté dans des protocoles qui s'appuient sur les timeouts comme mécanisme principal de récupération de perte; cependant, les timeouts NE DEVRAIENT PAS (SHOULD NOT) être utilisés comme mécanisme principal d'indication de perte à moins qu'il n'y ait pas d'autres alternatives.
6.2. Génération de sondes
Il existe plusieurs façons possibles de modifier les couches de paquetisation pour générer des sondes. Les différentes techniques entraînent différents coûts dans trois domaines: difficulté à générer le paquet de sonde (en termes de complexité d'implémentation de la couche de paquetisation et de mouvement de données supplémentaire), capacité réseau supplémentaire possible consommée par les sondes, et coût de récupération des sondes échouées (coûts réseau et protocole).
Certains protocoles pourraient être étendus pour permettre un remplissage arbitraire avec des données factices. Cela simplifie grandement l'implémentation car le sondage peut être effectué sans participation des couches supérieures et si la sonde échoue, les données manquantes (l'"écart de sonde") sont assurées de tenir dans le MTU actuel lors de leur retransmission.
De nombreux protocoles de couche de paquetisation peuvent transporter des messages de contrôle purs (sans aucune donnée des couches de protocole supérieures), qui peuvent être remplis à des longueurs arbitraires. Par exemple, le bloc PAD SCTP peut être utilisé de cette manière (voir section 10.2). Cette approche a l'avantage que rien ne doit être retransmis si la sonde est perdue.
Ces techniques ne fonctionnent pas pour TCP, car il n'y a pas de champ de longueur séparé ou d'autre mécanisme pour différencier le remplissage des données de charge utile réelles. Avec TCP, la seule approche consiste à envoyer des données de charge utile supplémentaires dans un segment surdimensionné.
Dans quelques cas, il peut ne pas y avoir de mécanismes raisonnables pour générer des sondes dans le protocole de couche de paquetisation lui-même. En dernier recours, il peut être possible de s'appuyer sur un protocole auxiliaire, tel qu'ICMP ECHO ("ping"), pour envoyer des paquets de sonde.