| < draft-schinazi-quic-h3-datagram-00.txt | draft-schinazi-quic-h3-datagram-01.txt > | |||
|---|---|---|---|---|
| Network Working Group D. Schinazi | Network Working Group D. Schinazi | |||
| Internet-Draft Google LLC | Internet-Draft Google LLC | |||
| Intended status: Experimental October 21, 2019 | Intended status: Experimental October 21, 2019 | |||
| Expires: April 23, 2020 | Expires: April 23, 2020 | |||
| Using QUIC Datagrams with HTTP/3 | Using QUIC Datagrams with HTTP/3 | |||
| draft-schinazi-quic-h3-datagram-00 | draft-schinazi-quic-h3-datagram-01 | |||
| Abstract | Abstract | |||
| The QUIC DATAGRAM extension provides application protocols running | The QUIC DATAGRAM extension provides application protocols running | |||
| over QUIC with a way to send unreliable data while leveraging the | over QUIC with a mechanism to send unreliable data while leveraging | |||
| security and congestion-control properties of QUIC. However, QUIC | the security and congestion-control properties of QUIC. However, | |||
| DATAGRAM frames do not provide a means to demultiplex application | QUIC DATAGRAM frames do not provide a means to demultiplex | |||
| contexts using them. This document defines how to use QUIC DATAGRAM | application contexts. This document defines how to use QUIC DATAGRAM | |||
| frames when the application protocol running over QUIC is HTTP/3, by | frames when the application protocol running over QUIC is HTTP/3 by | |||
| adding an identifier at the start of the frame payload. | adding an identifier at the start of the frame payload. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| 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- | |||
| skipping to change at page 2, line 24 ¶ | skipping to change at page 2, line 24 ¶ | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 | 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 | |||
| Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 4 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 1. Introduction | 1. Introduction | |||
| The QUIC DATAGRAM extension [I-D.pauly-quic-datagram] provides | The QUIC DATAGRAM extension [I-D.pauly-quic-datagram] provides | |||
| application protocols running over QUIC [I-D.ietf-quic-transport] | application protocols running over QUIC [I-D.ietf-quic-transport] | |||
| with a way to send unreliable data while leveraging the security and | with a mechanism to send unreliable data while leveraging the | |||
| congestion-control properties of QUIC. However, QUIC DATAGRAM frames | security and congestion-control properties of QUIC. However, QUIC | |||
| do not provide a means to demultiplex application contexts using | DATAGRAM frames do not provide a means to demultiplex application | |||
| them. This document defines how to use QUIC DATAGRAM frames when the | contexts. This document defines how to use QUIC DATAGRAM frames when | |||
| application protocol running over QUIC is HTTP/3 | the application protocol running over QUIC is HTTP/3 | |||
| [I-D.ietf-quic-http], by adding an identifier at the start of the | [I-D.ietf-quic-http] by adding an identifier at the start of the | |||
| frame payload. | frame payload. | |||
| This design mimics the use of Stream Types in HTTP/3, which provide a | This design mimics the use of Stream Types in HTTP/3, which provide a | |||
| demultiplexing identifier at the start of each unidirectional stream. | demultiplexing identifier at the start of each unidirectional stream. | |||
| 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 BCP | |||
| skipping to change at page 3, line 25 ¶ | skipping to change at page 3, line 25 ¶ | |||
| Flow Identifier: A variable-length integer indicating the Flow | Flow Identifier: A variable-length integer indicating the Flow | |||
| Identifier of the datagram (see Section 2.1). | Identifier of the datagram (see Section 2.1). | |||
| HTTP/3 Datagram Payload: The payload of the datagram, whose | HTTP/3 Datagram Payload: The payload of the datagram, whose | |||
| semantics are defined by individual applications. | semantics are defined by individual applications. | |||
| 2.1. Flow Identifiers | 2.1. Flow Identifiers | |||
| Flow identifiers represent bidirectional flows of datagrams within a | Flow identifiers represent bidirectional flows of datagrams within a | |||
| single QUIC connection. These are effectively equivalent to UDP | single QUIC connection. These are effectively equivalent to UDP | |||
| ports, that allow basic demultiplexing of application data. The | ports and allow basic demultiplexing of application data. The | |||
| primary role of slow identifiers is to provide a standard mechanism | primary role of flow identifiers is to provide a standard mechanism | |||
| for demultiplexing application data flows, which may be destined for | for demultiplexing application data flows, which may be destined for | |||
| different processing threads in the application, akin to UDP sockets. | different processing threads in the application, akin to UDP sockets. | |||
| Beyond this, a sender SHOULD ensure that DATAGRAM frames within a | Beyond this, a sender SHOULD ensure that DATAGRAM frames within a | |||
| single flow are transmitted in order relative to one another. If | single flow are transmitted in order relative to one another. If | |||
| multiple DATAGRAM frames can be packed into a single QUIC packet, the | multiple DATAGRAM frames can be packed into a single QUIC packet, the | |||
| sender SHOULD group them by Flow Identifier to promote fate-sharing | sender SHOULD group them by flow identifier to promote fate-sharing | |||
| within a specific flow and improve the ability to process batches of | within a specific flow and improve the ability to process batches of | |||
| datagram messages efficiently on the receiver. | datagram messages efficiently on the receiver. | |||
| 3. Flow Identifier Allocation | 3. Flow Identifier Allocation | |||
| Implementations of HTTP/3 that support the DATAGRAM extension will | Implementations of HTTP/3 that support the DATAGRAM extension will | |||
| provide a flow identifier allocation service. That service will | provide a flow identifier allocation service. That service will | |||
| allow applications co-located with HTTP/3 to request a unique Flow | allow applications co-located with HTTP/3 to request a unique flow | |||
| Identifier that they can subsequently use for their own purposes. | identifier that they can subsequently use for their own purposes. | |||
| The HTTP/3 implementation will then parse the Flow Identifier of | The HTTP/3 implementation will then parse the flow identifier of | |||
| incoming DATAGRAM frames and use it to deliver the frame to the | incoming DATAGRAM frames and use it to deliver the frame to the | |||
| appropriate application. | appropriate application. | |||
| 4. Security Considerations | 4. Security Considerations | |||
| This document currently does not have additional security | This document currently does not have additional security | |||
| considerations on top of the ones defined in | considerations beyond those defined in [I-D.ietf-quic-transport] and | |||
| [I-D.ietf-quic-transport] and [I-D.pauly-quic-datagram]. | [I-D.pauly-quic-datagram]. | |||
| 5. IANA Considerations | 5. IANA Considerations | |||
| This document has no IANA actions. | This document has no IANA actions. | |||
| 6. Normative References | 6. Normative References | |||
| [I-D.ietf-quic-http] | [I-D.ietf-quic-http] | |||
| Bishop, M., "Hypertext Transfer Protocol Version 3 | Bishop, M., "Hypertext Transfer Protocol Version 3 | |||
| (HTTP/3)", draft-ietf-quic-http-23 (work in progress), | (HTTP/3)", draft-ietf-quic-http-23 (work in progress), | |||
| End of changes. 7 change blocks. | ||||
| 20 lines changed or deleted | 20 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/ | ||||