idnits 2.17.1 draft-pardue-masque-dgram-priority-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (26 July 2021) is 1004 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-masque-h3-datagram-03 == Outdated reference: A later version (-12) exists of draft-ietf-httpbis-priority-04 == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MASQUE L. Pardue 3 Internet-Draft Cloudflare 4 Intended status: Experimental 26 July 2021 5 Expires: 27 January 2022 7 HTTP Datagram Prioritization 8 draft-pardue-masque-dgram-priority-01 10 Abstract 12 Application protocols using the QUIC transport protocol rely on 13 streams, and optionally the DATAGRAM extension, to carry application 14 data. Streams and datagrams can be multiplexed but QUIC provides no 15 interoperable prioritization scheme or signaling mechanism itself. 16 The HTTP Extensible Prioritization scheme describes how to prioritize 17 streams in HTTP/2 and HTTP/3. This document adopts the scheme to 18 support HTTP datagrams. 20 Note tho Readers 22 _RFC EDITOR: please remove this section before publication_ 24 Source code and issues list for this draft can be found at 25 https://github.com/LPardue/draft-pardue-masque-dgram-priority 26 (https://github.com/LPardue/draft-pardue-masque-dgram-priority). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 27 January 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 63 2. Signalling Datagram Priority . . . . . . . . . . . . . . . . 3 64 2.1. Datagram Urgency . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Prioritization of Contexts . . . . . . . . . . . . . . . 4 66 2.3. Reprioritization . . . . . . . . . . . . . . . . . . . . 4 67 3. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 5 69 5. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 5 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 74 8.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 Application protocols using the QUIC transport protocol [QUIC] rely 81 on streams, and optionally the DATAGRAM extension [QUIC-DATAGRAM], to 82 carry application data. Streams and datagrams can be multiplexed but 83 QUIC provides no interoperable prioritization scheme or signaling 84 mechanism itself. The HTTP Extensible Prioritization scheme 85 [I-D.ietf-httpbis-priority] describes how to prioritize streams in 86 HTTP/2 and HTTP/3. This document adopts the scheme to support HTTP 87 datagrams [HTTP-DATAGRAM]. 89 The Extensible Priorities scheme for HTTP describes how clients can 90 send priority signals related to requests in order to suggest how a 91 server allocates resources to serving responses. When the protocol 92 is HTTP/2, responses are carried on streams. When the protocol is 93 HTTP/3, responses are carries on QUIC streams. 95 While QUIC streams support multiplexing natively via use of a stream 96 identifier, the QUIC DATAGRAM extension does not provide any such 97 identifier. HTTP datagrams [HTTP-DATAGRAM] supports multiplexing 98 using a set of application-level identifiers that can be controlled 99 and accessed by HTTP/3. One identifer relates to a request stream, 100 the second, optional, identifer relates to an abstract context. 101 [HTTP-DATAGRAM] does not, however, define any means for multiplexed 102 datagram prioritization. 104 When the application protocol is HTTP/3, HTTP Datagrams can map 105 directly to QUIC datagrams or they can be carried on streams using a 106 DATAGRAM Capsule; see Section 4.4 of [HTTP-DATAGRAM]. 108 This document describes how the Extensible Priorities scheme applies 109 to HTTP datagrams. Priority signals sent by clients, related to 110 requests, can also be considered input to server scheduling decisions 111 for HTTP datagrams mapped to QUIC datagrams. 113 1.1. Notational Conventions 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 The term sf-integer is imported from [STRUCTURED-FIELDS]. 123 2. Signalling Datagram Priority 125 The Extensible Prioritization scheme [I-D.ietf-httpbis-priority] 126 provides a framework for communicating and acting upon priority 127 parameters, using [STRUCTURED-FIELDS] formats. It defines the 128 urgency and incremental parameters and provides guidance to 129 implementers about how to act on these parameters, in combination 130 with other inputs, to make resource allocation and scheduling 131 choices. Urgency communicates the client-view of request importance, 132 and incremental communicates how the client intends to process 133 response data as it arrives. Parameters are communicated in HTTP 134 headers or version-specific frames. A client omitting the urgency or 135 incremental parameters can be interpreted by the server as a signal 136 to apply default priorities. The core scheme is extensible, new 137 parameters can be defined to augment the base ones. 139 This specification defines the datagram-urgency ("du") extension 140 parameter that operates in addition to the base urgency. There is no 141 extension to the base incremental behavior; individual datragrams, 142 even if belonging to the same identifier, are messages that are 143 expected to be processed individually as they arrive. 145 2.1. Datagram Urgency 147 The datagram-urgency parameter ("du") takes an integer between 0 and 148 7, in descending order of priority. This range matches the base 149 urgency ("u") parameter range; see Section 4.1 of 150 [I-D.ietf-httpbis-priority]. 152 The value is encoded as an sf-integer. There is no default value. 154 This parameter indicates the sender's recommendation, based on the 155 expectation that the server would transmit HTTP datagrams in the 156 order of their datagram-urgency values if possible. The smaller the 157 value, the higher the precedence. Omitting the datagram-urgency 158 parameter is a signal to apply the value of the urgency parameter. 160 The following example shows a request for a CSS file with the urgency 161 set to "0", any associated datagrams have the lower urgency of "2": 163 :method = GET 164 :scheme = https 165 :authority = example.net 166 :path = /style.css 167 priority = u=0, du=2 169 Endpoints MUST NOT treat reception of the datagram-urgency parameter, 170 even if HTTP datagram support is not enabled. 172 The datagram-urgency parameter applies only to HTTP datagrams mapped 173 to QUIC datagrams. Datagram capsules are sent on streams, so the 174 base urgency parameter applies to them. 176 2.2. Prioritization of Contexts 178 The datagram-urgency parameter applies to all HTTP datagram contexts 179 related to a request stream. Prioritization of individual contexts 180 is not supported. 182 2.3. Reprioritization 184 Reprioritization is supported using the existing mechanisms defined 185 in Section 6 of [I-D.ietf-httpbis-priority]. 187 3. Client Scheduling 189 Clients MAY use datagram-urgency to make local processing or 190 scheduling choices about HTTP datagrams related to the requests it 191 initiates. 193 4. Server Scheduling 195 Priority signals are input to a prioritization process. Expressing 196 priority is only a suggestion. The datagram-urgency parameter 197 introduces new scheduling considerations on top of those presented in 198 Section 10 of [I-D.ietf-httpbis-priority]. 200 It is RECOMMENDED that, when possible, servers send higher urgency 201 HTTP datagrams before lower urgency datagrams. 203 Where streams and datagrams have equal urgency and datagram-urgency, 204 it is RECOMMENDED that servers alternate emitting HTTP datagrams and 205 stream bytes. Where servers implement the recommendations in 206 Section 10 of [I-D.ietf-httpbis-priority], alternating between 207 datagram and stream data will result in fair scheduling. This 208 recommendation holds whether stream are incremental or not. 210 It is RECOMMENDED that servers schedule DATAGRAM capsules the same as 211 response data. 213 5. Retransmission Scheduling 215 Section 12 of [I-D.ietf-httpbis-priority] provides guidance about 216 scheduling of retransmission data vs. new data. Since QUIC datagrams 217 are not retransmitted, endpoints that prioritize QUIC stream 218 retransmission data could delay datagrams. Furthermore, since 219 DATAGRAM capsules are sent as stream data, they *are* subject to 220 retransmission and could also delay native QUIC datagrams. 222 6. Security Considerations 224 There are believed to be no additional considerations to those 225 presented in [I-D.ietf-httpbis-priority]. 227 7. IANA Considerations 229 This specification registers the following entry in the HTTP Priority 230 Parameters Registry 232 Name: datagram-urgency 234 Description: Priority of HTTP datagrams 236 Reference: This document 238 8. References 240 8.1. Normative References 242 [HTTP-DATAGRAM] 243 Schinazi, D. and L. Pardue, "Using Datagrams with HTTP", 244 Work in Progress, Internet-Draft, draft-ietf-masque-h3- 245 datagram-03, 12 July 2021, 246 . 249 [I-D.ietf-httpbis-priority] 250 Oku, K. and L. Pardue, "Extensible Prioritization Scheme 251 for HTTP", Work in Progress, Internet-Draft, draft-ietf- 252 httpbis-priority-04, 11 July 2021, 253 . 256 [QUIC-DATAGRAM] 257 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 258 Datagram Extension to QUIC", Work in Progress, Internet- 259 Draft, draft-ietf-quic-datagram-03, 12 July 2021, 260 . 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, 266 . 268 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 269 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 270 May 2017, . 272 [STRUCTURED-FIELDS] 273 Nottingham, M. and P-H. Kamp, "Structured Field Values for 274 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 275 . 277 8.2. Informative References 279 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 280 Multiplexed and Secure Transport", RFC 9000, 281 DOI 10.17487/RFC9000, May 2021, 282 . 284 Appendix A. Acknowledgements 286 This document is inspired by discussion by many people across HTTP, 287 QUIC and MASQUE WGs. 289 Author's Address 291 Lucas Pardue 292 Cloudflare 294 Email: lucaspardue.24.7@gmail.com