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

On Fri, Jul 12, 2019 at 12:36 PM Patrick Meenan <patmeenan@gmail.com> wrote:

> I'm somewhat opposed to defaulting to concurrency=1 and using a lot of
> bits for a priority to handle sequencing because it introduces the problem
> of needing to know what other requests are in-flight and their priorities
> to set the appropriate sequence (the state that I was largely trying to get
> rid of when we implemented Cloudflare's prioritization).
>

There's state on the client, but it's a simple table. There's no state on
the server, unless you're expecting the server to reverse-translate the
priorities, which seems unnecessary (see below). That said, I don't feel
too strongly about this.


> By using absolute priorities tied to the request/response itself the
> browser rendering engine, the CDN back-ends and even the origin server
> application code, all of which are well outside of the connection itself,
> can influence and adjust the priorities of resources at an absolute level
> and still trust that they will be delivered in a reasonable order when it
> gets to the code that is actually managing the connection. Otherwise you're
> going to end up having an absolute scheme defined on either end (like the 5
> levels internal in Chrome and Cloudflare's header-based scheme) and doing a
> translation at the wire layer anyway.  If we encode an absolute scheme
> directly then the clients on either end can eventually migrate to using it
> directly.
>

I feel more strongly about this: If the server wants to suggest a
prioritization for subresources, I don't follow why the best place to do
that is in the HTTP response for the subresource itself, rather than in the
preceding HTML response. For example, we might define link elements like:

Link: rel=priority href=foo.js priotity=whatever

The HTML's response header can include link elements like this one. The
"whatever" can be some globally-understood thing, where the browser can
translate "whatever" to underlying H2/H3 priorities however it wants.


> It's also not necessarily strictly point-to-point.  At my origin I may
> decide to implement a query-param-based scheme for prioritization for
> resources that are always the same (template code in the head of my pages
> for example) where the server is configured to always set the priority for
> those as "critical script", independent of what the browser requested. The
> CDN in the middle doesn't need to know the application-specific knowledge
> that I created between the front-end code and the origin, it just needs to
> cache the priority headers along with the resources and respect whatever
> the origin responded with.
>

It's very roundabout to inject a priority into HTML, route that through a
CDN, to an origin server (via a subresource query param), then communicate
that back to the CDN via a response header. Not to mention:

- What about <link rel=prefetch>? You can't use different query params,
because that would break the prefetch.
- What if your page is loaded in an iframe within some other page? Your
server-assigned priority might be correct in the iframe context, but not in
the whole-page context if the browser has lowered the iframe's priority.
- What if your page is loaded in a background tab? Maybe the browser wants
to lower the priority of background tabs. But it can't, if the server will
override that decision.

The Link proposal above appears to be simpler and more flexible. The
browser might want this information anyway, for other reasons, such as to
throttle cache lookups.

For the security contexts and other uses for knowing WHY a specific
> resource is important, I'd strongly encourage not trying to overload the H3
> priority scheme with that data and leave that to the fetch metadata spec
> that Mike West is working on.
>
> On Fri, Jul 12, 2019 at 3:16 PM Tom Bergan <tombergan@chromium.org> wrote:
>
>>
>> I think I did a poor job explaining my argument.
>>
>> Your current proposal has 4 urgency bits and one concurrency bit (aka
>> "progressive" or "incremental"). I am saying that we can default to
>> concurrency=1 given enough urgency bits. For example, given ~53 bits (using
>> an sh-integer), we can define the following translation:
>>
>> func TranslatePriority(urgency4bits int, progressive bool) uint64 {
>>   if progressive {
>>     return urgency4bits << 49
>>   } else {
>>     seq := nextSeq[urgency4bits]  // where nextSeq[x] is initialized to
>> 2^49-1
>>     nextSeq[urgency4bits]--
>>     return (urgency4bits << 49) | seq
>>   }
>> }
>>
>> This is almost equivalent to your proposal, except for caveats about how
>> (urgency=X, progressive=false) is ordered with respect to (urgency=X,
>> progressive=true). Those caveats seem unimportant in practice.
>>
>