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

From: Lucas Pardue <[email-masked]>
Date: Thu, 5 Mar 2020 17:39:53 +0000

Hello WGs,

Following adoption of draft-kazuho-httpbis-priority-04 by HTTPbis, Kazuho
and I have published draft-ietf-httpbis-priority-00 (see forwarded email).

The major change in this draft relates to the urgency levels. Based on
feedback and discussion, we have kept 8 levels (0-7 in descending order of
priority) but have minimized the semantics. This allows a common urgency
range, without being overly prescriptive on client's ability to use the
range. Furthermore, the text describing how an intermediary might approach
merging priority signals from client and server implied a weighting toward
server signals; we have reduced the guidance and highlight that merging
decision are a local decision.

This draft version contains changes that reflect emerging WG consensus.
However, the list of open issues is available on Github [1] and we
encourage continued discussion, notably the debate on using frame vs.
headers is still unresolved.

Cheers
Lucas

[1] - https://github.com/httpwg/http-extensions/labels/priorities

---------- Forwarded message ---------
From: <[email-masked]>
Date: Thu, Mar 5, 2020 at 5:09 PM
Subject: New Version Notification for draft-ietf-httpbis-priority-00.txt
To: Kazuho Oku <[email-masked]>, Lucas Pardue <
[email-masked]>

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

Name:           draft-ietf-httpbis-priority
Revision:       00
Title:          Extensible Prioritization Scheme for HTTP
Document date:  2020-03-05
Group:          httpbis
Pages:          19
URL:
https://www.ietf.org/internet-drafts/draft-ietf-httpbis-priority-00.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-priority/
Htmlized:       https://tools.ietf.org/html/draft-ietf-httpbis-priority-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-priority

Abstract:
   This document describes a scheme for prioritizing HTTP responses.
   This scheme expresses the priority of each HTTP response using
   absolute values, rather than as a relative relationship between a
   group of HTTP responses.

   This document defines the Priority header field for communicating the
   initial priority in an HTTP version-independent manner, as well as
   HTTP/2 and HTTP/3 frames for reprioritizing the responses.  These
   share a common format structure that is designed to provide future
   extensibility.

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

---

From: Ian Swett <[email-masked]>
Date: Thu, 5 Mar 2020 13:17:27 -0500

Thanks for updating this draft.

On the point of headers vs frame, based on my experience leading the design
team and the slightly wider scope of use cases that are now on the table,
which includes server-side reprioritization, I see the compromise of having
both a frame and a header as the only way forward which has the ability to
gain consensus.  I also truly believe there are valid use cases for both.

I propose we should own that position and seek to describe the properties
of each clearly.

Thanks, Ian

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 5 Mar 2020 19:43:36 +0000

Hi Ian,

On Thu, Mar 5, 2020 at 6:17 PM Ian Swett <[email-masked]> wrote:

> On the point of headers vs frame, based on my experience leading the
> design team and the slightly wider scope of use cases that are now on the
> table, which includes server-side reprioritization, I see the compromise of
> having both a frame and a header as the only way forward which has the
> ability to gain consensus.  I also truly believe there are valid use cases
> for both.
>

 Thanks for sharing your current thinking. Clarification question, the
present design has an symmetrical design that constrains when and where
where the signal carrier is used: headers are used for initial priority,
and frames are used for reprioritization. You position supports both
carriers but does it support this constraint?

I'd also welcome other people's thoughts on this topic.

Lucas

---

From: Ian Swett <[email-masked]>
Date: Thu, 5 Mar 2020 14:51:01 -0500

The draft is written with that in mind, but there's no requirement in
design or the draft that an implementation can only use the header for
initial prioritization.  Chrome uses the frame for initial priority and
updates and it seems to work fine.  Obviously only the frame can be used
for reprioritization.  I expect Google HTTP/3 servers will end up
supporting both.

But I think the draft should be updated to describe the frame as HBH and
able to be used for either initial or priority updates.

In practice, due to reordering, implementations need to handle receiving
the frame prior to the request anyway.

I hope that clarifies my thinking, Ian

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 5 Mar 2020 20:05:01 +0000

> I hope that clarifies my thinking, Ian

Based on your implementation experience, would you be happy with the frame
being restricted to only being sent on the control stream? Or do you see
some need for allowing that frame on the request stream (noting that doing
so adds challenges to making it work with HTTP/2)?

---

From: Ian Swett <[email-masked]>
Date: Thu, 5 Mar 2020 15:09:39 -0500

I think only sending it on the control stream is fine, as you can bundle a
STREAM frame from the control frame with that of the request stream into a
single datagram.  I don't think I'd object to sending it on the request
stream, but the only clear benefit is saving a few bytes.

And of course, Chrome may change to use the header for the initial priority
at some point after evaluation, but for now this approach is a bit simpler.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 5 Mar 2020 20:43:37 +0000

Until HTTP offers chunk-extensions again, I don’t see how it can be otherwise?
-=R

From: QUIC <[email-masked]> on behalf of Lucas Pardue <[email-masked]>
Date: Thursday, March 5, 2020 at 12:24 PM
To: Ian Swett <[email-masked]>
Cc: QUIC WG <[email-masked]>, HTTP Working Group <[email-masked]>
Subject: Re: New Version Notification for draft-ietf-httpbis-priority-00.txt

Hi Ian,

On Thu, Mar 5, 2020 at 6:17 PM Ian Swett <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for updating this draft.

On the point of headers vs frame, based on my experience leading the design team and the slightly wider scope of use cases that are now on the table, which includes server-side reprioritization, I see the compromise of having both a frame and a header as the only way forward which has the ability to gain consensus.  I also truly believe there are valid use cases for both.

I propose we should own that position and seek to describe the properties of each clearly.

Thanks, Ian

 Thanks for sharing your current thinking. Clarification question, the present design has an symmetrical design that constrains when and where where the signal carrier is used: headers are used for initial priority, and frames are used for reprioritization. You position supports both carriers but does it support this constraint?

Lucas

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 06 Mar 2020 08:19:43 +1100

> Until HTTP offers chunk-extensions again, I don’t see how it can be otherwise?

I don't think that's the concern, it's that there is no way for a client to send an update if the request stream is closed.  At least in QUIC.

---

From: Ian Swett <[email-masked]>
Date: Thu, 5 Mar 2020 16:36:05 -0500

Martin's concern is exactly right.

On Thu, Mar 5, 2020 at 4:24 PM Martin Thomson <[email-masked]> wrote:

> I don't think that's the concern, it's that there is no way for a client
> to send an update if the request stream is closed.  At least in QUIC.
>
>

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 5 Mar 2020 21:53:50 +0000

I agree with the points made but I think my question was unclear of my
intent. So let me rephrase it as: HTTP/2 allows the PRIORITY frame to be
sent on a stream at any point. Do we want to allow NU_PRIORITY on request
streams but constrain the states that it can be sent in?

Given that we're trying to define something that works equivalently across
HTTP/2 and HTTP/3, my inclination is that restricting NU_PRIORITY to stream
0 and the control stream achieves that.

---

From: Ian Swett <[email-masked]>
Date: Thu, 5 Mar 2020 21:08:41 -0500

I think it would be nice to allow the frame on the request stream, but it's
not a must.  The current design works from my perspective, but it uses a
few more bytes.  If others support allowing it on the request stream, I'd
be supportive, and the additional code is tiny, but I'm not going to fight
for it really strongly and I certainly don't want to delay this effort to
fight for it.

I hope that's slightly clearer.

Thanks, Ian

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 6 Mar 2020 13:05:13 +0900

2020年3月6日(金) 11:12 Ian Swett <[email-masked]>:

> I think it would be nice to allow the frame on the request stream, but
> it's not a must.  The current design works from my perspective, but it uses
> a few more bytes.  If others support allowing it on the request stream, I'd
I think my preference goes to sending priority only on the control stream,
for simplicity and robustness.

Having two ways to signal priorities through a frame is complex.

I would point out that Chrome (as it is now) sends the PRIORITY_UPDATE
frame on the control stream before the HEADERS frame on the request stream,
and I like it.

QUIC does not have ordering guarantee between streams, and that means that
there's always chance for a PRIORITY_UPDATE frame to arrive after the
prioritization signal sent on the request stream, regardless of that signal
being a header field or a frame.

Therefore, servers ought to buffer the information conveyed in the
PRIORITY_UPDATE frame being received on the control stream. The current
behavior of Chrome helps server developers do that.

>> Given that we're trying to define something that works equivalently
>> across HTTP/2 and HTTP/3, my inclination is that restricting NU_PRIORITY to
>> stream 0 and the control stream achieves that.
>>
>>
>>>> I don't think that's the concern, it's that there is no way for a
>>>> client to send an update if the request stream is closed.  At least in QUIC.
>>>>
>>>>

-- 
Kazuho Oku