Fwd: New Version Notification for draft-kazuho-httpbis-priority-00.txt

[Kazuho Oku <[e-mail]>]

Hi,

Today, Lucas and I have submitted the following draft, that defines an
HTTP header field for driving prioritization.

https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/

In short, the draft defines an end-to-end HTTP header field called
"Priority" for transmitting prioritization hints in absolute values
that have meanings. It is much simpler than the prioritization scheme
of H2 that communicates and uses a "tree". Not only the client, but
also the server can send the prioritization hints, in order to improve
the way the responses are prioritized. The prioritization scheme is
independent to HTTP versions; it can be used on both H2 and H3 (and
also on H1 for providing hints to intermediaries).

For more detail, please refer to the draft.

Background: back in May in London, the QUIC WG had a discussion on if
porting the prioritization scheme of H2 to H3 is the way to go [1].

I think there were two major arguments for having something different:
* Prioritization scheme of H2 is complex, and porting it to H3
increases the complexity [2].
* With the H2 scheme, it is hard for the server to tweak the
prioritization tree, because clients build their trees in their own
ways [3][4].

The arguments against were:
* Redesigning prioritization for H3 is likely to delay the
standardization and time-to-market.
* Having something different in H3 is an act of "adding" complexity to
HTTP as a whole.

This discussion has led us to wonder if there could be a technical
solution that resolves the issues of the H2 scheme (see the pro
arguments), at the same time minimizing the downsides.

And we came up with this proposal. I think the key selling points of
the proposal are:

* Much simpler thanks to each request carrying an absolute priority
value. No need to synchronize a "tree".
* Because the priority value sent by the client indicates how each
request / response affects the use of other responses (e.g.,
"blocking", "non-blocking"), the server can understand the intent of
the client and further optimize the delivery order.
* Use of the HTTP header field as the conveyer of the priority value
allows an origin server to indicate hints to an intermediary that
terminates the H2/H3 connections from the client. For example, an
origin server can indicate higher precedence for some images that
matter more to the user, while giving lower precedence to others.
* Another benefit of using an HTTP header field instead of a frame is
that prioritization logic becomes independent from HTTP versions. That
would help both clients and servers improve the quality of their
implementation, as well as fostering website owners fine-tune the
prioritization through the use of the Priority response header.
* A header-based prioritization scheme can be improved as time goes,
as HTTP headers are extensible by their nature. It also means that a
header-based design can be rolled out at an earlier stage than a
frame-based design.

To paraphrase, the header-based design provides simplicity,
extensibility, room to evolve, and the possibility to roll out early.
This could be the only prioritization scheme for H3. Separating
prioritization into a version-independent approach simplifies H3,
taking some load away from QUIC WG.

Of course, H3 needs to hit the market with a prioritization scheme, we
need to agree on that particular scheme. But I think we might be able
to agree on the need for a header-based prioritization scheme, that a
server can tweak, that uses absolute priorities. If that is the case,
I think we have fair chance on agreeing on something pretty soon.

To summarize, with the proposed design, I think we have the chance of
making prioritization better as we roll out HTTP/3, without getting
the standardization process delayed.

Please let us know what you think. Thank you in advance.


[1] https://github.com/quicwg/wg-materials/blob/master/interim-19-05/priorities.pdf
[2] https://github.com/quicwg/base-drafts/issues/2739
[3] https://github.com/quicwg/base-drafts/issues/2740
[4] In https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0008.html,
Robin points out that server intervention is necessary for best
performance.

---------- Forwarded message ---------
From: <[e-mail]>
Date: 2019年7月8日(月) 21:51
Subject: New Version Notification for draft-kazuho-httpbis-priority-00.txt
To: Kazuho Oku <[e-mail]>, Lucas Pardue <[e-mail]>



A new version of I-D, draft-kazuho-httpbis-priority-00.txt
has been successfully submitted by Kazuho Oku and posted to the
IETF repository.

Name:           draft-kazuho-httpbis-priority
Revision:       00
Title:          The Priority HTTP Header Field
Document date:  2019-07-08
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/internet-drafts/draft-kazuho-httpbis-priority-00.txt
Status:         https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/
Htmlized:       https://tools.ietf.org/html/draft-kazuho-httpbis-priority-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-priority


Abstract:
   This document describes the Priority HTTP header field.  This header
   field can be used by endpoints to specify the absolute precedence of
   an HTTP response in an HTTP-version-independent way.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



-- 
Kazuho Oku