MASQUE M. Westerlund Internet-Draft Ericsson Intended status: Standards Track 7 July 2025 Expires: 8 January 2026 ECN and DSCP support for HTTPS's Connect-UDP draft-westerlund-masque-connect-udp-ecn-dscp-latest Abstract HTTP's Extended Connect's Connect-UDP protocol enables a client to proxy a UDP flow from the HTTP server towards a specified target IP address and UDP port. Both QUIC and RTP are transport protocols that uses UDP and have support Explicit Congestion Notification (ECN) by providing the necessary feedback. Thus, it is benefitial to enable an end-to-end QUIC connections or Real-time transport protocol (RTP) sessions to use ECN. This document specifies how ECN and DSCP can be supported through an extension to the Connect-UDP protocol for HTTP. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://gloinul.github.io/masque-ecn/#go.draft-westerlund-masque- connect-udp-ecn.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-westerlund-masque- connect-udp-ecn-dscp/. Discussion of this document takes place on the MASQUE 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/gloinul/masque-ecn. Status of This Memo 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 8 January 2026. Copyright Notice 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. Table of Contents 1. Introduction 2. Conventions 3. ECN-zero-byte Extension 4. DSCP/ECN Extension 5. Negotiating Extensions Usage 5.1. ECN-zero-byte Extension 5.1.1. HTTP Structured field 5.1.2. ECN Context ID Assignment Capsule 5.2. ECN/DSCP extension 5.2.1. HTTP Structured Header 5.2.2. DSCP/ECN Context ID Assignment Capsule 6. Tunnels and DSCP and ECN marking interactions 6.1. Tunnel Endpoint Marking 6.2. DSCP Remarking Considerations 6.3. Tunnel Transport Connection ECN Interactions and Congestion Control 6.4. Tunnel Transport Connection DSCP Interactions 6.5. Usage with the QUIC Aware Forwarding extension 7. Open Issues 8. IANA Considerations 8.1. HTTP Field Names 8.1.1. ECN-Context-ID 8.1.2. DSCP-ECN-Context-ID 8.2. HTTP Capsule Type 8.2.1. ECN_CONTEXT_ASSIGN 8.2.2. DSCP_ECN_CONTEXT_ASSIGN 9. Acknowledgments 10. References 10.1. Normative References 10.2. Informative References Author's Address 1. Introduction Connect-UDP as currently defined limits the Explicit Congestion Notification (ECN) [RFC3168] exchange between the HTTP server and the target. There is no support for carrying the ECN bits between the HTTP Connect-UDP client and the HTTP server proxying the UDP flow. Thus, it is not possible to establish the end-to-end ECN flow of information necessary to support either classic ECN [RFC3168] or L4S [RFC9484]. Diffserv [RFC2475] enables differential network treatment of packets. Connect-UDP as currently defined lacks support for carrying the value of the DSCP field [RFC2474] through the tunnel. As such additional extensions are needed to enable DSCP and ECN usage end-to-end for UDP-based transport protocols that are proxied by Connect-UDP extended connect over HTTP. This document specifies two such extensions: The ECN-zero-bytes extension without additional overhead by encoding the ECN value directly into the context ID; and the ECN/DSCP extension that carries both DSCP and ECN in the HTTP Datagram payload. For these two extensions negotiation is specified and a new Datagram context that carries the DSCP and ECN bits and the UDP payload instead of the context defined in [RFC9298]. An alternative to using this extension would be to use Connect-IP [RFC9484], however, that that approach carries a full IP header between the HTTP client and HTTP server which results in significantly more overhead compared to these extensions that add zero or one byte for ECN bits and DSCP values. To define a solution that can be combined with other extension and as such other contexts instead of redefining each combination with other extensions, the extensions defined in this document indicates not only the ECN and DSCP values but also the next following Context ID. The ECN-zero-bytes extension defines three additional Context ID values that are bound to a HTTP Datagram payload identifying Context ID and indicates if the packet was marked with ECT(0), ECT(1), or CE respectively. An endpoint should not enable both of the extension defined in this document as that would lead to confusion if both extension would indicate a different ECN value. 2. Conventions 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. 3. ECN-zero-byte Extension For a zero overhead encoding, the ECN bits can be indicated by using different context ID. At the same time the context ID indicates what context ID would otherwise have been used to identify the structure of the rest of the HTTP payload, which we call the payload- identifying conext ID or short payload ID. Often this isthe basic UDP payload context (context ID=0) as defined by [RFC9298]. The core of this solution is to define for a Connect-UDP stream additioanl Context IDs (A, B, and C) that are used to indicate the ECN values that are not Not-ECT, i.e. ECT(1), ECT(0), CE [RFC3168]. This idea is shown in Table 1. +==================+=========+===========+============+ | Context ID Value | ECN bit | ECN Value | Payload ID | +==================+=========+===========+============+ | 0 | 0b00 | Not-ECT | 0 | +------------------+---------+-----------+------------+ | A | 0b01 | ECT(1) | 0 | +------------------+---------+-----------+------------+ | B | 0b10 | ECT(0) | 0 | +------------------+---------+-----------+------------+ | C | 0b11 | CE | 0 | +------------------+---------+-----------+------------+ Table 1: ECN Encoding Table No new context ID value is defined to represent Not-ECT, as using a Context value without this extension by default would be not-ECT. Additionally context IDs are defined to represent the combination of an ECN value other than Not-ECT and the actual payload-identifying context ID. If the application uses more context ID values than just zero, additional context ID values need to be defined. This extension results in four times the number of conext IDs within one Connect-UDP stream. We expect that is acceptable in most cases as a total of 64 context IDs can be encoded as a single byte, thus resulting in no packet expansion. However for applications that have more than 16 original context IDs (including zero) it is recommened to use the ECN/DSCP extension Section 4 which only doubles the number of context IDs but requires an additional byte in the payload. A endpoint enabling this extension MUST define all three of the Not- ECT ECN values, even if the ECN-enables application expects that only one ECT value (and CE) is used. This is because of transmission errors or erronous remarking in the network where also the other ECT codepoint as well as Not-ECT may observed. Negotiation of the conetxt ID values is defined using both HTTP headers and capsulses in Section 4. 4. DSCP/ECN Extension The HTTP Datagram Payload format is defined in [RFC9484] as depicted below. UDP Proxying HTTP Datagram Payload { Context ID (i), UDP Proxying Payload (..) } Figure 1: ECN enabled UDP Proxying HTTP Datagram Format For the ECN/DSCP extension, the ECN/DSCP UDP Proxying Payload is defined in the following way: ECN/DSCP UDP Proxying Payload { DSCP(6), ECN(2), UDP Proxying Payload (..) # Payload per another Context ID definition } Figure 2: ECN/DSCP UDP Proxying Payload DSCP: six bits currently reserved, SHALL be set to zero (0) on transmission, and ignored on reception. ECN: A two bit field carrying the IP ECN bits as defined by Section 5 of [RFC3168] to be set or as received on the IP/UDP packet carrying the UDP Datagram payload included. UDP Proxying Payload: Another UDP Proxying Payload following the ECN carrying byte. This uses another Context ID as negotiated, e.g. Context ID 0. Thus enabling this byte to be combined with any other payload. This format used a negotiated context ID that MUST be non-zero. It MUST also negotiate the payload-identifying context ID. 5. Negotiating Extensions Usage This section defines capability negotation and Context ID configuration for the two defined extensions. Note that context IDs are defined as QUIC varints, see section 16 of [RFC9000] and do support value up to 4,611,686,018,427,387,903, which is larger than what an Structure Header Integer support, which is limited to 999,999,999,999,999. We forsee no issues with this limitations as context identifiers should primiarly use the single byte representation for efficiency reason, i.e. context IDs should rarely be above the value 63. 5.1. ECN-zero-byte Extension To use the ECN-zero-byte extension three context IDs need to be signaled in relation to a payload-identifying context ID. Each Actual configuration of an ECN signalled using a four tuple with the following format: ECN_CONTEXT_ASSIGNMENT { ECT_1_CONTEXT (i), ECT_0_CONTEXT (i), CE_CONTEXT (i), PAYLOAD_CONTEXT (i) } Figure 3: ECN CONTEXT ASSIGNMENT Format ECT_1_CONTEXT: The Context ID used to indicate the payload was marked with ECN value ECT(1). ECT_0_CONTEXT: The Context ID used to indicate the payload was marked with ECN value ECT(0). CE_CONTEXT: The Context ID used to indicate the payload was marked with ECN value CE. PAYLOAD_CONTEXT: The payload-identifiying context ID indicating the actual encoding of the start of the HTTP Datagram payload. 5.1.1. HTTP Structured field ECN-Context-ID is an Structured Header Field [RFC9651]. Its value is a list consisting of zero or more inner lists, where an inner list contains four integer items. The integer items MUST be non-negative as they are context IDs as defined in [RFC9298]. The four context IDs are the four defined in Figure 3 in that order. When the header is included in a Extended Connect Request, it indicates, first of all, support for this ECN extension. Secondly, is may define one or more 4-item inner lists of context IDs for the requestor-to-responder direction. If no context ID 4-item inner lists are included then this header only indicate support for the extension and the context IDs MAY be signaled using capsules. The responder MAY include the header in a response if the received request included the ECN-Context-ID header. If included in a response it defines the context IDs used in the responder-to- requestor direction. The following example indicates support of the ECN-zero-byte extension and defines two sets of context IDs, ID=5,6,7 (ECT(1), ECT(0),CE) combined with context ID 4, and context ID=1,2,3 combined with the default context ID 0 as defined in [RFC9298], i.e. a plain UDP Payload. ECN-Context-ID: (5,6,7,4), (1,2,3,0) Figure 4: Example of ECN-Context-ID header 5.1.2. ECN Context ID Assignment Capsule The DSCP_ECN_CONTEXT_ASSIGN capsule is used to assign conext ID values for the ECN-zero-byte extension. ECN_CONTEXT_ASSIGN Capsule { Type (i) = TBA_2 Length (i), ECN_CONTEXT ASSIGNMENT (..) ..., } Figure 5: ECN_CONTEXT_ASSIGN Capsule Format Type and Length are as defined by the HTTP Capsule specification Section 3.2 of [RFC9297]. The capsule value is the ECN_CONEXT_ASSIGNMENT defined above (see Figure 3). Thus, the capsule value consists of zero or more Context Assignment 4-item lists. 5.2. ECN/DSCP extension This defines the negotiation of the ECN/DSCP extension defined in Section 4. It defined both an HTTP header field (DSCP-ECN-CONTEXT) that can be included in the Extended Connect request as well as an capsule. 5.2.1. HTTP Structured Header DSCP-ECN-Context-ID is an Structured Header Field [RFC9651]. Its value is a list consisting of zero or more inner lists, where an inner list contains two integer items. The integer items MUST be non-negative as they are context IDs as defined by [RFC9298]. The first integer item is the context ID being defined, the second context ID is the payload-identifying context ID for the payload following the ECN byte. When the header is included in a Extended Connect Request it indicate, first of all, support for the ECN/DSCP extension. Secondly, is defines one or more context IDs that is defined for requestor to responder direction. If no context ID pairs are included then this header only indicate support for the extension and it may be configured using capsules. The responder MAY include the header in a response if the request include the DSCP-ECN-Context-ID header. If included in a response it defines thecContext IDs used in the responder-to-requestor direction. The following example indicates supoprt of the ECN/DSCP extension and defines three context IDs, context ID=1 is combined with 4, ID=2 with context ID 5 and ID=3 with the default ID=0 as defined in [RFC9298], i.e. a plain UDP payload. DSCP-ECN-Conext-ID: (1,4), (2,5), (3,0) Figure 6: Example of ECN-Context-ID header 5.2.2. DSCP/ECN Context ID Assignment Capsule The DSCP_ECN_CONTEXT_ASSIGN capsule is used to assign context ID values for the DSCP/ECN extension. DSCP_ECN_CONTEXT_ASSIGN Capsule { Type (i) = TBA_2 Length (i), CONTEXT ASSIGNMENT (..) ..., } Figure 7: DSCP_ECN_CONTEXT_ASSIGN Capsule Format Type and Length as defined by the HTTP Capsule specification in Section 3.2 of [RFC9297]. The capsule value is defined below. CONTEXT ASSIGNMENT { ASSIGNED_CONTEXT (i), NEXT_PAYLOAD_CONTEXT (i) } Figure 8: CONTEXT ASSIGNMENT Format The capsule value consists of zero or more CCONTEXT ASSIGNMENT pair values. Each pair consists of these two fields: ASSIGNED_CONTEXT: : The context ID identifying that the indicated HTTP datagram payload starts with the ECN/DSCP UDP Proxying Payload. NEXT_PAYLOAD_CONTEXT: The context ID identifying the following payload in each HTTP datagram after the ECN/DSCP UDP Proxying Payload. This capsule is sent by either endpoints to configure or extend the configuration of context IDs. The receiving HTTP endpoint MUST send back its corresponding DSCP_ECN_CONTEXT_ASSIGN capsule, which may be empty if the peer does not intend to provide any context IDs. 6. Tunnels and DSCP and ECN marking interactions 6.1. Tunnel Endpoint Marking When a tunnel endpoint of a Connect-UDP connection receives an IP/UDP packet and the ECN/DSCP extension is enabled, it copies the the six DSCP bits and the two ECN field bits from the IP header to the DSCP and ECN fields in the HTTP datagram payload using the respective Context ID. If the ECN-zero-byte extension is used, the two ECN bits in the incoming IP/UDP packet are used to select which context ID value should be used. For the ECN/DSCP extension a tunnel egress endpoint copies the DSCP and ECN extension field value into the IP/UDP packet it creates for this UDP Proxying payload. For the ECN-zero-byte extension, the conext ID value is used to determine which value to write in the outgoing IP/UDP packets ECN field. An Tunnel endpoint which is unable to read or set the ECN Field SHALL NOT enable the ECN extension. 6.2. DSCP Remarking Considerations The tunnel may interconnect two different adminstrative domains that use DSCP values differently. Thus, the endpoints likely need to perform remarking of the DSCP field values, similar as an inter domain router. Depending on use cases and deployment, an HTTP client can be in different network domains with different DSCP usages. An HTTP server that connects the HTTP client to different network domains may also need to support multiple external domains. These complications in handling DSCP makes it impossible to provide standarized remarking instructions. Instead the deployment will have to define if remarking is handled by the HTTP server, the HTTP client, or both considering the tunnel a specific network domain in itself. 6.3. Tunnel Transport Connection ECN Interactions and Congestion Control The primary goal of the ECN extension is to enable ECN usage between the proxy and the target and have the end-to-end transport react to that ECN. However, there are different potential models for how to provide ECN interactions for a tunnel, i.e. between the HTTP client and sever. Which one to use depends on how the tunnel is configured and what other support is implemented for the Connect-UDP protocol. For HTTP tunnels (that are not using HTTP/3 [RFC9114], HTTP/3 using data streams, or HTTP/3 with datagrams with congestion control), the each tunnel is one congestion-controlled transport connections. In this case, ECN needs to be enabled for each underlying transport connection independently. That means it is not possible to have a one-to-one marking between the lower layer ECN marking and the tunneled HTTP datagrams to avoid reacting twice, on the tunnel transport and in the end-to-end connection. Instead each HTTP hop needs to run an AQM to set ECN CE mark or drop the HTTP datagram. In other words, each HTTP transport connection is treated as one IP link on the end-to-end chain. For tunnels using HTTP/3 datagrams and where the QUIC connection disabled congestion control, as discsussed in Section 6 of [RFC9298], the ECN marking on the tunneled packets can be propogated between the IP packet of the transport connection and the end-to-end packet. This represents a specific implementation of IP-in-IP tunnels with tightly coupled shim Headers as discussed in [RFC9601]. This is implemented as Feed-Forward-and-Up as discussed in [RFC9599], and MUST use the normal mode on tunnel ingress, and follow the specified default behavior on egress as defined by [RFC6040]. 6.4. Tunnel Transport Connection DSCP Interactions For HTTP tunnels not using HTTP/3 [RFC9114], HTTP/3 using data streams, or HTTP/3 with datagrams but not disabling congestion control, the tunnel will consist of one or possibly several chained congestion controlled transport connections. These transport connections will only be able to use a single DSCP to avoid inconsistent network treatment that might confuse the congestion controller and retransmission mechanism. Thus, even if the tunneled packets are using different DSCP values, the transport connection will have to use a single DSCP; unless the Multipath extension for QUIC [I-D.ietf-quic-multipath] is used, where each path can have a different DSCP values. In this later case, packets with different DSCP values could be mapped to different paths with the approparite network treatment as indicated by the DSCP value. For tunnels using HTTP/3 datagram and where the QUIC connection diabled congestion control, as discsussed in Section 6 of [RFC9298], the QUIC packets could be marked using the most suitable DSCP value based on the encapsualted packet. In cases where the tunnel connection sents into a different network domains than the one the tunneled packet was received on, a suitable remapping needs to occur to the domain the tunnel packet will be sent to. The HTTP tunnel MUST not coalesce different tunneled payloads which are not mapped to the same DSCP value in the same QUIC packet. 6.5. Usage with the QUIC Aware Forwarding extension A HTTP endpoint that supports this extension and QUIC Aware Forwarding [I-D.ietf-masque-quic-proxy] MUST preserve ECN markings on forwarded packets in both directions, to ensure ECN functions end-to- end. Using this extension in combination with the QUIC Aware forwarding instead of only QUIC Aware forwarding also ensures that one does not get ECN black holes on some packets, like long header packets or for packets sent at any point when the QUIC Aware forwarding is not yet established for short header packets. Thus supporting both ensures a consistent ECN experience. 7. Open Issues * Is it the right mechanism to use an HTTP header with no configurations to indicate the capability to support later configuration using capsules? 8. IANA Considerations 8.1. HTTP Field Names IANA is request to register two new permanent Field name in the Hypertext Transfer Protocol (HTTP) Field Name Registry (At time of writing residing at: https://www.iana.org/assignments/http-fields/ http-fields.xhtml). 8.1.1. ECN-Context-ID Field Name: ECN-Context-ID Status: Permanent Structured Type: List Reference: [RFC-TO-BE] 8.1.2. DSCP-ECN-Context-ID Field Name: DSCP-ECN-Context-ID Status: Permanent Structured Type: List Reference: [RFC-TO-BE] 8.2. HTTP Capsule Type IANA is reqeusted ot register two new HTTP Capsule Types in the permanent range (0x00-0x3f). 8.2.1. ECN_CONTEXT_ASSIGN Value: TBA_1 Capsule Type: ECN_CONTEXT_ASSIGN Status: permanent Reference: RFC-TO-BE Change Controller: IETF Contact: MASQUE Working Group masque@ietf.org Notes: None 8.2.2. DSCP_ECN_CONTEXT_ASSIGN Value: TBA_2 Capsule Type: DSCP_ECN_CONTEXT_ASSIGN Status: permanent Reference: RFC-TO-BE Change Controller: IETF Contact: MASQUE Working Group masque@ietf.org Notes: None 9. Acknowledgments This draft takes insperation from David Schinazi's An ECN Extension to Connect-UDP [I-D.schinazi-masque-connect-udp-ecn]. 10. References 10.1. Normative References [I-D.ietf-masque-quic-proxy] Pauly, T., Rosenberg, E., and D. Schinazi, "QUIC-Aware Proxying Using HTTP", Work in Progress, Internet-Draft, draft-ietf-masque-quic-proxy-05, 3 March 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, . [RFC9297] Schinazi, D. and L. Pardue, "HTTP Datagrams and the Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August 2022, . [RFC9298] Schinazi, D., "Proxying UDP in HTTP", RFC 9298, DOI 10.17487/RFC9298, August 2022, . [RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. White, "Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture", RFC 9330, DOI 10.17487/RFC9330, January 2023, . [RFC9599] Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", BCP 89, RFC 9599, DOI 10.17487/RFC9599, August 2024, . [RFC9601] Briscoe, B., "Propagating Explicit Congestion Notification across IP Tunnel Headers Separated by a Shim", RFC 9601, DOI 10.17487/RFC9601, August 2024, . [RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, . 10.2. Informative References [I-D.ietf-quic-multipath] Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema, C., and M. Kühlewind, "Multipath Extension for QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-multipath-14, 23 April 2025, . [I-D.schinazi-masque-connect-udp-ecn] Schinazi, D., "An ECN Extension to CONNECT-UDP", Work in Progress, Internet-Draft, draft-schinazi-masque-connect- udp-ecn-02, 28 March 2022, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, . [RFC9484] Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A., Kühlewind, M., and M. Westerlund, "Proxying IP in HTTP", RFC 9484, DOI 10.17487/RFC9484, October 2023, . Author's Address Magnus Westerlund Ericsson Email: magnus.westerlund@ericsson.com