Re: Stream State and PRIORITY Frames

On Thu, Jan 19, 2017 at 4:00 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> What I'd like from Firefox is an explanation of why exactly PRIORITY is
> the first thing(s) happening here at all?
>
>
sure - see below. First, I think we need to revisit the primary motivation
for dependencies at all in h2:

When any client needs to forward requests from two or more contexts it
needs to balance them according to some policy. maybe that's fairness (each
user gets 1/2) or maybe that's some kind of class of service (foreground
tab gets 90%, other ones get 10%).. you can try and weight the streams to
make that happen, but there are N streams for each 'user' and that number
varies quickly over time, which would mean constantly reprioritizing the
weights.

The problem is solved with dependencies and grouping nodes (i.e. idle
streams). Each use can get equal weight (or whatever your policy) in
aggregate no matter how many streams come and go as long as they are rooted
in the same group.

The client in this scenario might be a proxy, looking for fairness among
users, or it might be a user-agent looking for a fair policy for balancing
different tabs. It doesn't matter.


> What exactly does it mean for them to set PRIORITY on a non-existent
> stream?
>

tl;dr; streams 3,5,7,9,b only ever have PRIORITY sent on them (and I
believe this leaves them idle). Subsequent 'normal' streams (of the HEADERS
ilk) are dependent on one of these 5 streams (generally directly, but
sometimes via a layer of indirection through another HEADERS based stream.)

These low numbered streams are 'grouping nodes' in the priority graph -
they have different weights and represent different classes of service
(things like background loads in the download manager are separated from
more low-latency things like css, etc..). As your session goes on over time
the HEADERS based streams close normally, but new navigations and uses root
themselves in the graph to those same low numbered grouping nodes - which
are meant to be persistent. They need not have full stream state (they are
after all still idle) - they are just a part of the dependency graph.. any
kind of LRU based eviction algorithm should easily keep them around in
practice.

I'm sure it will evolve over time.

It might be helpful if we had a mechanism where we could signal if one peer
made a PRIORITY assertion with a dependency that couldn't be resolved on
the other end because it evicted the relevant information.. that would let
the original peer reprioritize the stream.