| < 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/ | ||||