Re: Question about HTTP 2.0 priority

Hi Mike,

I fully understand that priority is advisory.  In practice, however,
priority is critically important, and we will implement solutions that take
full advantage of it.  (We will also push our CDN partners, HTTP servers,
etc. to have reasonable behavior.)  Without priority, there's no way to
both maximize the customers' network connection AND minimize
time-to-interactivity and time-to-perceived-load.

Without priority, HTTP 2 can be slower than HTTP!  Browsers maintain a
fixed-size HTTP connection pool which is fed from a priority queue of
requests.  See the analysis here:
https://insouciant.org/tech/prioritization-is-critical-to-spdy/

If a server does not implement reasonable priority semantics, clients must
sacrifice effective network utilization by waiting for all high-priority
responses before issuing any low-priority requests.  Especially on
high-latency connections, this results in a poor customer experience.

And, of course, the most interesting thing about this entire discussion is
that managing a request priority queue is often very easy for both clients
and servers.  I will expect all high-quality HTTP 2 caching proxies and
CDNs to implement priority.

I still wonder whether a simple 8-bit or 32-bit priority value would have
been superior of the stream tree model.  However, I'm also prepared to
handle the situation where HTTP 2 ships as currently-specified.  :)

Thanks,
Chad



On Thu, Oct 9, 2014 at 11:17 AM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

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



-- 
Chad Austin
http://chadaustin.me