10. Couches de paquetisation spécifiques

Tous les protocoles de couche de paquetisation doivent considérer toutes les questions discutées dans la Section 6. Pour de nombreux protocoles, il est simple de traiter ces questions. Cette section discute des détails spécifiques pour implémenter PLPMTUD avec quelques protocoles. On espère que les descriptions ici seront une illustration suffisante pour que les implémenteurs s'adaptent à des protocoles supplémentaires.

10.1. Méthode de sondage utilisant TCP

TCP n'a pas de mécanisme pour distinguer les données en bande du remplissage. Par conséquent, TCP doit générer des sondes en segmentant les données de manière appropriée. Il existe deux approches de segmentation: chevauchante et non chevauchante.

Méthode non chevauchante

Dans la méthode non chevauchante, les données sont segmentées de sorte que la sonde et tous les segments ultérieurs ne contiennent pas de données chevauchantes. Si la sonde est perdue, l'"écart de sonde" sera une taille de sonde complète moins les en-têtes. Les données dans l'écart de sonde devront être retransmises avec plusieurs segments plus petits.

Numéro de séquence TCP

t   <---->
i         <-------->           (sonde)
m                   <---->
e
                .
                .                (sonde perdue)
                .

            <---->               (écart de sonde retransmis)
                  <-->

Méthode chevauchante

Une approche alternative consiste à envoyer des données ultérieures chevauchant la sonde de sorte que l'écart de sonde soit égal en longueur au MSS actuel. Dans le cas d'une sonde réussie, cela a une surcharge supplémentaire en ce qu'il enverra certaines données deux fois, mais il devra ne retransmettre qu'un segment après une sonde perdue. Lorsqu'une sonde réussit, il y aura probablement des acquittements en double générés en raison des données en double envoyées. Il est important que ces acquittements en double ne déclenchent pas Fast Retransmit. En tant que tel, une implémentation utilisant cette approche DEVRAIT (SHOULD) limiter la taille de sonde à trois fois le MSS actuel (causant au plus 2 acquittements en double), ou ajuster de manière appropriée son seuil d'acquittement en double pour les données immédiatement après une sonde réussie.

Numéro de séquence TCP

t   <---->
i         <-------->           (sonde)
m               <---->
e                     <---->

                .
                .                (sonde perdue)
                .

            <---->               (écart de sonde retransmis)

Le choix de la méthode de segmentation à utiliser devrait être basé sur ce qui est le plus simple et le plus efficace pour une implémentation TCP donnée.

10.2. Méthode de sondage utilisant SCTP

Dans le Stream Control Transmission Protocol (SCTP) [RFC2960], l'application écrit des messages à SCTP, qui divise les données en "blocs" plus petits adaptés à la transmission à travers le réseau. Chaque bloc se voit attribuer un Transmission Sequence Number (TSN). Une fois qu'un TSN a été transmis, SCTP ne peut pas changer la taille du bloc. Le support multichemin SCTP exige normalement que SCTP choisisse une taille de bloc telle que ses messages s'adaptent au PMTU le plus petit de tous les chemins. Bien que non requis, les implémentations peuvent regrouper plusieurs blocs de données ensemble pour créer des paquets IP plus grands à envoyer sur des chemins avec un PMTU plus grand. Notez que SCTP doit sonder indépendamment le PMTU sur chaque chemin vers le pair.

La méthode RECOMMANDÉE (RECOMMENDED) pour générer des sondes consiste à ajouter un bloc composé uniquement de remplissage à un message SCTP. Le bloc PAD défini dans [RFC4820] DEVRAIT (SHOULD) être attaché à un bloc HEARTBEAT (HB) de longueur minimale pour construire un paquet de sonde. Cette méthode est entièrement compatible avec toutes les implémentations SCTP actuelles.

SCTP PEUT (MAY) également sonder avec une méthode similaire à celle de TCP décrite ci-dessus, en utilisant des données en ligne. L'utilisation d'une telle méthode a l'avantage que les sondes réussies n'ont pas de surcharge supplémentaire; cependant, les sondes échouées nécessiteront la retransmission de données, ce qui peut impacter les performances du flux.

10.3. Méthode de sondage pour la fragmentation IP

Il existe quelques protocoles et applications qui envoient normalement de grands datagrammes et comptent sur la fragmentation IP pour les délivrer. Il est connu depuis longtemps que cela a des conséquences indésirables [Kent87]. Plus récemment, il est apparu que la fragmentation IPv4 n'est pas suffisamment robuste pour une utilisation générale dans Internet d'aujourd'hui. Le champ d'identification IP de 16 bits n'est pas assez grand pour empêcher des fragments IP mal associés fréquents, et les checksums TCP et UDP sont insuffisants pour empêcher les données corrompues résultantes d'être délivrées aux couches de protocole supérieures [frag-errors].

Comme mentionné dans la Section 8, les protocoles de datagramme (tels qu'UDP) pourraient s'appuyer sur la fragmentation IP comme couche de paquetisation. Cependant, utiliser la fragmentation IP pour implémenter PLPMTUD est problématique car la couche IP n'a pas de mécanisme pour déterminer si les paquets sont finalement délivrés au nœud distant, sans participation directe de l'application.

Pour supporter la fragmentation IP comme couche de paquetisation sous une application non modifiée, une implémentation DEVRAIT (SHOULD) s'appuyer sur le partage de MTU de chemin décrit dans la Section 5.2 plus un protocole auxiliaire pour sonder le MTU de chemin. Il existe plusieurs protocoles qui pourraient être utilisés à cette fin, tels que ICMP ECHO et ECHO REPLY, ou des datagrammes UDP de style "traceroute" qui déclenchent des messages ICMP. L'utilisation d'ICMP ECHO et ECHO REPLY sondera à la fois les chemins avant et retour, donc l'émetteur ne pourra profiter que du minimum des deux. D'autres méthodes qui sondent uniquement le chemin avant sont préférées si disponibles.

Toutes ces approches ont plusieurs problèmes de robustesse potentiels. Les échecs les plus probables sont dus à des pertes non liées au MTU (par exemple, des nœuds qui rejettent certains types de protocole). Ces pertes non liées au MTU peuvent empêcher PLPMTUD d'augmenter le MTU, forçant la fragmentation IP à utiliser un MTU plus petit que nécessaire. Étant donné que ces échecs ne sont pas susceptibles de causer des problèmes d'interopérabilité, ils sont relativement bénins.

Cependant, d'autres modes d'échec plus graves existent, tels que ceux qui pourraient être causés par des boîtes intermédiaires ou des routeurs de couche supérieure qui choisissent des chemins différents pour différents types de protocoles ou sessions. Dans de tels environnements, les protocoles auxiliaires peuvent légitimement subir un MTU de chemin différent du protocole principal. Si le protocole auxiliaire trouve un MTU plus grand que le protocole principal, PLPMTUD peut sélectionner un MTU qui n'est pas utilisable par le protocole principal. Bien que ce soit un problème potentiellement grave, ce type de situation est susceptible d'être considéré comme incorrect par un grand nombre d'observateurs, et il y aura donc une forte motivation pour le corriger.

Étant donné que les protocoles sans connexion peuvent ne pas conserver suffisamment d'état pour diagnostiquer efficacement les trous noirs MTU, il serait plus robuste de pécher par excès de prudence en utilisant un MTU initial trop petit (par exemple, 1 kByte ou moins) avant de sonder un chemin pour mesurer le MTU. Pour cette raison, les implémentations qui utilisent la fragmentation IP DEVRAIENT (SHOULD) utiliser un eff_pmtu initial, qui est sélectionné comme décrit dans la Section 7.2, sauf en utilisant un contrôle global séparé pour l'eff_mtu initial par défaut pour les protocoles sans connexion.

Les protocoles sans connexion introduisent également un problème supplémentaire avec le maintien du cache d'informations de chemin: il n'y a pas d'événements correspondant à l'établissement et à la fermeture de connexion à utiliser pour gérer le cache lui-même. Une approche naturelle serait de conserver une entrée de cache immuable pour le "chemin par défaut", qui a un eff_pmtu fixé à la valeur initiale pour les protocoles sans connexion. Le protocole auxiliaire de découverte du MTU de chemin serait invoqué une fois que le nombre de datagrammes fragmentés vers une destination particulière atteint un certain seuil configurable (par exemple, 5 datagrammes). Une nouvelle entrée de cache de chemin serait créée lorsque le protocole auxiliaire met à jour eff_pmtu, et supprimée sur la base d'un temporisateur ou d'un algorithme de remplacement de cache le moins récemment utilisé.

10.4. Méthode de sondage utilisant des applications

Les inconvénients de s'appuyer sur la fragmentation IP et un protocole auxiliaire pour effectuer la découverte du MTU de chemin peuvent être surmontés en implémentant la découverte du MTU de chemin dans l'application elle-même, en utilisant le propre protocole de l'application. L'application doit avoir une méthode appropriée pour générer des sondes et avoir un mécanisme précis et opportun pour déterminer si les sondes ont été perdues.

Idéalement, le protocole d'application inclut une fonction d'écho légère qui confirme la livraison de message, plus un mécanisme pour remplir les messages à la taille de sonde souhaitée, de sorte que le remplissage ne soit pas écho. Cette combinaison (semblable à HB SCTP plus PAD) est RECOMMANDÉE (RECOMMENDED) car une application peut mesurer séparément le MTU de chaque direction sur un chemin avec des MTU asymétriques.

Pour les protocoles qui ne peuvent pas implémenter PLPMTUD avec "écho plus remplissage", il existe souvent des méthodes alternatives pour générer des sondes. Par exemple, le protocole peut avoir un écho de longueur variable qui mesure effectivement le MTU minimum des chemins avant et retour, ou il peut y avoir un moyen d'ajouter du remplissage aux messages réguliers transportant de vraies données d'application. Il peut également y avoir des moyens alternatifs de segmenter les données d'application pour générer des sondes, ou en dernier recours, il peut être faisable d'étendre le protocole avec de nouveaux types de messages spécifiquement pour supporter la découverte MTU.

Notez que s'il est nécessaire d'ajouter de nouveaux types de messages pour supporter PLPMTUD, l'approche la plus générale consiste à ajouter des messages ECHO et PAD, qui permettent la plus grande latitude possible dans la façon dont une implémentation spécifique à l'application de PLPMTUD interagit avec d'autres applications et protocoles sur le même système final.

Toutes les techniques de sondage d'application nécessitent la capacité d'envoyer des messages plus grands que l'eff_pmtu actuel décrit dans la Section 9.