6. Considérations relatives aux performances
- Considérations relatives aux performances
Le trafic en rafale peut souvent entraîner des pertes de paquets temporellement corrélées ; à son tour, cela peut conduire à des réponses sous-optimales des contrôleurs de congestion dans les protocoles fonctionnant sur UDP. Pour éviter cela, les proxys UDP DEVRAIENT s'efforcer d'éviter d'augmenter la rafale du trafic UDP ; ils NE DEVRAIENT PAS mettre les paquets en file d'attente afin d'augmenter le traitement par lots.
Lorsque le protocole fonctionnant sur UDP qui est relayé utilise le contrôle de congestion (par exemple, [QUIC]), le trafic relayé subira au moins deux contrôleurs de congestion imbriqués. La connexion HTTP sous-jacente NE DOIT PAS désactiver le contrôle de congestion à moins d'avoir un moyen hors bande de savoir avec une certitude absolue que le trafic interne est contrôlé par congestion.
Si un client ou un proxy UDP avec une connexion contenant un flux de requête de proxy UDP désactive le contrôle de congestion, il NE DOIT PAS signaler la prise en charge de la notification explicite de congestion (ECN) [ECN] sur cette connexion. C'est-à-dire qu'il DOIT marquer tous les en-têtes IP avec le point de code Not-ECT. Il PEUT continuer à signaler les commentaires ECN via des trames QUIC ACK_ECN ou le bit TCP ECE, car le pair peut ne pas avoir désactivé le contrôle de congestion.
Lorsque le protocole fonctionnant sur UDP qui est relayé utilise la récupération de perte (par exemple, [QUIC]), et que la connexion HTTP sous-jacente fonctionne 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 UDP DEVRAIT être effectué sur HTTP/3 pour permettre de tirer parti de la trame QUIC DATAGRAM.
6.1. Considérations relatives au MTU
Lors de l'utilisation de HTTP/3 avec l'extension de datagramme QUIC [QUIC-DGRAM], les charges utiles UDP sont transmises dans des trames QUIC DATAGRAM. Comme celles-ci ne peuvent pas être fragmentées, elles ne peuvent transporter que des charges utiles jusqu'à une longueur donnée déterminée par la configuration de la connexion QUIC et le MTU du chemin (PMTU). Si un proxy UDP utilise des trames QUIC DATAGRAM et qu'il reçoit une charge utile UDP de la cible qui ne rentre pas dans une trame QUIC DATAGRAM, le proxy UDP NE DEVRAIT PAS envoyer la charge utile UDP 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 de PMTU de couche de paquetisation de datagramme (DPLPMTUD) [DPLPMTUD]. Dans ce scénario, le proxy UDP DEVRAIT abandonner la charge utile UDP et envoyer un message ICMP Packet Too Big à la cible ; voir la section 3.2 de [ICMP6].
6.2. Tunnelisation des marques ECN
Le relais UDP ne crée pas de tunnel IP-dans-IP, donc les conseils de [ECN-TUNNEL] concernant le transfert des marques ECN entre les en-têtes IP internes et externes ne s'appliquent pas. Il n'y a pas d'en-tête IP interne dans les tunnels de proxy UDP.
Dans cette spécification, notez que les clients de proxy UDP n'ont pas la capacité de contrôler les points de code ECN sur les paquets UDP que le proxy UDP envoie à la cible, et les proxys UDP ne peuvent pas non plus communiquer les marquages de chaque paquet UDP de la cible au proxy UDP.
Un proxy UDP DOIT ignorer les bits ECN dans l'en-tête IP des paquets UDP reçus de la cible, et il DOIT définir les bits ECN sur Not-ECT sur les paquets UDP qu'il envoie à la cible. Ceux-ci ne sont en aucun cas liés aux marquages ECN des paquets envoyés entre le client et le proxy UDP.