Re: Question about HTTP 2.0 priority

2014/10/10 3:09 "Chad Austin" <caustin@gmail.com>:
>
> 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].
>

Nghttp2 implements dependency based periority.  It also supports 1 and 2
behaviour you described above.  You can test nghttp2 server at
https://nghttp2.org

Best regards,
Tatsuhiro Tsujikawa

> 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>
wrote:
>>
>> On 6 October 2014 22:48, Chad Austin <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