10. Considérations sur les performances
Le trafic en rafale peut souvent conduire à des pertes de paquets corrélées temporellement ; à son tour, cela peut conduire à des réponses sous-optimales des contrôleurs de congestion dans les protocoles s'exécutant à l'intérieur du tunnel. Pour éviter cela, les points de terminaison de relais IP DEVRAIENT s'efforcer d'éviter d'augmenter le caractère en rafale du trafic IP ; ils NE DEVRAIENT PAS mettre les paquets en file d'attente afin d'augmenter le traitement par lots au-delà de la quantité minimale requise pour tirer parti des délestages matériels.
Lorsque le protocole s'exécutant à l'intérieur du tunnel utilise le contrôle de congestion (par exemple, [TCP] ou [QUIC]), le trafic relayé subira au moins deux contrôleurs de congestion imbriqués. Lorsque les paquets tunnelisés sont envoyés à l'aide de trames QUIC DATAGRAM, la connexion HTTP externe PEUT désactiver le contrôle de congestion pour les paquets qui contiennent uniquement des trames QUIC DATAGRAM encapsulant des paquets IP. Les implémenteurs bénéficieront de la lecture des conseils de la Section 3.1.11 de UDP-USAGE.
Lorsque le protocole s'exécutant à l'intérieur du tunnel utilise la récupération de perte (par exemple, [TCP] ou [QUIC]) et que la connexion HTTP externe s'exécute sur TCP, le trafic relayé subira au moins deux mécanismes de récupération de perte imbriqués. Cela peut réduire les performances, car les deux peuvent parfois retransmettre indépendamment les mêmes données. Pour éviter cela, le relais IP DEVRAIT être effectué sur HTTP/3 pour permettre l'exploitation de la trame QUIC DATAGRAM.
10.1. Considérations sur la MTU
Lors de l'utilisation de HTTP/3 avec l'extension QUIC Datagram [DGRAM], les paquets IP sont transmis dans des trames QUIC DATAGRAM. Puisque ces trames ne peuvent pas être fragmentées, elles ne peuvent transporter des paquets que jusqu'à une longueur donnée déterminée par la configuration de la connexion QUIC et la MTU du chemin (PMTU). Si un point de terminaison utilise des trames QUIC DATAGRAM et qu'il tente de router un paquet IP à travers le tunnel qui ne tiendra pas dans une trame QUIC DATAGRAM, le proxy IP NE DEVRAIT PAS envoyer le paquet IP dans une capsule DATAGRAM, car cela va à l'encontre de la caractéristique de non-fiabilité de bout en bout dont dépendent des méthodes telles que la découverte PMTU de la couche de paquettisation de datagramme (DPLPMTUD) [DPLPMTUD]. Dans ce scénario, le point de terminaison DEVRAIT supprimer le paquet IP et envoyer un message ICMP Packet Too Big (Paquet trop grand) à l'expéditeur du paquet supprimé ; voir Section 3.2 de ICMPv6.
10.2. Considérations ECN
Si un point de terminaison de relais IP avec une connexion contenant un flux de requête de relais IP désactive le contrôle de congestion, il ne peut pas signaler la prise en charge de la notification explicite de congestion (ECN) [ECN] sur cette connexion externe. C'est-à-dire que l'expéditeur QUIC DOIT marquer tous les en-têtes IP avec le point de code Not ECN-Capable Transport (Not-ECT) (Transport non compatible ECN) pour les paquets QUIC qui sont en dehors du contrôle de congestion. Le point de terminaison peut toujours signaler les commentaires ECN via des trames QUIC ACK_ECN ou le bit TCP ECN-Echo (ECE), car le pair pourrait ne pas avoir désactivé le contrôle de congestion.
Inversement, si le contrôle de congestion n'est pas désactivé sur la congestion externe, les conseils de [ECN-TUNNEL] concernant le transfert des marques ECN entre les en-têtes IP internes et externes ne s'appliquent pas car la connexion externe réagira correctement aux notifications de congestion si elle utilise ECN. Le trafic interne peut également utiliser ECN, indépendamment de son utilisation sur la connexion externe.
10.3. Considérations sur les services différenciés
Les paquets IP tunnelisés peuvent avoir des points de code de services différenciés (DSCP) [DSCP] définis dans le champ d'en-tête IP de classe de trafic pour demander un comportement par saut particulier. Si un point de terminaison de relais IP est configuré dans le cadre d'un domaine de services différenciés, il PEUT implémenter une différenciation de trafic basée sur ces marquages. Cependant, l'utilisation de HTTP peut limiter les possibilités de traitement différencié des paquets IP tunnelisés sur le chemin entre les points de terminaison de relais IP.
Lorsqu'une connexion HTTP est contrôlée en congestion, marquer des paquets avec différents DSCP peut conduire à un réordonnancement entre eux, et cela peut à son tour conduire le contrôleur de congestion de la connexion de transport sous-jacente à avoir de mauvaises performances. Si les paquets tunnelisés sont soumis au contrôle de congestion par la connexion externe, ils doivent éviter de porter des marquages DSCP qui ne sont pas équivalents en comportement de transfert pour éviter cette situation. Dans ce scénario, le point de terminaison de relais IP NE DOIT PAS copier le champ DSCP de l'en-tête IP interne vers l'en-tête IP externe du paquet transportant ce paquet. Au lieu de cela, une application devrait utiliser des connexions séparées vers le proxy, une pour chaque DSCP. Notez que ce document ne définit pas de moyen pour que les requêtes soient limitées à des valeurs DSCP particulières ; un tel support est laissé aux extensions futures.
Si les paquets tunnelisés utilisent des datagrammes QUIC et ne sont pas soumis au contrôle de congestion par la connexion externe, les points de terminaison de relais IP PEUVENT traduire la valeur du champ DSCP du trafic tunnelisé vers l'en-tête IP externe. Les points de terminaison de relais IP NE DOIVENT PAS fusionner plusieurs paquets internes dans le même paquet externe à moins qu'ils n'aient le même marquage DSCP ou une classe de trafic équivalente. Notez que la capacité à traduire les valeurs DSCP dépend du fait que l'entrée et la sortie du tunnel appartiennent ou non au même domaine de services différenciés.