HTTP Datagram Prioritization
draft-pardue-masque-dgram-priority-01

Document Type Active Internet-Draft (individual)
Author Lucas Pardue 
Last updated 2021-07-26
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
MASQUE                                                         L. Pardue
Internet-Draft                                                Cloudflare
Intended status: Experimental                               26 July 2021
Expires: 27 January 2022

                      HTTP Datagram Prioritization
                 draft-pardue-masque-dgram-priority-01

Abstract

   Application protocols using the QUIC transport protocol rely on
   streams, and optionally the DATAGRAM extension, to carry application
   data.  Streams and datagrams can be multiplexed but QUIC provides no
   interoperable prioritization scheme or signaling mechanism itself.
   The HTTP Extensible Prioritization scheme describes how to prioritize
   streams in HTTP/2 and HTTP/3.  This document adopts the scheme to
   support HTTP datagrams.

Note tho Readers

   _RFC EDITOR: please remove this section before publication_

   Source code and issues list for this draft can be found at
   https://github.com/LPardue/draft-pardue-masque-dgram-priority
   (https://github.com/LPardue/draft-pardue-masque-dgram-priority).

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 27 January 2022.

Copyright Notice

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

Pardue                   Expires 27 January 2022                [Page 1]
Internet-Draft        HTTP Datagram Prioritization             July 2021

   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   3
   2.  Signalling Datagram Priority  . . . . . . . . . . . . . . . .   3
     2.1.  Datagram Urgency  . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Prioritization of Contexts  . . . . . . . . . . . . . . .   4
     2.3.  Reprioritization  . . . . . . . . . . . . . . . . . . . .   4
   3.  Client Scheduling . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Server Scheduling . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Retransmission Scheduling . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Application protocols using the QUIC transport protocol [QUIC] rely
   on streams, and optionally the DATAGRAM extension [QUIC-DATAGRAM], to
   carry application data.  Streams and datagrams can be multiplexed but
   QUIC provides no interoperable prioritization scheme or signaling
   mechanism itself.  The HTTP Extensible Prioritization scheme
   [I-D.ietf-httpbis-priority] describes how to prioritize streams in
   HTTP/2 and HTTP/3.  This document adopts the scheme to support HTTP
   datagrams [HTTP-DATAGRAM].

   The Extensible Priorities scheme for HTTP describes how clients can
   send priority signals related to requests in order to suggest how a
   server allocates resources to serving responses.  When the protocol
   is HTTP/2, responses are carried on streams.  When the protocol is
   HTTP/3, responses are carries on QUIC streams.

   While QUIC streams support multiplexing natively via use of a stream
   identifier, the QUIC DATAGRAM extension does not provide any such
   identifier.  HTTP datagrams [HTTP-DATAGRAM] supports multiplexing

Pardue                   Expires 27 January 2022                [Page 2]
Internet-Draft        HTTP Datagram Prioritization             July 2021

   using a set of application-level identifiers that can be controlled
   and accessed by HTTP/3.  One identifer relates to a request stream,
   the second, optional, identifer relates to an abstract context.
   [HTTP-DATAGRAM] does not, however, define any means for multiplexed
   datagram prioritization.

   When the application protocol is HTTP/3, HTTP Datagrams can map
   directly to QUIC datagrams or they can be carried on streams using a
   DATAGRAM Capsule; see Section 4.4 of [HTTP-DATAGRAM].

   This document describes how the Extensible Priorities scheme applies
   to HTTP datagrams.  Priority signals sent by clients, related to
   requests, can also be considered input to server scheduling decisions
   for HTTP datagrams mapped to QUIC datagrams.

1.1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The term sf-integer is imported from [STRUCTURED-FIELDS].

2.  Signalling Datagram Priority

   The Extensible Prioritization scheme [I-D.ietf-httpbis-priority]
   provides a framework for communicating and acting upon priority
   parameters, using [STRUCTURED-FIELDS] formats.  It defines the
   urgency and incremental parameters and provides guidance to
   implementers about how to act on these parameters, in combination
   with other inputs, to make resource allocation and scheduling
   choices.  Urgency communicates the client-view of request importance,
   and incremental communicates how the client intends to process
   response data as it arrives.  Parameters are communicated in HTTP
   headers or version-specific frames.  A client omitting the urgency or
   incremental parameters can be interpreted by the server as a signal
   to apply default priorities.  The core scheme is extensible, new
   parameters can be defined to augment the base ones.

   This specification defines the datagram-urgency ("du") extension
   parameter that operates in addition to the base urgency.  There is no
   extension to the base incremental behavior; individual datragrams,
   even if belonging to the same identifier, are messages that are
   expected to be processed individually as they arrive.

Pardue                   Expires 27 January 2022                [Page 3]
Internet-Draft        HTTP Datagram Prioritization             July 2021

2.1.  Datagram Urgency

   The datagram-urgency parameter ("du") takes an integer between 0 and
   7, in descending order of priority.  This range matches the base
   urgency ("u") parameter range; see Section 4.1 of
   [I-D.ietf-httpbis-priority].

   The value is encoded as an sf-integer.  There is no default value.

   This parameter indicates the sender's recommendation, based on the
   expectation that the server would transmit HTTP datagrams in the
   order of their datagram-urgency values if possible.  The smaller the
   value, the higher the precedence.  Omitting the datagram-urgency
   parameter is a signal to apply the value of the urgency parameter.

   The following example shows a request for a CSS file with the urgency
   set to "0", any associated datagrams have the lower urgency of "2":

   :method = GET
   :scheme = https
   :authority = example.net
   :path = /style.css
   priority = u=0, du=2

   Endpoints MUST NOT treat reception of the datagram-urgency parameter,
   even if HTTP datagram support is not enabled.

   The datagram-urgency parameter applies only to HTTP datagrams mapped
   to QUIC datagrams.  Datagram capsules are sent on streams, so the
   base urgency parameter applies to them.

2.2.  Prioritization of Contexts

   The datagram-urgency parameter applies to all HTTP datagram contexts
   related to a request stream.  Prioritization of individual contexts
   is not supported.

2.3.  Reprioritization

   Reprioritization is supported using the existing mechanisms defined
   in Section 6 of [I-D.ietf-httpbis-priority].

3.  Client Scheduling

   Clients MAY use datagram-urgency to make local processing or
   scheduling choices about HTTP datagrams related to the requests it
   initiates.

Pardue                   Expires 27 January 2022                [Page 4]
Internet-Draft        HTTP Datagram Prioritization             July 2021

4.  Server Scheduling

   Priority signals are input to a prioritization process.  Expressing
   priority is only a suggestion.  The datagram-urgency parameter
   introduces new scheduling considerations on top of those presented in
   Section 10 of [I-D.ietf-httpbis-priority].

   It is RECOMMENDED that, when possible, servers send higher urgency
   HTTP datagrams before lower urgency datagrams.

   Where streams and datagrams have equal urgency and datagram-urgency,
   it is RECOMMENDED that servers alternate emitting HTTP datagrams and
   stream bytes.  Where servers implement the recommendations in
   Section 10 of [I-D.ietf-httpbis-priority], alternating between
   datagram and stream data will result in fair scheduling.  This
   recommendation holds whether stream are incremental or not.

   It is RECOMMENDED that servers schedule DATAGRAM capsules the same as
   response data.

5.  Retransmission Scheduling

   Section 12 of [I-D.ietf-httpbis-priority] provides guidance about
   scheduling of retransmission data vs. new data.  Since QUIC datagrams
   are not retransmitted, endpoints that prioritize QUIC stream
   retransmission data could delay datagrams.  Furthermore, since
   DATAGRAM capsules are sent as stream data, they *are* subject to
   retransmission and could also delay native QUIC datagrams.

6.  Security Considerations

   There are believed to be no additional considerations to those
   presented in [I-D.ietf-httpbis-priority].

7.  IANA Considerations

   This specification registers the following entry in the HTTP Priority
   Parameters Registry

   Name:  datagram-urgency

   Description:  Priority of HTTP datagrams

   Reference:  This document

8.  References

8.1.  Normative References

Pardue                   Expires 27 January 2022                [Page 5]
Internet-Draft        HTTP Datagram Prioritization             July 2021

   [HTTP-DATAGRAM]
              Schinazi, D. and L. Pardue, "Using Datagrams with HTTP",
              Work in Progress, Internet-Draft, draft-ietf-masque-h3-
              datagram-03, 12 July 2021,
              <https://www.ietf.org/archive/id/draft-ietf-masque-h3-
              datagram-03.txt>.

   [I-D.ietf-httpbis-priority]
              Oku, K. and L. Pardue, "Extensible Prioritization Scheme
              for HTTP", Work in Progress, Internet-Draft, draft-ietf-
              httpbis-priority-04, 11 July 2021,
              <https://www.ietf.org/archive/id/draft-ietf-httpbis-
              priority-04.txt>.

   [QUIC-DATAGRAM]
              Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
              Datagram Extension to QUIC", Work in Progress, Internet-
              Draft, draft-ietf-quic-datagram-03, 12 July 2021,
              <https://www.ietf.org/archive/id/draft-ietf-quic-datagram-
              03.txt>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [STRUCTURED-FIELDS]
              Nottingham, M. and P-H. Kamp, "Structured Field Values for
              HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
              <https://www.rfc-editor.org/info/rfc8941>.

8.2.  Informative References

   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

Appendix A.  Acknowledgements

   This document is inspired by discussion by many people across HTTP,
   QUIC and MASQUE WGs.

Pardue                   Expires 27 January 2022                [Page 6]
Internet-Draft        HTTP Datagram Prioritization             July 2021

Author's Address

   Lucas Pardue
   Cloudflare

   Email: lucaspardue.24.7@gmail.com

Pardue                   Expires 27 January 2022                [Page 7]