Re: h2 priority

On Sep 4, 2014, at 9:57 AM, Patrick McManus wrote:

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

Well, I can't say much about SPDY priorities because they are just numbers.
The two bits that I used in waka benefit from having fewer choices since
that is easy to understand and partition between shared connections.
What happens is that the recipient splits traffic equally among multiple
streams with the same priority and the proxy pumps up the priority of a
stream if one of the two (or more) clients is being starved (which should
only occur if that client has only zero-priority streams remaining).

There is still nothing to prevent any one client from getting greedy and
asking for high priority all of the time, but a server is not required
to obey the priorities.  A server might be setting its priorities based on
source behavior (e.g., AOL proxies were a common target for unusual
server settings) or on past browser statistical profiles (the same ones an
h2 server might use to determine when push_promise is useful).

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

Okay, thanks for the info.  I'd be happier if there were a real example
of stream dependencies working in practice, since that is 32 bits.
Are stream dependencies intended to reflect tabs?

....Roy

Received on Thursday, 4 September 2014 17:50:03 UTC