10. Überlegungen zur Leistung
Stoßweiser Verkehr kann oft zu zeitlich korrelierten Paketverlusten führen; dies kann wiederum zu suboptimalen Reaktionen von Überlastungskontrollmechanismen in Protokollen führen, die innerhalb des Tunnels laufen. Um dies zu vermeiden, SOLLTEN IP-Proxying-Endpunkte danach streben, eine Zunahme der Stoßhaftigkeit des IP-Verkehrs zu vermeiden; sie SOLLTEN Pakete NICHT in einer Weise in Warteschlangen stellen, die das Batching über das minimale Maß hinaus erhöht, das erforderlich ist, um Hardware-Offloads zu nutzen.
Wenn das Protokoll, das innerhalb des Tunnels läuft, Überlastungskontrolle verwendet (z. B. [TCP] oder [QUIC]), wird der geproxte Verkehr mindestens zwei verschachtelten Überlastungskontrollmechanismen unterliegen. Wenn getunnelte Pakete unter Verwendung von QUIC-DATAGRAM-Frames gesendet werden, KANN die äußere HTTP-Verbindung die Überlastungskontrolle für diejenigen Pakete deaktivieren, die nur QUIC-DATAGRAM-Frames enthalten, die IP-Pakete kapseln. Implementierer werden von der Lektüre der Anleitung in Abschnitt 3.1.11 von UDP-USAGE profitieren.
Wenn das Protokoll, das innerhalb des Tunnels läuft, Verlustbehebung verwendet (z. B. [TCP] oder [QUIC]) und die äußere HTTP-Verbindung über TCP läuft, wird der geproxte Verkehr mindestens zwei verschachtelten Verlustbehebungsmechanismen unterliegen. Dies kann die Leistung verringern, da beide manchmal unabhängig voneinander dieselben Daten erneut übertragen können. Um dies zu vermeiden, SOLLTE IP-Proxying über HTTP/3 durchgeführt werden, um die Nutzung des QUIC-DATAGRAM-Frames zu ermöglichen.
10.1. MTU-Überlegungen
Bei der Verwendung von HTTP/3 mit der QUIC-Datagramm-Erweiterung [DGRAM] werden IP-Pakete in QUIC-DATAGRAM-Frames übertragen. Da diese Frames nicht fragmentiert werden können, können sie nur Pakete bis zu einer bestimmten Länge übertragen, die durch die QUIC-Verbindungskonfiguration und die Pfad-MTU (PMTU) bestimmt wird. Wenn ein Endpunkt QUIC-DATAGRAM-Frames verwendet und versucht, ein IP-Paket durch den Tunnel zu leiten, das nicht in einen QUIC-DATAGRAM-Frame passt, SOLLTE der IP-Proxy das IP-Paket NICHT in einer DATAGRAM-Kapsel senden, da dies die Ende-zu-Ende-Unzuverlässigkeitseigenschaft zunichtemacht, von der Methoden wie Datagram Packetization Layer PMTU Discovery (DPLPMTUD) abhängen [DPLPMTUD]. In diesem Szenario SOLLTE der Endpunkt das IP-Paket verwerfen und eine ICMP Packet Too Big-Nachricht an den Absender des verworfenen Pakets senden; siehe Abschnitt 3.2 von ICMPv6.
10.2. ECN-Überlegungen
Wenn ein IP-Proxying-Endpunkt mit einer Verbindung, die einen IP-Proxying-Anforderungsstrom enthält, die Überlastungskontrolle deaktiviert, kann er die Unterstützung für Explicit Congestion Notification (ECN) [ECN] auf dieser äußeren Verbindung nicht signalisieren. Das heißt, der QUIC-Absender MUSS alle IP-Header mit dem Codepunkt Not ECN-Capable Transport (Not-ECT) für QUIC-Pakete markieren, die außerhalb der Überlastungskontrolle liegen. Der Endpunkt kann weiterhin ECN-Feedback über QUIC ACK_ECN-Frames oder das TCP ECN-Echo (ECE)-Bit melden, da der Peer die Überlastungskontrolle möglicherweise nicht deaktiviert hat.
Wenn umgekehrt die Überlastungskontrolle auf der äußeren Verbindung nicht deaktiviert ist, gilt die Anleitung in [ECN-TUNNEL] bezüglich der Übertragung von ECN-Markierungen zwischen inneren und äußeren IP-Headern nicht, da die äußere Verbindung korrekt auf Überlastungsbenachrichtigungen reagiert, wenn sie ECN verwendet. Der innere Verkehr kann ebenfalls ECN verwenden, unabhängig davon, ob es auf der äußeren Verbindung verwendet wird.
10.3. Überlegungen zu differenzierten Diensten
Getunnelte IP-Pakete können Differentiated Services Code Points (DSCPs) [DSCP] im Traffic-Class-IP-Header-Feld gesetzt haben, um ein bestimmtes Per-Hop-Verhalten anzufordern. Wenn ein IP-Proxying-Endpunkt als Teil einer Differentiated-Services-Domäne konfiguriert ist, KANN er eine Verkehrsdifferenzierung basierend auf diesen Markierungen implementieren. Die Verwendung von HTTP kann jedoch die Möglichkeiten für eine differenzierte Behandlung der getunnelten IP-Pakete auf dem Pfad zwischen den IP-Proxying-Endpunkten einschränken.
Wenn eine HTTP-Verbindung überlastungskontrolliert ist, kann das Markieren von Paketen mit unterschiedlichen DSCPs zu einer Umordnung zwischen ihnen führen, was wiederum dazu führen kann, dass der Überlastungskontrollmechanismus der zugrunde liegenden Transportverbindung schlecht abschneidet. Wenn getunnelte Pakete der Überlastungskontrolle durch die äußere Verbindung unterliegen, müssen sie vermeiden, DSCP-Markierungen zu tragen, die im Weiterleitungsverhalten nicht äquivalent sind, um diese Situation zu verhindern. In diesem Szenario DARF der IP-Proxying-Endpunkt das DSCP-Feld NICHT vom inneren IP-Header in den äußeren IP-Header des Pakets kopieren, das dieses Paket trägt. Stattdessen müsste eine Anwendung separate Verbindungen zum Proxy verwenden, eine für jeden DSCP. Beachten Sie, dass dieses Dokument keinen Weg definiert, wie Anforderungen auf bestimmte DSCP-Werte beschränkt werden können; eine solche Unterstützung bleibt zukünftigen Erweiterungen vorbehalten.
Wenn getunnelte Pakete QUIC-Datagramme verwenden und nicht der Überlastungskontrolle durch die äußere Verbindung unterliegen, KÖNNEN die IP-Proxying-Endpunkte den DSCP-Feldwert vom getunnelten Verkehr in den äußeren IP-Header übersetzen. IP-Proxying-Endpunkte DÜRFEN NICHT mehrere innere Pakete in dasselbe äußere Paket zusammenfassen, es sei denn, sie haben dieselbe DSCP-Markierung oder eine äquivalente Verkehrsklasse. Beachten Sie, dass die Fähigkeit, DSCP-Werte zu übersetzen, davon abhängt, ob der Tunneleingang und -ausgang zur selben Differentiated-Services-Domäne gehören oder nicht.