MASQUE M. Westerlund Internet-Draft Ericsson Intended status: Standards Track 9 June 2025 Expires: 11 December 2025 ECN and DSCP support for HTTPS's Connect-UDP draft-westerlund-masque-connect-udp-ecn-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 for using ECN and providing the necessary feedback. Thus, there exist a benefit to enable an end-to-end QUIC or RTP transport protocol connection/session to be able 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/. 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 11 December 2025. 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 Encoded in Context ID 4. DSCP and ECN enabled UDP Proxying Payload 5. Negotiating Extensions Usage 5.1. ECN Signaled using Context IDs 5.1.1. HTTP Structured field 5.1.2. ECN CID Assignment Capsule 5.2. ECN and DSCP enabled UDP Proxying Payload 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 6.4. Tunnel Transport Connection DSCP Interactions 6.5. QUIC Aware Forwarding 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_CID_ASSIGN 8.2.2. DSCP_ECN_CID_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 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 make either ECN classic [RFC3168] or L4S [RFC9484] function. Diffserv architecture [RFC2475] enables different network treatment of packets. Connect-UDP as currently defined lacks support for carrying the value of the DSCP field [RFC2474] through the tunnel. To enable DSCP and ECN usage end-to-end for transport protocols using UDP and being proxied using the Connect-UDP extended connect over HTTP additional extensions are needed. This document specifies the necessary extension, defining two methods, one possible having no additional overhead by encoding only ECN in the context ID, the other carrying 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 results in that one carries a full IP header between the HTTP client and HTTP server. That results in significantly more overhead compared to this extension that adds zero or one byte for containing both the DSCP and ECN bits. To define a solution that can be combined with other contexts and avoid having to be redefined for each combination with other extensions this defines context IDs that indicates that it carries the ECN and DSCP and then is followed by another Context ID. The ECN encoding in the context ID configures three additional Context ID values that are bound to a HTTP Datagram payload idefnitying 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 alternatives in this document as that would lead to confusion on when to use the DSCP carrying extension. 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 Encoded in Context ID For a likely zero overhead encoding of the ECN bits, the ECN bits can be indicated by using different context ID values followed by the context that would otherwise have been used, often the basic UDP payload context (CID=0) as defined by [RFC9298]. The core of this solution is to define for a Connect-UDP stream define 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. +===========+=========+===========+====================+ | CID Value | ECN bit | ECN Value | Original CID Value | +===========+=========+===========+====================+ | 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 CID value is defined to represent Not-ECT, as using a Context value without this extension by default would be not-ECT. Then additionally CIDs are defined to represent the combination of an ECN value other than Not-ECT and the actual payload identification context ID. If the application used more CID values than just zero, then additional CID values will have to be defined. This extension is likely to result in three times additioanl CIDs will be needed in the Connect-UDP stream. We expect that this will be acceptable in most cases as a total of 64 CIDs can be encoded as a single byte, thus resulting in no packet expansion. However for applications that has more than 16 original CIDs (including zero) it is possible to consider using the ECN and DSCP context Section 4 which only double the number of CIDs but requires an additional byte in the payload. A endpoint enabling this extension MUST define all three of the Not- ECT ECN values. This despite that an ECN application working as intened would expect to see only the one ECT value the endpoint uses and the CE code. However, if there are transmission errors or erronous remarking in the network, also the other ECT codepoint as well as Not-ECT may be needed to transmitt. Negotiation of the CID values to use are defined using both HTTP headers and Capsulses in Section 4. 4. DSCP and ECN enabled UDP Proxying Payload 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 The DSCP and ECN carrying UDP Proxying Payload is defined in the following way: ECN carrying UDP Proxying Payload { DSCP(6), ECN(2), UDP Proxying Payload (..) # Payload per another Context ID definition } Figure 2: ECN carrying 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 will use a negotiated context ID that MUST be non-zero. It also MUST negotiate what the context ID of the UDP Proxying payload included. 5. Negotiating Extensions Usage This section defines capability negotation and Context ID configuration for the two defined extensions. Note that Context Identifiers 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 be using the single byte representation for efficiency reason, i.e. Context Identifers should rarely be above the value 63. 5.1. ECN Signaled using Context IDs To configure the ECN Signaled using Context IDs three context IDs need to be configured in relation to a Context ID that identified the actual HTTP Datagram Payload. Each Actual configuration of an ECN signalled using a four tuple with the following format: ECN_CID_ASSIGNMENT { ECT_1_CID (i), ECT_0_CID (i), CE_CID (i), PAYLOAD_CID (i) } Figure 3: ECN CID ASSIGNMENT Format ECT_1_CID: The Context ID used to indicate the payload was marked with ECN value ECT(1). ECT_0_CID: The Context ID used to indicate the payload was marked with ECN value ECT(0). CE_CID: The Context ID used to indicate the payload was marked with ECN value CE. PAYLOAD_CID: The 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 the Inner List contains four Integer Items. The Integer Items MUST be non-negative as they are context Identifiers as defined by [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 indicate first of all support for this ECN extension. Secondly is may defines one or more four tuples of context IDs that is defined for requestor to responder direction. If no context ID four tuples are included then this header only indicate support for the extension and it may be configured using capsules. The responder MAY if the request include the ECN-Context-ID header include the header in a response. If included in a response it defines the Context ID used in the responder to requestor direction. ECN-Context-ID: (5,6,7,4), (1,2,3,0) Figure 4: Example of ECN-Context-ID header The above example indicate supoprt of the ECN signaled using Context IDs and defines two sets of Context IDs, ID=5,6,7 (ECT(1), ECT(0),CE) combined with Context ID 4, Context ID=1,2,3 which is combined with the default ID=0 as defined in [RFC9298], i.e. a plain UDP Payload. 5.1.2. ECN CID Assignment Capsule The DSCP_ECN_CID_ASSIGN capsule is used to assign CID values to the DSCP & ECN UDP Proxying payload. ECN_CID_ASSIGN Capsule { Type (i) = TBA_2 Length (i), ECN_CID ASSIGNMENT (..) ..., } Figure 5: ECN_CID_ASSIGN Capsule Format Type and Length as defined by the HTTP Capsule specification Section 3.2 of [RFC9297]. The capsule value is the ECN_CID ASSIGNMENT defined above Figure 3. Thus, the capsule value consists of zero or more CID Assignment four tupless. 5.2. ECN and DSCP enabled UDP Proxying Payload This defines the negotiation of the ECN and DSCP enabled UDP Proxying Payload extension defined in Section 4. It defined both an HTTP header field (DSCP-ECN-Context-ID) that can be included in the Extended Connect request. It also defines 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 the Inner List contains two Integer Items. The Integer Items MUST be non-negative as they are context Identifiers as defined by [RFC9298]. The first Integer Item is the Context ID being defined, the second Context ID is the 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 this ECN extension. Secondly is may 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 if the request include the DSCP-ECN-Context-ID header include the header in a response. If included in a response it defines the Context ID used in the responder to requestor direction. DSCP-ECN-Context-ID: (1,4), (2,5), (3,0) Figure 6: Example of ECN-Context-ID header The above example indicate supoprt of the ECN byte context 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. 5.2.2. DSCP ECN Context ID Assignment Capsule The DSCP_ECN_CID_ASSIGN capsule is used to assign CID values to the DSCP & ECN UDP Proxying payload. DSCP_ECN_CID_ASSIGN Capsule { Type (i) = TBA_2 Length (i), CID ASSIGNMENT (..) ..., } Figure 7: DSCP_ECN_CID_ASSIGN Capsule Format Type and Length as defined by the HTTP Capsule specification Section 3.2 [RFC9297]. The capsule value is defined below. CID ASSIGNMENT { ASSIGNED_CID (i), NEXT_PAYLOAD_CID (i) } Figure 8: CID ASSIGNMENT Format The capsule value consists of zero or more CID Assignment pair values. Each pair consists of these two fields: ASSIGNED_CID: : The CID identifying that the indicated HTTP datagram payload starts with the DSCP ECN UDP Proxying Payload. NEXT_PAYLOAD_CID: The CID identifying the following payload in each HTTP datagram after the DSCP ECN UDP Proxying Payload. This capsule is sent by either endpoints to configure or extend the configuration of CIDs which it intends to send. The receiving HTTP endpoint MUST send back its corresponding DSCP_ECN_CID_ASSIGN capsule, which may be empty if the peer does not intended to send any. 6. Tunnels and DSCP and ECN marking interactions 6.1. Tunnel Endpoint Marking The Tunnel Endpoint when receiving an IP/UDP packet that is belonging to an Connect-UDP request where the ECN+DSCP extension is enabled copies the the six DSCP bits and the two ECN field bits from the IP header to the DSCP and ECN fields respectively in the HTTP datagram payload using the relevant Context ID. If using the ECN only extension the two ECN bits in the incoming IP/UDP packet are used to select which CID value should be used. For the DSCP+ECN extension a Tunnel endpoint on egress copies the DSCP and ECN extension field value into the IP/UDP packet it creates for this UDP Proxying payload. For the ECN extension the CID 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 uses the DSCP values differently. Thus, the endpoints likely need to perform remarking of the DSCP field values the same as a inter domain router would. Depending on use cases and deployment the HTTP client can be in different actual network domains with different DSCP usages. An HTTP server that based on user identification connects the HTTP client to different network domains behind it may also need to support multiple external domains. The above complications in handling DSCP makes it impossible to provide a standarized remarking instruction. 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 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 exist different potential models for how to provide ECN interactions for the tunnel, i.e. between HTTP client and sever. Which to do depends on how the tunnel is configured and what other support one have implemented for the Connect-UDP protocol. 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. In this case ECN may be enabled for each underlying transport connection independently. However, it in this case it is not possible to have a one-to-one marking between the lower layer ECN marking and the tunneled HTTP datagrams and avoid reacting both on the tunnel transport and in the end-to-end. Instead the only real choice to have each HTTP layer hop run an ECN marking AQM goverened by what it can transmit over the transport connection that marks the ECN field in the HTTP datagram or drops the HTTP datagram when a queue builds. In other words each HTTP transport connection is treated as one IP link on the end-to-end chain. For tunnels using HTTP/3 and Datagram and where the QUIC connection is disabling congestion control on the packets containing HTTP datagrams, as discsussed in Section 6 of [RFC9298], then 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 reprensts 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 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 code point to avoid inconsistent network treatment that might confuse the congestion controller and retransmission mechanism. Thus, even if the tunneled packets are using different DSCP, the transport connection will have to settle for using a single DSCP of suitable value. This unless the Multipath extension for QUIC [I-D.ietf-quic-multipath] is used, where each path can have a different DSCP value. 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 and Datagram and where the QUIC connection is disabling congestion control on the packets containing HTTP datagrams, 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 is sent in a different network domain 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 in the same QUIC packet. 6.5. QUIC Aware Forwarding 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 ensure that one don't get ECN black holes on some packets, like long header packets or for packets sent at any point when the QUIC Aware forwarding isn't 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_CID_ASSIGN Value: TBA_1 Capsule Type: ECN_CID_ASSIGN Status: permanent Reference: RFC-TO-BE Change Controller: IETF Contact: MASQUE Working Group masque@ietf.org Notes: None 8.2.2. DSCP_ECN_CID_ASSIGN Value: TBA_2 Capsule Type: DSCP_ECN_CID_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