Unreliable Transmission Extension for HTTP/2 over QUIC
draft-tiesel-quic-unreliable-http-00

Abstract

This draft outlines methods for requesting unreliable delivery of HTTP response bodies over QUIC with unreliable streams specified in [I-D.tiesel-quic-unreliable-streams].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 9, 2018.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Conventions and Definitions
• 2. Introduction
• 3. General Concept
• 4. Requesting Unreliable transmission
• 5. Stream Mapping
• 5.1. Stream Mapping for draft-ietf-quic-http-04
• 5.2. Stream Mapping for draft-ietf-quic-http-05
• 6. Security Considerations
• 7. IANA Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

1. Conventions and Definitions

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 [RFC2119].

2. Introduction

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.

3. General Concept

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 [I-D.tiesel-quic-unreliable-streams] to transfer HTTP request bodies in a (partially) unreliable way. To use the regular HTTP client logic, headers are always transferred reliably.

4. Requesting Unreliable transmission

By adding the following header, an HTTP client can request unreliable transmission of the response body

Transport-Response-Reliability: unreliable

In case unreliable transmission should only be used to prevent retransmissions after a certain deadline, the client hat add the following header

Transport-Response-Reliability: unreliable-after DATE

Where DATE is either a relative offset in milliseconds or a date as specified in [RFC7231] with optionally extending time-of-day to

time-of-day = hour ":" minute ":" second
            | hour ":" minute ":" second "." msec

In 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.

5. Stream Mapping

The stream mapping scheme changes between versions -04 and -05 of [I-D.ietf-quic-http]. 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.

5.1. Stream Mapping for draft-ietf-quic-http-04

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.

5.2. Stream Mapping for draft-ietf-quic-http-05

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.

6. Security Considerations

TBD

7. IANA Considerations

TBD

8. References

8.1. Normative References

8.2. Informative References

Author's Address