Unreliable Transmission Extension for HTTP/2 over QUICBerlin Institute of TechnologyMarchstr. 23BerlinGermanyphilipp@inet.tu-berlin.de
Transport
QUIC Working GroupInternet-DraftThis draft outlines methods for requesting unreliable delivery
of HTTP response bodies over QUIC with unreliable streams specified in .The words “MUST”, “MUST NOT”, “SHALL”, “SHALL NOT”, “SHOULD”, and
“MAY” are used in this document. It’s not shouting; when these
words are capitalized, they have a special meaning as defined
in .HTTP has become part of application protocols used for time sensitive applications such as video streaming and back-office ad auctions.
These applications might have time constraints that can make retransmissions of lost frames useless.
Some of these applications can operate on partially delivered messages, but waiting for retransmissions blocks the delivery of data after a gap in the stream by design.This draft enables applications to request partial delivery of HTTP objects by allowing to disable retransmissions for HTTP response bodies.This draft specifies a new HTTP header for requesting unreliable delivery of the HTTP request body.
For answering requests including this header, the server uses unreliable QUIC streams as specified in
to transfer HTTP request bodies in a (partially) unreliable way.
To use the regular HTTP client logic, headers
are always transferred reliably.By adding the following header, an HTTP client can request unreliable transmission of the response bodyIn case unreliable transmission should only be used to prevent
retransmissions after a certain deadline, the client hat add the following headerWhere DATE is either a relative offset in milliseconds or a date as specified in with optionally extending time-of-day toIn case of having requested unreliable delivery with
the unreliable-after verb, retransmissions on that stream should be stopped after the time specified.For unreliable deliver with using the unreliable verb, the server may use domain knowledge about the data transmitted to decide whether to retransmit parts of the data.The stream mapping scheme changes between versions -04 and -05 of
. While version -04 separates
HTTP header and body into different QUIC streams,
version -05 transports multiple HTTP/2 frames of different types within one stream.
We present different stream mapping for these versions.Note that draft-ietf-quic-http-04 allows a simpler
implementation as it does not require partial retransmission within an unreliable stream.The control stream MUST alway use a reliable stream to ease state keeping.When indicated by the Transport-Response-Reliability HTTP header,
the server SHOULD open the data stream as unreliable stream.As a prerequisite to requesting unreliable delivery of HTTP objects, the client MUST open a stream used for the request as an unreliable stream.
The Transport-Response-Reliability HTTP header sent over reliable streams SHOULD be ignored.Despite opening the stream as an unreliable stream, all HTTP/QUIC frame headers, as well as the payload of HEADERS frames, MUST be transmitted reliably to re-use normal HTTP/2 application logic.TBDTBDHypertext Transfer Protocol (HTTP/1.1): Semantics and ContentThe Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.Hypertext Transfer Protocol Version 2 (HTTP/2)This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.Key words for use in RFCs to Indicate Requirement LevelsIn 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.QUIC: A UDP-Based Multiplexed and Secure TransportThis document defines the core of the QUIC transport protocol. This document describes connection establishment, packet format, multiplexing and reliability. Accompanying documents describe the cryptographic handshake and loss detection.Considerations for Unreliable Streams in QUICThis memo outlines support for unreliable streams in QUIC. This draft contains a collection of considerations and requirements for unreliable streams in QUIC based on [I-D.draft-ietf-quic-transport]. It provides to alternatives demonstrating how unreliable streams can be realized. The intention of this document is to collect considerations regarding unreliable streams in QUIC and to frame the design space. All content of this memo is supposed to be merged into [I-D.draft-ietf-quic-transport], [I-D.draft-ietf-quic-recovery] and, [I-D.draft-ietf-quic-applicability] once unreliable streams get integrated with QUIC.Hypertext Transfer Protocol (HTTP) over QUICThe QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to QUIC.