idnits 2.17.1 draft-tiesel-quic-unreliable-http-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.tiesel-quic-unreliable-streams]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 05, 2017) is 2423 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7540' is defined on line 168, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-quic-transport' is defined on line 180, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-05 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-05 == Outdated reference: A later version (-01) exists of draft-tiesel-quic-unreliable-streams-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Working Group P. Tiesel 3 Internet-Draft Berlin Institute of Technology 4 Intended status: Informational September 05, 2017 5 Expires: March 9, 2018 7 Unreliable Transmission Extension for HTTP/2 over QUIC 8 draft-tiesel-quic-unreliable-http-00 10 Abstract 12 This draft outlines methods for requesting unreliable delivery of 13 HTTP response bodies over QUIC with unreliable streams specified in 14 [I-D.tiesel-quic-unreliable-streams]. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 9, 2018. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. General Concept . . . . . . . . . . . . . . . . . . . . . . . 2 53 4. Requesting Unreliable transmission . . . . . . . . . . . . . 3 54 5. Stream Mapping . . . . . . . . . . . . . . . . . . . . . . . 3 55 5.1. Stream Mapping for draft-ietf-quic-http-04 . . . . . . . 3 56 5.2. Stream Mapping for draft-ietf-quic-http-05 . . . . . . . 4 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 61 8.2. Informative References . . . . . . . . . . . . . . . . . 4 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Conventions and Definitions 66 The words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and 67 "MAY" are used in this document. It's not shouting; when these words 68 are capitalized, they have a special meaning as defined in [RFC2119]. 70 2. Introduction 72 HTTP has become part of application protocols used for time sensitive 73 applications such as video streaming and back-office ad auctions. 74 These applications might have time constraints that can make 75 retransmissions of lost frames useless. Some of these applications 76 can operate on partially delivered messages, but waiting for 77 retransmissions blocks the delivery of data after a gap in the stream 78 by design. 80 This draft enables applications to request partial delivery of HTTP 81 objects by allowing to disable retransmissions for HTTP response 82 bodies. 84 3. General Concept 86 This draft specifies a new HTTP header for requesting unreliable 87 delivery of the HTTP request body. For answering requests including 88 this header, the server uses unreliable QUIC streams as specified in 89 [I-D.tiesel-quic-unreliable-streams] to transfer HTTP request bodies 90 in a (partially) unreliable way. To use the regular HTTP client 91 logic, headers are always transferred reliably. 93 4. Requesting Unreliable transmission 95 By adding the following header, an HTTP client can request unreliable 96 transmission of the response body 98 Transport-Response-Reliability: unreliable 100 In case unreliable transmission should only be used to prevent 101 retransmissions after a certain deadline, the client hat add the 102 following header 104 Transport-Response-Reliability: unreliable-after DATE 106 Where DATE is either a relative offset in milliseconds or a date as 107 specified in [RFC7231] with optionally extending time-of-day to 109 time-of-day = hour ":" minute ":" second 110 | hour ":" minute ":" second "." msec 112 In case of having requested unreliable delivery with the "unreliable- 113 after" verb, retransmissions on that stream should be stopped after 114 the time specified. 116 For unreliable deliver with using the "unreliable" verb, the server 117 may use domain knowledge about the data transmitted to decide whether 118 to retransmit parts of the data. 120 5. Stream Mapping 122 The stream mapping scheme changes between versions -04 and -05 of 123 [I-D.ietf-quic-http]. While version -04 separates HTTP header and 124 body into different QUIC streams, version -05 transports multiple 125 HTTP/2 frames of different types within one stream. We present 126 different stream mapping for these versions. 128 Note that draft-ietf-quic-http-04 allows a simpler implementation as 129 it does not require partial retransmission within an unreliable 130 stream. 132 5.1. Stream Mapping for draft-ietf-quic-http-04 134 The control stream MUST alway use a reliable stream to ease state 135 keeping. 137 When indicated by the "Transport-Response-Reliability" HTTP header, 138 the server SHOULD open the data stream as unreliable stream. 140 5.2. Stream Mapping for draft-ietf-quic-http-05 142 As a prerequisite to requesting unreliable delivery of HTTP objects, 143 the client MUST open a stream used for the request as an unreliable 144 stream. The "Transport-Response-Reliability" HTTP header sent over 145 reliable streams SHOULD be ignored. 147 Despite opening the stream as an unreliable stream, all HTTP/QUIC 148 frame headers, as well as the payload of "HEADERS" frames, MUST be 149 transmitted reliably to re-use normal HTTP/2 application logic. 151 6. Security Considerations 153 TBD 155 7. IANA Considerations 157 TBD 159 8. References 161 8.1. Normative References 163 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 164 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 165 DOI 10.17487/RFC7231, June 2014, . 168 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 169 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 170 DOI 10.17487/RFC7540, May 2015, . 173 8.2. Informative References 175 [I-D.ietf-quic-http] 176 Bishop, M., "Hypertext Transfer Protocol (HTTP) over 177 QUIC", draft-ietf-quic-http-05 (work in progress), August 178 2017. 180 [I-D.ietf-quic-transport] 181 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 182 and Secure Transport", draft-ietf-quic-transport-05 (work 183 in progress), August 2017. 185 [I-D.tiesel-quic-unreliable-streams] 186 Tiesel, P., Palmer, M., Chandrasekaran, B., Feldmann, A., 187 and J. Ott, "Considerations for Unreliable Streams in 188 QUIC", draft-tiesel-quic-unreliable-streams-00 (work in 189 progress), September 2017. 191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 192 Requirement Levels", BCP 14, RFC 2119, 193 DOI 10.17487/RFC2119, March 1997, . 196 Author's Address 198 Philipp S. Tiesel 199 Berlin Institute of Technology 200 Marchstr. 23 201 Berlin 202 Germany 204 Email: philipp@inet.tu-berlin.de