| Internet-Draft | CONNECT-UDP ECN | June 2025 |
| Seemann | Expires 1 January 2026 | [Page] |
This document describes how to proxy the ECN bits when proxying UDP in HTTP.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://marten-seemann.github.io/draft-seemann-masque-connect-udp-ecn/draft-seemann-masque-connect-udp-ecn.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-seemann-masque-connect-udp-ecn/.¶
Discussion of this document takes place on the Multiplexed Application Substrate over QUIC Encryption Working Group mailing list (mailto:masque@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/masque/. Subscribe at https://www.ietf.org/mailman/listinfo/masque/.¶
Source for this draft and an issue tracker can be found at https://github.com/marten-seemann/draft-seemann-masque-connect-udp-ecn.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Explicit Congestion Notification marking [RFC3168] uses two bits in the IP header to signal congestion from a network to endpoints.¶
[RFC9298] describes how UDP datagrams can be proxied in HTTP. This allows the proxying of the payload of UDP datagrams, however, it is not possible to proxy the ECN bits. This document defines an extension to [RFC9298] that allows the proxying of the ECN bits without imposing any encoding overhead.¶
When establishing a tunnel, the client registers four context identifiers, one for each ECN marking. These context identifiers are then used to:¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The proxy fulfills a dual role: First, it sends UDP datagrams received from the client over HTTP to the target, and sends UDP datagrams received from the target over HTTP to the client. Second, it also acts as a router that can experience congestion in both directions.¶
When sending UDP datagrams over the tunnel, the client uses the context identifier as negotiated during establishment of the tunnel (see Section 4). Under normal circumstances, the proxy MUST set the ECN marking on the UDP datagram sent to the target based on the context identifier. However, if the proxy is experiencing congestion on the link to the target, it SHOULD apply ECN markings according to [RFC3168] and [RFC8331].¶
When receiving UDP datagrams from the target, the proxy uses the context identifier negotiated during establishment of the tunnel to indicate the ECN marking the UDP datagram was received with. Similarly, if the HTTP connection to the client is experiencing congestion, the proxy SHOULD apply ECN markings.¶
To support ECN mode, both clients and proxies need to include the "Proxy-ECN" header field. This indicates support for ECN mode and registers the context IDs.¶
proxy-ecn = ?1; not-ect = 2; ect1 = 100; ect0 = 1234; ce = 42¶
"Proxy-ECN" is an Item Structured Header [RFC8941]. Its value MUST be a boolean.¶
If the client wants to enable proxying of ECN markings, it sets the value to "?1". The client MUST add the following four parameters: "not-ect", "ect1", "ect0", and "ce", each of which is of type sf-integer. The values are used to register the context IDs for the different ECN markings. The numbers MUST be even according to the rules for context identifiers in Section 4 of [RFC9298].¶
It is RECOMMENDED to use context identifier values that can be encoded using the same QUIC Variable-Length Integer encoding (see Section 16 of [RFC9000]).¶
If the proxy wants to enable proxying of ECN markings, it sets the value to "?1". It MUST NOT add any of the four parameters defined above.¶
If the proxy wants to disable proxying of ECN markings, it either omits the "Proxy-ECN" header field or sets the value to "?0". This also refuses the registration of the context IDs.¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶