]> Smallstep

martenseemann@gmail.com

Web and Internet Transport Multiplexed Application Substrate over QUIC Encryption UDP ECN Proxying This document describes how to proxy the ECN bits when proxying UDP in HTTP. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Multiplexed Application Substrate over QUIC Encryption Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Explicit Congestion Notification marking uses two bits in the IP header to signal congestion from a network to endpoints. 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 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:

1. For UDP datagrams sent from the client to the proxy: To request the proxy to set the ECN marking on the UDP datagram sent to the target.
2. For UDP datagrams sent from the proxy to the client: To inform the client about the ECN marking of the UDP datagram received from the target.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Proxying ECN 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.

Sending UDP datagrams from the client to the proxy When sending UDP datagrams over the tunnel, the client uses the context identifier as negotiated during establishment of the tunnel (see ). 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 and .

Sending UDP datagrams from the proxy to the client 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.

Negotiating Extension and Registration of Context Identifiers 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" is an Item Structured Header . 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 three parameters: "ect1", "ect0", and "ce", each of which is of type sf-integer. The Not-ECT context ID always uses context ID 0. 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 . It is RECOMMENDED to use context identifier values that can be encoded using the same QUIC Variable-Length Integer encoding (see Section 16 of ). 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.

Optimistic Sending of ECN Markings allows the client to send UDP datagrams to the proxy without waiting for the proxy to send a response. This is useful for applications that need to send UDP datagrams to the proxy as soon as possible. When sending datagrams to the proxy, the client MAY optimistically use the context identifiers proposed in the "Proxy-ECN" header field. However, these datagrams will be dropped if the server does not enable ECN mode. This is therefore only recommended if the client has prior knowledge that the server likely supports ECN mode. A client that wishes to avoid the loss of packets if ECN mode is not enabled SHOULD NOT optimistically use the context identifiers proposed in the "Proxy-ECN" header field.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

Normative References This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK] This document describes how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo describes a Real-time Transport Protocol (RTP) payload format for the Society of Motion Picture and Television Engineers (SMPTE) ancillary space (ANC) data, as defined by SMPTE ST 291-1. SMPTE ANC data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD). This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.

Acknowledgments TODO acknowledge.