Re: h2 priority

Hi Roy,

So the priority dependencies is really a feature googlers championed, I'm
surprised that we haven't seen anyone from that team contributing to this.
I do, however, support it so I'll carry on the discussion.

The most important bit of consensus was that experience has shown us the
few bits of spdy priority can't be aggregated well. The easiest
illustration is a proxy...

if 2 inbound sessions have 3 streams each of priorities {0,1,2} and {5, 6,
7} all headed to the same origin what is a reasonable implementation for
the priorities on the 1 outbound session? The incoming priorities only have
meaning wrt other streams in the same session, they have no global meaning.
Each client is incented to pick priorities at the most important end of the
spectrum - indeed perhaps to only use the highest priority which is back to
having no priority at all.

So that was the core issue that motivated a more complicated scheme, and I
think there was strong support around that. And of course things other than
proxies aggregate.. OS's.. even browsers between tabs and plugins are
basically doing the same function sometimes with more context than others.

After that you get into more speculative use cases for sure. I've got one
whiteboarded regarding dependencies for images based on what the layout
engine says might be visible at any moment in time, but its stalled mostly
on non-network internal browser stuff of figuring out what might be visible
at any moment in time :) For the most part I agree we are basically
speculating on what might work in that space right now, but the previously
mentioned aggregation bits were a known problem that the text sought to
address.

hth



On Wed, Sep 3, 2014 at 6:15 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> Hi Patrick,
>
> Sorry, I almost missed this one in the noise ...
>
> On Sep 2, 2014, at 8:28 AM, Patrick McManus wrote:
>
> On Sun, Aug 31, 2014 at 7:06 PM, Roy T. Fielding <fielding@gbiv.com>
> wrote:
>
>>
>>
>> The reason I did not go into any more detail than that is because the
>> priority information is only a suggestion, like in h2.  Defining how
>> the recipient is going to reprioritize its stack based on existing
>> streams is an implementation detail behind the HTTP interface: wishful
>> thinking and untestable (because it is only a suggestion).  Editorially,
>> section 5.3 belongs in an appendix, or as a separate spec that has time
>> to ruminate on the balance between weighted streams and various
>> response characteristics.
>>
>
> Editorially and organizationally I think you're right but am happy to
> defer to the editor. As a matter of content, I think the fairly complicated
> scheme is well justified in terms of identified problems spdy has shown
> with using just a few bits of weight (aggregation of lots of clients, dash
> like dependencies, etc..)
>
>
> Does that mean it has been implemented?  I mean, does the weighted tree
> with stream dependencies result in effective prioritization by a server?
>
> I am curious about that because I see most UA traffic as parallel with
> aborts, rather than dependent streams, and expect a user agent to
> prioritize
> by fairly well-understood latency buckets (critical path, js, renderable
> content, not-rendered-yet content, background prefetch, long pull, etc.).
> IOW, I don't see how a client can guess which streams are "more important"
> other than by the perceived latency buckets.
>
> > 6.2.  HEADERS
>> >
>> Priority is a suggestion.
>
>
> imo it is only really a suggestion in the sense that it is untestable.
> Priority is a core piece of h2, because h2 introduces mux and a
> non-prioritized mux is worse than h1.
>
>
> Well, worse than h1 + multiple connections.  Yes, that's why I thought
> priority would be important as well.  What I found disconcerting
> is that the spec takes a deep dive into explaining how priorities work,
> before it even defines the frames, and yet doesn't actually use any of
> that stuff in examples or later prose.
>
> ....Roy
>
>