Subject: Priorities I-D for Thursday HTTPbis meeting (Fwd: New Version Notification for draft-kazuho-httpbis-priority-04.txt)

From: Kazuho Oku <[email-masked]>
Date: Wed, 20 Nov 2019 20:04:54 +0800

Dear working groups members,

After the HTTPbis meeting on Monday, the priorities design team as well as
others have had discussions, and have converged on a particular design
(header-based, as well as allowing intermediaries to send frames to express
per-hop priorities).

We have submitted a new revision of the I-D that reflects the emerging
consensus, that clarifies more about the corner cases and how they should
be handled.

It can be found at:
https://tools.ietf.org/html/draft-kazuho-httpbis-priority-04
HTML version is:
https://kazuho.github.io/draft-kazuho-httpbis-priority/draft-kazuho-httpbis-priority.html

We have asked chairs to give us some time in tomorrow's HTTPbis meeting
that we can use to provide an update on the status.

We are looking forward to hearing your comments either face-to-face, or on
the mailing list.

Thank you in advance.

---------- Forwarded message ---------
From: <[email-masked]>
Date: 2019年11月20日(水) 19:53
Subject: New Version Notification for draft-kazuho-httpbis-priority-04.txt
To: Kazuho Oku <[email-masked]>, Lucas Pardue <
[email-masked]>

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

Name:           draft-kazuho-httpbis-priority
Revision:       04
Title:          Extensible Prioritization Scheme for HTTP
Document date:  2019-11-20
Group:          Individual Submission
Pages:          20
URL:
https://www.ietf.org/internet-drafts/draft-kazuho-httpbis-priority-04.txt
Status:
https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/
Htmlized:       https://tools.ietf.org/html/draft-kazuho-httpbis-priority-04
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-priority
Diff:
https://www.ietf.org/rfcdiff?url2=draft-kazuho-httpbis-priority-04

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

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 20 Nov 2019 04:57:20 -0800

Looking forward to digging further into this.

This is not a feedback in the actual design, only the document structure
and presentation. While this may come across a bit negative, I’m really
happy with simplifying the priority scheme of HTTP/2..

Some quick observation when approaching the document initially. I writing
this before having a full grasp of the concepts because that is the only
time to provide a newcomer perspective.

I think the document could be reorganised and much earlier specify how it
achieves prioritisation and use less text (initially) on HTTP/2 by mere
stating the the scheme can work with both HTTP/1, 2, 3 and possibly future
versions while stating that special mechanisms can be used to opt-out of
existing HTTP/2, and leave it at that.

After reading 1/3 of document, I still have no clue how the priority scheme
works (except I have some guess based on earlier ideas that have floatet)
and I have had to deal with a lot of HTTP/2 legacy that I am not
necessarily interested in. HTTP/3 doc has also move away from implicit
HTTP/2 familiarity, at least last time I checked.

The document talks about intermediate hop reprioritisation without making
clear what that is or what purpose it serves. I can only assume load
balancers and reverse proxies. From a QUIC background that also leaves me
wondering what that means - since each hop is necessarily also end to end,
unless there is an extension wrapper frame, but that makes no sense.

Once I got to the business end of the document, the document starts by
telling which headers not send when it is not at all clear what those
headers are about in th first place.

It’s also confusing what a protocol specific frame means, or why it cannot
all be done with HTTP headers.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 20 November 2019 at 13.05.19, Kazuho Oku ([email-masked]) wrote:

It can be found at:

Thank you in advance.

---------- Forwarded message ---------
From: <[email-masked]>
Date: 2019年11月20日(水) 19:53
Subject: New Version Notification for draft-kazuho-httpbis-priority-04.txt
To: Kazuho Oku <[email-masked]>, Lucas Pardue <

Abstract:

The IETF Secretariat

--
Kazuho Oku

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Nov 2019 19:18:34 +0000

Hi Mikkel,

To comment as a co-author but speaking only for myself:

> time to provide a newcomer perspective.

Thanks for taking the time to review, fresh eyes are great.

> existing HTTP/2, and leave it at that.

I agree here. The present document is an amalgamation of several doc, this
has acted as a mechanism to support the design team and improve the
iteration seed. As a specification we can make improvements here, both in
structure and modularity.

> After reading 1/3 of document, I still have no clue how the priority
> scheme works (except I have some guess based on earlier ideas that have
> floatet) and I have had to deal with a lot of HTTP/2 legacy that I am not

To reinterpret you point, I think that the concepts of urgency and
precedence would benefit from better description (issues #31[1] and
#32[2]). But I also wonder if you are saying that there is too much or too
little HTTP/2 specific/related content? Or am I missing out on your point
here?

> unless there is an extension wrapper frame, but that makes no sense.

The intent is to address the HTTP semantic layer but dip into HTTP
version-specifics where necessary. We rely on readers being familiar with
HTTP semantic concepts and terminology but can probably do a better job of
referencing. Since QUIC has no concept of priority, but the serialisation
of HTTP does and is ultimately coupled to the transport layer, it can be a
bit tricky to pick the subject. Happy to take some suggestions on specific
ways to improve here

> all be done with HTTP headers.

It would help to point to a specific section or paragraph. RFC 7540 Section
8 and HTTP/3 draft 24 section 4.1 detail message exchanges - I don't
especially feel the need to duplicate text in this document but accept that
it might help to reference these in the text.

Cheers
Lucas

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 21 Nov 2019 08:17:03 +0800

Kazuho,

Thanks for putting this together.  I only looked briefly, but this appears to faithfully capture what we discussed.

Why did you choose to express this with a dictionary `u=4, i=?1`** rather than a numeric item `4;i=?1`?

Can we look to simplifying this a little more?  I understand that reprioritization was identified as being important by the design team, but I don't recall seeing ever any evidence to support that view.  Can we split that piece out and maybe pursue it separately?

I would prefer to frame the way in which priorities are "merged" (Section 6) differently.  I would instead say that the priority information is input to prioritization decisions that endpoints/intermediaries/etc.. make.  So I would instead say that these entities simply make their own decision about the way to incorporate these signals into their decision.  That's probably a systemic thing that affects more than Section 6; I see that the draft uses "obey" in Section 7.1.1, for example.

There seems - at least to me - to be an assumption on the part of some people involved in this that Priority will be interpreted as an imperative.  That is, that a client might be able to tell a server to act in a particular way and expect to have that instruction complied with.  Same for servers and proxies.  That might be an appealing, but I can't see any way in which we can rely on that.  To the example in the draft, as a CDN, I would expect that the server's view carries more weight than the client's, but I wouldn't necessarily say that this something as absolute as is currently implied.

** The draft is unclear as to whether it is `u=4,i=?1` or `u=4;i=?1`, which you might want to double-check.

On Wed, Nov 20, 2019, at 20:04, Kazuho Oku wrote:
> After the HTTPbis meeting on Monday, the priorities design team as well 
> as others have had discussions, and have converged on a particular 
> design (header-based, as well as allowing intermediaries to send frames 
> to express per-hop priorities).
> 
> consensus, that clarifies more about the corner cases and how they 
> should be handled.
> 
> It can be found at: 
> We are looking forward to hearing your comments either face-to-face, or 
> on the mailing list.
> 
> Thank you in advance.
> 
> To: Kazuho Oku <[email-masked]>, Lucas Pardue <[email-masked]>
> 
> 
> 
>  URL: https://www.ietf.org/internet-drafts/draft-kazuho-httpbis-priority-04.txt
>  Status: https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/
>  Htmlized: https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-priority
>  Diff: https://www.ietf.org/rfcdiff?url2=draft-kazuho-httpbis-priority-04
> 
>  Abstract:

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 21 Nov 2019 09:53:11 +0800

I agree with Martin’s comments. We really should emphasize that these are suggestions for improving the user experience that may need to be adjusted based on external knowledge by recipients.

Also, there is a spot in the document where Vary is mentioned as being appropriate. I don’t agree that Vary is ever appropriate for this feature because that changes the semantics of the priority in ways that are terribly unpredictable, nor is content negotiation on the basis of received Priority a good idea. I would simply require that Priority not be included in preemptive content negotiation and be done.

Even with these minor issues, I think this draft is a great improvement and is ready for adoption by the WG.

....Roy

> On Nov 21, 2019, at 8:17 AM, Martin Thomson <[email-masked]> wrote:
> 
> Kazuho,
> 
>> Subject: New Version Notification for draft-kazuho-httpbis-priority-04..txt

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 21 Nov 2019 10:00:04 +0800

> and is ready for adoption by the WG.

Oh, I forgot this.  I agree with Roy, we should definitely adopt this now.  The issues I raise are minor enough that we can work them out in the working group.

---

From: Robin MARX <[email-masked]>
Date: Thu, 21 Nov 2019 10:11:29 +0800

Hello Martin,

 > I understand that reprioritization was identified as being important by
the design team, but I don't recall seeing ever any evidence to support
that view.  Can we split that piece out and maybe pursue it separately?

Could you expand on this statement a bit more?
In my view, reprioritization has two sides: reprioritization from the
client after sending an initial priority and server-side reprioritization,
overriding the client's initial priority.

The first side comes into play when doing things like video/media streaming
when switching qualities (see e.g.,
https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/92) or for
the "switching tabs" use case that e.g., Ian keeps mentioning.

The second side was discussed at some length in our paper (
https://h3.edm.uhasselt.be/files/HTTP3_Prioritization_extended_3jul2019.pdf)
and also in a series of Cloudflare blogposts (e.g.,
https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/).
It is also imo mirrored in the intent of the priority hints proposal from
the W3C (https://github.com/WICG/priority-hints/blob/master/EXPLAINER.md).
One of the main reasons for simplifying the H2 scheme (next to
implementation complexity) is to provide an "absolute" priority indication
so that it's easier to reprioritize the responses on the server side.

Are you talking about both or one of these sides?
While I would agree we have less data for the 1st side, I do feel everyone
on the design team agrees this should be kept in.
Removing the PRIORITY_UPDATE frame would also lead to significant push back
from the Chrome team, as I understood from Ian (though I don't want to put
words in his mouth), and would make the proxy-to-origin case difficult
again.

With best regards,
Robin

On Thu, 21 Nov 2019 at 10:00, Martin Thomson <[email-masked]> wrote:

> Oh, I forgot this.  I agree with Roy, we should definitely adopt this
> now.  The issues I raise are minor enough that we can work them out in the
> working group.
>
>

-- 

Robin Marx
PhD researcher - web performance
Expertise centre for Digital Media

T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Nov 2019 10:15:40 +0800

Hi Martin,

Thank you for your comments. My personal responses inline.

> than a numeric item `4;i=?1`?

The primary benefit is to let the server update the "i" (interleaved)
parameter only. Sometimes, only the server knows If the response is
incrementally processible in a meaningful way (e.g., progressive JPEG vs.
baseline JPEG). It is therefore beneficial to let the server specify the
"i" parameter without messing with "u" (urgency).

The other benefit would be that providing room for future extensions to
define new parameters as SH Dictionary members rather than parameters, as
only the former can take be accompanied with a compound value.

>
> Can we look to simplifying this a little more?  I understand that
> reprioritization was identified as being important by the design team, but
> I don't recall seeing ever any evidence to support that view.  Can we split
> that piece out and maybe pursue it separately?
>

There seemed to be certain amount of agreement that three features
(client-driven prioritization, server intervention, reprioritization) was
necessary. That said, I agree that we can cleanly split reprioritization
from the scope of the draft, and at the moment I would not oppose to that
if that is the preference of HTTP WG.

>
> I would prefer to frame the way in which priorities are "merged" (Section
> 6) differently.  I would instead say that the priority information is input
> to prioritization decisions that endpoints/intermediaries/etc.. make.  So I
> would instead say that these entities simply make their own decision about
> the way to incorporate these signals into their decision.  That's probably
> a systemic thing that affects more than Section 6; I see that the draft
> uses "obey" in Section 7.1.1, for example.
>
> There seems - at least to me - to be an assumption on the part of some
> people involved in this that Priority will be interpreted as an
> imperative.  That is, that a client might be able to tell a server to act
> in a particular way and expect to have that instruction complied with.
> Same for servers and proxies.  That might be an appealing, but I can't see
> any way in which we can rely on that.  To the example in the draft, as a
> CDN, I would expect that the server's view carries more weight than the
> client's, but I wouldn't necessarily say that this something as absolute as
> is currently implied.
>

I agree that the priority parameters are merely hints, and that we do not
need to mandate exactly how they would be implemented. Though I think we
need to provide expectations on how H2/H3 terminators are expected to
prioritize is important for other endpoints using the signal.

> which you might want to double-check.

The parameters are SH dictionary members. Therefore `,` is the correct
answer.

-- 
Kazuho Oku

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 21 Nov 2019 02:53:53 +0000

To put my own thoughts on top of some of Kazuho's

> if that is the preference of HTTP WG.

I opened issue #1 on draft 00 as a question on reprioritiation. But I think
the important question to ask is, if we as WG agree to deprecate "HTTP/2
priorities" does that mean the signal, the tree-based model, the features
(setting, mutating, etc) or all of the above. My own view is that we are
not deprecating the features but instead grandparenting them in
unquestionably. The question of importance of reprioritization is totally
valid but I think it is unfair to place the burden of proving its
importance in a replacement, when RFC 7540 does not describe why it was
important in the first place. That said, I would be willing to explore this
further, and support the notion of a separate document but will caution
that carving the feature set too much will increase the chance that
implementers get this new scheme wrong by making assumptions based only on
initial priority. This is not a theoretical risk, there is a large survey
of reprioritization in the wild for some specific cases [1].

> prioritize is important for other endpoints using the signal.
I started a PR to tackle explanation some of the issues about merging
/collaboartion. I closed that closed it because I wasn't sure if useful,
but it sounds like there is some value and I can resurrect it.

Cheers
Lucas

[1] https://github.com/andydavies/http2-prioritization-issues

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 21 Nov 2019 12:45:39 +0800

Hi Robin,

On Thu, Nov 21, 2019, at 10:11, Robin MARX wrote:
>  > I understand that reprioritization was identified as being important 
> by the design team, but I don't recall seeing ever any evidence to 
> support that view. Can we split that piece out and maybe pursue it 
> separately? 
> 
> client after sending an initial priority and server-side 
> reprioritization, overriding the client's initial priority.

I refer specifically to the frame.

> The first side comes into play when doing things like video/media 
> streaming when switching qualities (see e.g., 
> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/92) or 
> for the "switching tabs" use case that e.g., Ian keeps mentioning.

These seem fairly obvious, but I realized recently that a lot of our thinking hasn't been grounded in any data.  That is, we're intuiting things about the value of the signal, but we never got firm reasons.

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Nov 2019 15:11:20 +0800

2019年11月21日(木) 9:54 Roy T. Fielding <[email-masked]>:

> I agree with Martin’s comments. We really should emphasize that these are
> suggestions for improving the user experience that may need to be adjusted
> based on external knowledge by recipients.
>
> Also, there is a spot in the document where Vary is mentioned as being
> appropriate. I don’t agree that Vary is ever appropriate for this feature
> because that changes the semantics of the priority in ways that are
> terribly unpredictable, nor is content negotiation on the basis of received
> Priority a good idea. I would simply require that Priority not be included
> in preemptive content negotiation and be done.
>

Roy, thank you for the review and the suggestion. I think you are correct,
I have opened
https://github.com/kazuho/draft-kazuho-httpbis-priority/pull/119 to address
the issue.

> .....Roy
> > Thanks for putting this together.  I only looked briefly, but this
> appears to faithfully capture what we discussed.
> >
> > I would prefer to frame the way in which priorities are "merged"
> (Section 6) differently.  I would instead say that the priority information
> is input to prioritization decisions that endpoints/intermediaries/etc..
> make.  So I would instead say that these entities simply make their own
> decision about the way to incorporate these signals into their decision.
> That's probably a systemic thing that affects more than Section 6; I see
> that the draft uses "obey" in Section 7.1.1, for example.
> >

-- 
Kazuho Oku

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 21 Nov 2019 10:16:11 +0100

First of all, thanks for Kazuho and Lucas for putting this together!

I agree with most of what has been already said, especially that it
should be adopted by the WG.

There seems to be consensus that priorities are hints for server and
not laws to obey.

The interleave setting is a new thing (yes, we had weights) and I am 
not sure if it is really something that clients want. I understood 
the mentioned use case, but before implementing this feature, I would 
really like to know more about the effects it has in various scenarios.

Cheers, Stefan

> Am 21.11.2019 um 05:45 schrieb Martin Thomson <[email-masked]>:
> 
> Hi Robin,
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sat, 23 Nov 2019 05:52:35 -0500

comments inline

On 20 November 2019 at 20.18.46, Lucas Pardue ([email-masked])
wrote:

Hi Mikkel,

On Wed, 20 Nov 2019, 20:57 Mikkel Fahnøe Jørgensen, <[email-masked]>
wrote:

> ...

Yes, I think an overview of the mechanism is needed. This email was up to
section 3.

On HTTP/2 I think it is warranted with a good explanation. I don’t think
more is necessary, and perhaps there is enough, but it is placed too early,
forcing focus on things that may not be material to the reader and confuses
grasping the core concepts.

Reading further, I don’t bother to comment, but a general observation was
the each section raised questions that were answered in later sections -
it’s hard to address all at once, but worth keeping in mind. A minor thing
is the inline graphics which intuitively, to me, means hex encoded SVG og
PNG, but that is not what is meant, and at the very end that becomes clear.
A larger issues are why servers send priorities in the first place (it is
eventually explained).

Intermediates are explained when reading all the way to the end, but it is
an example of confusion that arises while reading through the document. On
HTTP version neutrality I think that is fine, but it would help to be more
expliciit bout this, and mention why there are frames in some versions,
without going into details. As it is, the text appears a mixture of general
headers, and constructs (frames) that do not necessarily make sense, and
misleading because the heavy text HTTP/2 might lead one to think that it is
possibly only, or mostly, intended for HTTP/2.

Start of section 3, quote below. This text assumes detailed knowledge of
later text. It would be better to state that certain restrictions apply as
discussed in section (whaterever later section).

" If

   intermediaries want to specify prioritizaton on a multiplexed HTTP
   connection, it SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT
   change the Priority header field.

“

Cheers
Lucas