3. Fonctionnalités requises pour fournir le PLPMTUD de datagramme

Les principes exprimés dans [RFC4821] s'appliquent à l'utilisation de la technique avec n'importe quel PL. Le PLPMTUD TCP a été défini en utilisant des mécanismes de protocole TCP standard. Contrairement à TCP, un PL de datagramme nécessite des mécanismes et considérations supplémentaires pour implémenter PLPMTUD.

Exigences pour le PLPMTUD de datagramme

1. Gestion du PLPMTU

Pour les PL de datagramme, le PLPMTU est géré par DPLPMTUD. Un PL NE DOIT PAS envoyer un datagramme (autre qu'un paquet de sondage) avec une taille au niveau PL supérieure au PLPMTU actuel.

2. Paquets de sondage

L'interface réseau en dessous du PL est REQUISE pour fournir un moyen de transmettre un paquet de sondage plus grand que le PLPMTU.

• IPv4: Un paquet de sondage DOIT être envoyé avec le bit Don't Fragment (DF) défini dans l'en-tête IP et sans fragmentation d'extrémité de couche réseau.
• IPv6: Un paquet de sondage est toujours envoyé sans fragmentation source (comme spécifié dans [RFC8201] Section 5.4).

3. Retour de réception

Le point de terminaison PL de destination est REQUIS pour fournir une méthode de retour qui indique à l'émetteur DPLPMTUD quand un paquet de sondage a été reçu par le point de terminaison PL de destination. Section 6 fournit des exemples de la façon dont un PL peut fournir cette confirmation des paquets de sondage reçus.

4. Récupération de perte de sondage

Il est RECOMMANDÉ d'utiliser des paquets de sondage qui ne transportent pas de données utilisateur nécessitant une retransmission en cas de perte. La plupart des transports de datagramme le permettent.

Si un paquet de sondage contient des données utilisateur nécessitant une retransmission en cas de perte:

• Le PL (ou les couches supérieures) est REQUIS d'organiser toute retransmission et/ou réparation de toute perte résultante.
• Le PL est REQUIS d'être robuste dans le cas où des paquets de sondage sont perdus pour d'autres raisons (y compris erreur de transmission de liaison, congestion).

5. Paramètres PMTU

• Un émetteur DPLPMTUD est RECOMMANDÉ d'utiliser les informations sur la taille maximale de paquet pouvant être transmis par l'émetteur sur la liaison locale (par exemple, le MTU de liaison locale).
• Un émetteur PL PEUT utiliser des informations similaires sur la taille maximale de paquet de couche réseau qu'un récepteur peut accepter lorsque cela est fourni (notez que cela pourrait être inférieur à EMTU_R).

Cela évite que les implémentations tentent d'envoyer des paquets de sondage qui ne peuvent pas être transférés par la liaison locale. Une valeur trop élevée pourrait réduire l'efficacité de l'algorithme de recherche. Certaines applications ont également une taille maximale d'unité de données de protocole de transport (PDU), auquel cas il n'y a aucun avantage à sonder une taille supérieure à celle-ci (à moins qu'un transport ne permette le multiplexage des PDU de plusieurs applications dans le même datagramme).

6. Traitement des messages PTB

• Un émetteur DPLPMTUD PEUT optionnellement utiliser les messages PTB reçus de la couche réseau pour aider à identifier quand un chemin réseau ne supporte pas la taille actuelle du paquet de sondage.
• Tout message PTB reçu DOIT être validé avant d'être utilisé pour mettre à jour les informations de découverte PLPMTU [RFC8201].

Cette validation confirme que le message PTB a été envoyé en réponse à un paquet provenant du point de terminaison PL effectuant DPLPMTUD. Cette validation doit être effectuée avant que la méthode de découverte PLPMTU ne réagisse au message PTB.

• Un message PTB NE DOIT PAS être utilisé pour augmenter le PLPMTU [RFC8201].
• Un message PTB pourrait déclencher un sondage pour tester un PLPMTU plus grand.

Un PTB_SIZE valide est converti en PL_PTB_SIZE avant d'être utilisé dans la machine à états DPLPMTUD. Un PL_PTB_SIZE supérieur à celui actuellement sondé DEVRAIT être ignoré (Ce message PTB devrait être supprimé sans traitement supplémentaire mais pourrait être utilisé comme entrée permettant un mode de résilience).

7. Sondage et contrôle de congestion

• Un PL PEUT utiliser un contrôleur de congestion pour décider quand envoyer un paquet de sondage.

Si la transmission de paquets de sondage est limitée par le contrôleur de congestion, cela pourrait entraîner un retard ou une suspension de la transmission des paquets de sondage pendant la congestion.

• Lorsque la transmission de paquets de sondage n'est pas contrôlée par le contrôleur de congestion, l'intervalle entre les paquets de sondage DOIT être d'au moins un RTT.
• La perte d'un paquet de sondage NE DEVRAIT PAS être traitée comme une indication de congestion.
• La perte d'un paquet de sondage NE DEVRAIT PAS déclencher une réaction de contrôle de congestion [RFC4821].

Ceci est dû au fait que cela pourrait entraîner une réduction inutile du débit d'envoi.

• Une mise à jour du PLPMTU (ou MPS) NE DOIT PAS augmenter la fenêtre de congestion mesurée en octets [RFC4821].

Par conséquent, une augmentation de la taille du paquet n'entraîne pas une augmentation du débit de données en octets par seconde. Un PL qui maintient la fenêtre de congestion en termes de limite du nombre de paquets de taille fixe en attente DEVRAIT adapter cette limite pour compenser la taille des paquets réels.

La transmission de paquets de sondage peut interagir avec le fonctionnement d'un PL qui effectue une atténuation de rafale ou un rythme, et le PL pourrait avoir besoin que la transmission de paquets de sondage soit régulée par ces méthodes.

8. Sondage et contrôle de flux

Le contrôle de flux au niveau PL concerne le flux de bout en bout des données utilisant le service PL. Le contrôle de flux NE DEVRAIT PAS s'appliquer à DPLPMTUD lorsque les paquets de sondage utilisent une conception qui ne transporte pas de données utilisateur vers l'application distante.

9. État PLPMTU partagé

La valeur PMTU calculée à partir du PLPMTU PEUT également être stockée avec l'entrée correspondante associée à la destination dans le cache de couche IP et utilisée par d'autres instances PL.

La spécification de PLPMTUD [RFC4821] stipule: «Si PLPMTUD met à jour le MTU pour un chemin particulier, toutes les sessions de couche de paquetisation qui partagent la représentation du chemin (comme décrit dans la section 5.2) DEVRAIENT être notifiées pour utiliser le nouveau MTU». De telles méthodes DOIVENT être robustes face à la grande variété de comportements de transfert réseau sous-jacents. [RFC8201] Section 5.2 fournit des conseils sur la mise en cache des informations PMTU et également la relation avec les étiquettes de flux IPv6.

Principes de conception

En plus des exigences ci-dessus, les principes suivants sont énoncés pour la conception d'une méthode DPLPMTUD:

1. Segmentation des données

• Un PL PEUT être conçu pour segmenter des blocs de données plus grands que le MPS en plusieurs datagrammes.

Cependant, tous les PL de datagramme ne prennent pas en charge la segmentation des blocs de données.

• Il est RECOMMANDÉ que les méthodes évitent de forcer une application à utiliser un MPS arbitrairement petit pour la transmission pendant que la méthode recherche le PLPMTU actuellement supporté.

Un MPS réduit peut nuire aux performances d'une application.

2. Primitive MPS

Pour aider les applications à choisir une taille de bloc de données appropriée, il est RECOMMANDÉ que le PL fournisse une primitive qui renvoie le MPS dérivé du PLPMTU à la couche supérieure utilisant le PL. La valeur du MPS peut changer suite à un changement de chemin ou à une perte de paquets de sondage.

3. Validation du chemin

Il est RECOMMANDÉ que les méthodes soient robustes face aux changements de chemin qui pourraient s'être produits depuis que les caractéristiques du chemin ont été confirmées pour la dernière fois et à la possibilité de recevoir des informations de chemin incohérentes.

4. Réordonnancement des datagrammes

Une méthode est REQUISE d'être robuste face à la possibilité qu'un flux rencontre un réordonnancement ou que le trafic (y compris les paquets de sondage) soit divisé sur plus d'un chemin réseau.

5. Retard et duplication des datagrammes

Le mécanisme de retour est REQUIS d'être robuste face à la possibilité que des paquets puissent être considérablement retardés ou dupliqués le long d'un chemin réseau.

6. Quand sonder

Il est RECOMMANDÉ que les méthodes déterminent si le chemin a changé depuis qu'il a mesuré le chemin pour la dernière fois. Cela peut aider à déterminer quand sonder à nouveau le chemin.

Considérations de mise en œuvre

Lors de la mise en œuvre de DPLPMTUD, considérez:

1. Efficacité: Évitez le sondage excessif qui cause une surcharge réseau
2. Robustesse: Gérez diverses conditions réseau et scénarios de défaillance
3. Interopérabilité: Compatibilité avec les protocoles et implémentations existants
4. Performance: Minimisez l'impact sur les performances des applications

Ces exigences et principes garantissent que DPLPMTUD peut fonctionner de manière fiable dans diverses conditions réseau.