RE: Question about HTTP 2.0 priority

Note that priority is always strictly advisory - the client cannot "rely" on the server having any particular behavior in response to the priority information it sends.  The priority field permits the client to provide the server additional information to consider when making its own decisions about how to allocate resources.  A server would be completely compliant with the HTTP/2 protocol to return the resources with A1 last.  Now, that's probably not a good implementation unless there's some factor the client doesn't know about - but that's the point.  There might well be, and the protocol doesn't forbid that case.

From: Chad Austin [mailto:caustin@gmail.com]
Sent: Thursday, October 9, 2014 11:05 AM
To: Martin Thomson
Cc: Amos Jeffries; HTTP Working Group
Subject: Re: Question about HTTP 2.0 priority

Thanks, Martin.  If a client can rely on two things, then a linked list is not necessary:
1. the server will keep the priority tree information for closed streams "long enough"
2. In the case of "(A1, A2, A3) -> 0; (B1, B2, B3) -> A1", if A1 completes before A2, the server will apply any available resources to A2 and A3 before any of B1, B2, or B3.
Sounds like you're saying #1 is likely.

Can you confirm that #2 is also the behavior specified by the current draft?

Are there any implementations of HTTP 2 priority semantics in the wild?  Do we have any real-world experience with how they work?  Will Chan argues compellingly that prioritization is a crucial part of SPDY [1] -- where 3 bits has been precise enough for basic browser use cases -- and it seems the HTTP 2 stream priority model originates from his deck Considerations for HTTP/2 Prioritization [2].
What's your over-under on whether a future protocol or version of HTTP 2 would support numeric priorities in addition to or in lieu of the stream dependency model?
I ask because I'm simultaneously pushing to have a request prioritization API added to browsers, and it seems a bit optimistic for the API exposed to JavaScript to map directly to HTTP 2 semantics.

[1] https://insouciant.org/tech/prioritization-is-critical-to-spdy/
[2] https://docs.google.com/presentation/d/1OfgPJsW6P7pky5PiyEzBNZnf5dWXq-y19ReSSg6BIeM/pub

On Tue, Oct 7, 2014 at 1:34 PM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
On 6 October 2014 22:48, Chad Austin <caustin@gmail.com<mailto:caustin@gmail.com>> wrote:
> Are you suggesting that either the client, server, or both keep it around?
> Does it matter if it's half closed?

Well, a client that knows it's not going to use a stream as a basis
for prioritization can discard the state immediately.  A server
doesn't have that opportunity, so it has to use some heuristics to
determine what to keep and what to delete.

The point is that prioritization state isn't strictly tied to stream
state.  If stream 7 depends - or could depend - on stream 5, stream 5
might be closed at the server when initial or updated priority
information for stream 7 arrives.  If the server cares about
respecting prioritization for stream 7, it had best find a way to keep
stream 5 in its priority graph somehow.



--
Chad Austin
http://chadaustin.me