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

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).

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.

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.

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.
>