< draft-schinazi-masque-connect-udp-ecn-01.txt   draft-schinazi-masque-connect-udp-ecn-02.txt >
Network Working Group D. Schinazi MASQUE D. Schinazi
Internet-Draft Google LLC Internet-Draft Google LLC
Intended status: Standards Track 5 January 2021 Intended status: Standards Track 28 March 2022
Expires: 9 July 2021 Expires: 29 September 2022
An ECN Extension to CONNECT-UDP An ECN Extension to CONNECT-UDP
draft-schinazi-masque-connect-udp-ecn-01 draft-schinazi-masque-connect-udp-ecn-02
Abstract Abstract
The CONNECT-UDP method allows proxying UDP packets over HTTP. This CONNECT-UDP allows proxying UDP packets over HTTP. This document
document describes an extension to CONNECT-UDP that allows conveying describes an extension to CONNECT-UDP that allows conveying ECN
ECN information on proxied UDP packets. information on proxied UDP packets.
Discussion of this work is encouraged to happen on the MASQUE IETF
mailing list (masque@ietf.org (mailto:masque@ietf.org)) or on the
GitHub repository which contains the draft:
https://github.com/DavidSchinazi/draft-connect-udp-ecn.
Discussion Venues Discussion Venues
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at Source for this draft and an issue tracker can be found at
https://github.com/DavidSchinazi/draft-connect-udp-ecn. https://github.com/DavidSchinazi/draft-connect-udp-ecn.
Status of This Memo Status of This Memo
skipping to change at page 1, line 44 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 July 2021. This Internet-Draft will expire on 29 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 2 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 2
2. ECN Header Definition . . . . . . . . . . . . . . . . . . . . 3 2. Context Identifiers . . . . . . . . . . . . . . . . . . . . . 2
3. Datagram Encoding of Proxied UDP Packets . . . . . . . . . . 3 3. ECN Header Definition . . . . . . . . . . . . . . . . . . . . 3
4. Stream Encoding of Proxied UDP Packets . . . . . . . . . . . 4 4. Encoding of ECN bits . . . . . . . . . . . . . . . . . . . . 3
5. HTTP Intermediaries . . . . . . . . . . . . . . . . . . . . . 4 5. A Note about Future Extensions . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 5
7.2. Flow Identifier Parameters . . . . . . . . . . . . . . . 5
7.3. Stream Chunk Type Registration . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
The CONNECT-UDP [CONNECT-UDP] method allows proxying UDP packets over CONNECT-UDP [CONNECT-UDP] allows proxying UDP packets over HTTP.
HTTP. This document describes an extension to CONNECT-UDP that This document describes an extension to CONNECT-UDP that allows
allows conveying ECN [ECN] information on proxied UDP packets. conveying ECN [ECN] information on proxied UDP packets.
Discussion of this work is encouraged to happen on the MASQUE IETF
mailing list (masque@ietf.org (mailto:masque@ietf.org)) or on the
GitHub repository which contains the draft:
https://github.com/DavidSchinazi/draft-connect-udp-ecn.
1.1. Conventions and Definitions 1.1. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. ECN Header Definition 2. Context Identifiers
"ECN" is a Item Structured Header [STRUCT-HDR]. Its value MUST be a The "Context Identifiers" section of [CONNECT-UDP] defines the
Boolean. Its ABNF is: concept of context IDs and how they can be used to extend CONNECT-
UDP. When a client wishes to use ECN with CONNECT-UDP, it generates
an unique client-allocated context ID. In this document, we'll refer
to that context ID as the "chosen context ID". Note that, by
definition of client-allocated context IDs, the chosen context ID
will always be a non-zero even number. We also add the restriction
that the chosen context ID MUST be strictly less than 10^15. If the
client has run out of available context ID values that match this
requirement for this CONNECT-UDP request, it MUST NOT use the ECN
extension with this CONNECT-UDP request.
ECN = sf-boolean 3. ECN Header Definition
The "ECN" header indicates whether the sender supports this The "ECN" header field is an Item Structured Field, see Section 3.3
extension. A value of 1 indicates support whereas a value of 0 (or of [STRUCT-FIELD]; its value MUST be a Integer; any other value type
the absence of the header) indicates lack of support. MUST be handled as if the field were not present by recipients (for
example, if this field is included multiple times, its type will
become a List and the field will therefore be ignored). This
document does not define any parameters for the "ECN" header field
value, but future documents might define parameters. Receivers MUST
ignore unknown parameters.
When present, the "ECN" header indicates that the sender supports
this extension, and communicates the chosen context ID as the "ECN"
field value.
For example, if the client chosen context ID is 42, it would send the
following:
ECN: 42; foo=bar
Figure 1: Example Client ECN Field
Clients MUST NOT indicate support for this extension unless they know Clients MUST NOT indicate support for this extension unless they know
that the protocol running over UDP that is being proxied supports that the protocol running over UDP that is being proxied supports
ECN, and will react appropriately to Congestion Experienced (CE) ECN, and will react appropriately to Congestion Experienced (CE)
markings. markings.
Proxies MUST NOT indicate support for this extension unless they know Proxies MUST NOT indicate support for this extension unless they know
they have the ability to read and write the IP ECN bits on its they have the ability to read and write the IP ECN bits on its
target-bound UDP sockets. target-bound UDP sockets.
This extension is said to have been negotiated when both client and This extension is said to have been negotiated when both client and
proxy indicated support for it in their CONNECT-UDP request and proxy indicated support for it in their CONNECT-UDP request and
response. response. When indicating support for this extension, the proxy send
the client's chosen context ID as the "ECN" field value.
3. Datagram Encoding of Proxied UDP Packets For example, the proxy could reply with:
If a client supports this extension and HTTP/3 datagrams [H3DGRAM], ECN: 42
it can attempt to use datagrams for ECN information. This is done by
allocating four datagram flow identifiers (as opposed to one in
traditional CONNECT-UDP) and communicating them to the proxy using
named elements on the "Datagram-Flow-Id" header. These names are
"ecn-ect0", "ecn-ect1", and "ecn-ce". For example:
Datagram-Flow-Id = 42, 44; ecn-ect0, 46; ecn-ect1, 48; ecn-ce Figure 2: Example Proxy ECN Field
If the proxy wishes to support datagram encoding of this extension, 4. Encoding of ECN bits
it echoes those named elements in its CONNECT-UDP response. The
unnamed element now represents Not-ECT, whereas the one in "ecn-ect0"
represents ECT(0), "ecn-ect1" represents ECT(1) and "ecn-ce"
represents CE; see Section 5 of [ECN] for the definition of these IP
header fields.
When the proxy receives a datagram from the given flow identifier, it When an HTTP Datagram [HTTP-DGRAM] associated with a CONNECT-UDP
sets the IP packet's ECN bits accordingly on the UDP packet it sends stream uses the chosen context ID as its context ID, its "Payload"
to the target. Similarly, in the other direction the flow identifier field contains the following format (using the notation from the
represents which ECN bits were seen on the UDP packets received from "Notational Conventions" section of [QUIC]):
the target.
4. Stream Encoding of Proxied UDP Packets CONNECT-UDP Payload with ECN {
Must be Zero (6),
ECN Bits (2),
UDP Payload (..),
}
If HTTP/3 datagrams are not supported, the stream is used to convey Figure 3: CONNECT-UDP Payload with ECN
UDP payloads, and the CONNECT-UDP Stream Chunk Type is used to
indicate the values of the ECN bits, as defined below:
+-------+-----------------+-----------+ Must be Zero: 6 bits that MUST be sent as zero. Receivers MUST
| Value | Type | ECN Field | validate that these bits are zero and MUST silently drop the HTTP
+-------+-----------------+-----------+ Datagram if they have any other value. Extensions to this
| 0x00 | UDP_PACKET | Not-ECT | mechanism MAY relax this requirement.
+-------+-----------------+-----------+
| 0x31 | UDP_PACKET_ECT0 | ECT(0) |
+-------+-----------------+-----------+
| 0x32 | UDP_PACKET_ECT1 | ECT(1) |
+-------+-----------------+-----------+
| 0x33 | UDP_PACKET_CE | CE |
+-------+-----------------+-----------+
The proxy then uses the the CONNECT-UDP Stream Chunk Type on received ECN Bits: The ECN bits, sent in the same order as they appear in the
UDP payloads to set the ECN bits on the IP packets it sends to the IP header.
target, and in the reverse direction to indicate which ECN bits
received from the target.
5. HTTP Intermediaries UDP Payload: The UDP Payload, as defined in the "HTTP Datagram
Payload Format" section of [CONNECT-UDP].
HTTP/3 DATAGRAM flow identifiers are specific to a given HTTP/3 When the proxy receives a datagram with the chosen context ID, it
connection. However, in some cases, an HTTP request may travel sets the IP packet's ECN bits accordingly on the UDP packet it sends
across multiple HTTP connections if there are HTTP intermediaries to the target. Similarly, in the other direction the ECN Bits field
involved; see Section 2.3 of [RFC7230]. represents which ECN bits were seen on the UDP packets received from
the target.
Intermediaries that support this extension and HTTP/3 datagrams MUST 5. A Note about Future Extensions
negotiate all four flow identifiers separately on the client-facing
and server-facing connections. This is accomplished by having the
intermediary parse the unnamed element and the "ecn-ect0", "ecn-
ect1", and "ecn-ce" named elements in the "Datagram-Flow-Id" header
on all CONNECT-UDP requests it receives, and sending the same four
flow identifiers in the "Datagram-Flow-Id" header on the response.
Intermediaries MUST NOT send the "ECN" header with a value of 1 to This CONNECT-UDP extension uses an HTTP field to register its chosen
the client on its response unless it has received that same value in context ID. Future extensions to CONNECT-UDP can use the same
the response it received from the server. strategy to register their chosen context ID(s) via another HTTP
field. This strategy is best for CONNECT-UDP extensions that only
need to register context IDs during the HTTP request and response.
Some extensions may need to register context IDs after the request
and response have been exchanged, for example an extension that
wishes to compress QUIC connection IDs [QUIC] is not aware of all
connection IDs at request time. In such cases, extensions can use
new Capsule Types (see [HTTP-DGRAM]) to perform context ID
registration.
6. Security Considerations 6. Security Considerations
This document does not have additional security considerations beyond This document does not have additional security considerations beyond
those defined in [CONNECT-UDP]. those defined in [CONNECT-UDP].
7. IANA Considerations 7. IANA Considerations
7.1. HTTP Header This document will request IANA to register the following entry in
the "HTTP Field Name" registry:
This document will request IANA to register the "ECN" header in the
"Permanent Message Header Field Names" registry maintained at
<https://www.iana.org/assignments/message-headers>.
+-------------------+----------+--------+---------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+--------+---------------+
| ECN | http | std | This document |
+-------------------+----------+--------+---------------+
7.2. Flow Identifier Parameters
This document will request IANA to register the "ecn-ect0", "ecn- Field Name: ECN
ect1", and "ecn-ce" flow identifier parameters in the "HTTP Datagram
Flow Identifier Parameters" registry (see [H3DGRAM]):
+----------+-------------------------+---------+---------------+ Template: None
| Key | Description | Is Name | Reference |
+----------+-------------------------+---------+---------------+
| ecn-ect0 | UDP payload with ECT(0) | Yes | This document |
+----------+-------------------------+---------+---------------+
| ecn-ect1 | UDP payload with ECT(1) | Yes | This document |
+----------+-------------------------+---------+---------------+
| ecn-ce | UDP payload with CE | Yes | This document |
+----------+-------------------------+---------+---------------+
7.3. Stream Chunk Type Registration Status: provisional (permanent if this document is approved)
This document will request IANA to register the following entry in Reference: This document
the "CONNECT-UDP Stream Chunk Type" registry [CONNECT-UDP]:
+-------+-----------------+-------------------------+---------------+ Comments: None
| Value | Type | Description | Reference |
+-------+-----------------+-------------------------+---------------+
| 0x31 | UDP_PACKET_ECT0 | UDP payload with ECT(0) | This document |
+-------+-----------------+-------------------------+---------------+
| 0x32 | UDP_PACKET_ECT1 | UDP payload with ECT(1) | This document |
+-------+-----------------+-------------------------+---------------+
| 0x33 | UDP_PACKET_CE | UDP payload with CE | This document |
+-------+-----------------+-------------------------+---------------+
8. Normative References 8. Normative References
[CONNECT-UDP] [CONNECT-UDP]
Schinazi, D., "The CONNECT-UDP HTTP Method", Work in Schinazi, D., "UDP Proxying Support for HTTP", Work in
Progress, Internet-Draft, draft-ietf-masque-connect-udp- Progress, Internet-Draft, draft-ietf-masque-connect-udp-
02, 30 December 2020, <http://www.ietf.org/internet- 08, 21 March 2022, <https://datatracker.ietf.org/doc/html/
drafts/draft-ietf-masque-connect-udp-02.txt>. draft-ietf-masque-connect-udp-08>.
[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/rfc/rfc3168>.
[H3DGRAM] Schinazi, D., "Using QUIC Datagrams with HTTP/3", Work in [HTTP-DGRAM]
Progress, Internet-Draft, draft-schinazi-quic-h3-datagram- Schinazi, D. and L. Pardue, "HTTP Datagrams and the
05, 12 October 2020, <http://www.ietf.org/internet-drafts/ Capsule Protocol", Work in Progress, Internet-Draft,
draft-schinazi-quic-h3-datagram-05.txt>. draft-ietf-masque-h3-datagram-08, 28 March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-masque-
h3-datagram-08>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[STRUCT-HDR] [STRUCT-FIELD]
Nottingham, M. and P. Kamp, "Structured Field Values for Nottingham, M. and P-H. Kamp, "Structured Field Values for
HTTP", Work in Progress, Internet-Draft, draft-ietf- HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
httpbis-header-structure-19, 3 June 2020, <https://www.rfc-editor.org/rfc/rfc8941>.
<http://www.ietf.org/internet-drafts/draft-ietf-httpbis-
header-structure-19.txt>.
Acknowledgments Acknowledgments
This proposal was inspired directly or indirectly by prior work from This proposal was inspired directly or indirectly by prior work from
many people. The author would like to thank contributors the MASQUE many people. The author would like to thank contributors the MASQUE
working group. working group.
Author's Address Author's Address
David Schinazi David Schinazi
 End of changes. 42 change blocks. 
153 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/