Re: Question about HTTP 2.0 priority

On Mon, Oct 6, 2014 at 10:26 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 6 October 2014 22:13, Chad Austin <caustin@gmail.com> wrote:
> > Sorry for the terrible ASCII art.  :)  Everything at priority B depends
> on
> > some element in A, and everything in C depends on some element in B.
> >
> > How do I handle the case that B1 completes before B2?
>
> I tend to write it out like so:  (A1, A2, A3) -> 0; B1 -> A1; B2 -> A1
> and B3 -> A1; C1 -> B1; C2 -> B1; and C3 -> B1.
>
> So yes, if B1 is removed, then all the C moves up to depend on A1...
> and takes a proportional weight from the removed B1.
>
> But the draft recommends not removing when a stream completes, because
> that loses information.  Keep it around.  Put it in a LRU list or
> something and remove it when you have to, or when it isn't referenced,
> or when it is too old.  Then you lose nothing more than a few bytes of
> RAM, and maybe a few extra cycles when nearby elements move around, or
> are added.
>

"Keep it around."

Are you suggesting that either the client, server, or both keep it around?
Does it matter if it's half closed?

If an efficiently prioritizing server can simply keep the dependencies for
old streams around then my concern is less valid.

A linked list is fine for nodes with the same dependency, but I tend
> to think of it as a set.  A skip list might be more efficient if you
> think that you'll have lots of adjacent nodes.
>

[Note: the next two paragraphs are only relevant if for some reason it's
hard to keep old stream records around.]

Yeah, all nodes at a given priority *are* a set, but it sounds like there's
no way to get set dependency semantics without a linked list.  A linked
list is too much precision: I don't particularly care the order of
completion within a priority level.  A skip list, while slightly more
efficient for the server, allows a bit of "priority leakage".

It's not the worst thing in the world, but ultimately we're going to be
pushing the customer experience as hard as we can.  With a linked list (and
an optimally prioritizing server), the theoretical lower bound on load
times is ideal: the customer's network connection wouldn't even begin
consuming bandwidth on low-priority responses until the high-priority
responses are done.

-- 
Chad Austin
http://chadaustin.me