W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: h2 priority

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 3 Sep 2014 15:15:20 -0700
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <F5D0B8E3-E28B-4BF1-A880-8A3721324B24@gbiv.com>
To: Patrick McManus <mcmanus@ducksong.com>
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
Received on Wednesday, 3 September 2014 22:15:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC