10. Performance Considerations
Bursty traffic can often lead to temporally correlated packet losses; in turn, this can lead to suboptimal responses from congestion controllers in protocols running inside the tunnel. To avoid this, IP proxying endpoints SHOULD strive to avoid increasing burstiness of IP traffic; they SHOULD NOT queue packets in order to increase batching beyond the minimal amount required to take advantage of hardware offloads.
When the protocol running inside the tunnel uses congestion control (e.g., [TCP] or [QUIC]), the proxied traffic will incur at least two nested congestion controllers. When tunneled packets are sent using QUIC DATAGRAM frames, the outer HTTP connection MAY disable congestion control for those packets that contain only QUIC DATAGRAM frames encapsulating IP packets. Implementers will benefit from reading the guidance in Section 3.1.11 of UDP-USAGE.
When the protocol running inside the tunnel uses loss recovery (e.g., [TCP] or [QUIC]) and the outer HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms. This can reduce performance, as both can sometimes independently retransmit the same data. To avoid this, IP proxying SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM frame.
10.1. MTU Considerations
When using HTTP/3 with the QUIC Datagram extension [DGRAM], IP packets are transmitted in QUIC DATAGRAM frames. Since these frames cannot be fragmented, they can only carry packets up to a given length determined by the QUIC connection configuration and the Path MTU (PMTU). If an endpoint is using QUIC DATAGRAM frames and it attempts to route an IP packet through the tunnel that will not fit inside a QUIC DATAGRAM frame, the IP proxy SHOULD NOT send the IP packet in a DATAGRAM capsule, as that defeats the end-to-end unreliability characteristic that methods such as Datagram Packetization Layer PMTU Discovery (DPLPMTUD) depend on [DPLPMTUD]. In this scenario, the endpoint SHOULD drop the IP packet and send an ICMP Packet Too Big message to the sender of the dropped packet; see Section 3.2 of ICMPv6.
10.2. ECN Considerations
If an IP proxying endpoint with a connection containing an IP proxying request stream disables congestion control, it cannot signal Explicit Congestion Notification (ECN) [ECN] support on that outer connection. That is, the QUIC sender MUST mark all IP headers with the Not ECN-Capable Transport (Not-ECT) codepoint for QUIC packets that are outside of congestion control. The endpoint can still report ECN feedback via QUIC ACK_ECN frames or the TCP ECN-Echo (ECE) bit, as the peer might not have disabled congestion control.
Conversely, if congestion control is not disabled on the outer congestion, the guidance in [ECN-TUNNEL] about transferring ECN marks between inner and outer IP headers does not apply because the outer connection will react correctly to congestion notifications if it uses ECN. The inner traffic can also use ECN, independently of whether it is in use on the outer connection.
10.3. Differentiated Services Considerations
Tunneled IP packets can have Differentiated Services Code Points (DSCPs) [DSCP] set in the traffic class IP header field to request a particular per-hop behavior. If an IP proxying endpoint is configured as part of a Differentiated Services domain, it MAY implement traffic differentiation based on these markings. However, the use of HTTP can limit the possibilities for differentiated treatment of the tunneled IP packets on the path between the IP proxying endpoints.
When an HTTP connection is congestion-controlled, marking packets with different DSCPs can lead to reordering between them, and that can in turn lead the underlying transport connection's congestion controller to perform poorly. If tunneled packets are subject to congestion control by the outer connection, they need to avoid carrying DSCP markings that are not equivalent in forwarding behavior to prevent this situation. In this scenario, the IP proxying endpoint MUST NOT copy the DSCP field from the inner IP header to the outer IP header of the packet carrying this packet. Instead, an application would need to use separate connections to the proxy, one for each DSCP. Note that this document does not define a way for requests to scope to particular DSCP values; such support is left to future extensions.
If tunneled packets use QUIC datagrams and are not subject to congestion control by the outer connection, the IP proxying endpoints MAY translate the DSCP field value from the tunneled traffic to the outer IP header. IP proxying endpoints MUST NOT coalesce multiple inner packets into the same outer packet unless they have the same DSCP marking or an equivalent traffic class. Note that the ability to translate DSCP values is dependent on the tunnel ingress and egress belonging to the same Differentiated Service domain or not.