Re: Restarting the discussion on HTTP/2 stream priorities

On 28 October 2013 14:32, William Chan (陈智昌) <willchan@chromium.org> wrote:
> I think that the second point is far more controversial and requires more
> discussion.

It may be the case that you find the first issue compelling enough
that a change of some form is justified regardless of what you think
on the second :)

Of course, I think that there are some significant problems with the
proposal, most of which I think that you will find are easy to fix.

The first is largely procedural.  I've have people complain about the
use of references to documents like the above for archival and IPR
reasons.  Maybe copying and pasting the entirety of that document to
an email will address those concerns.  Maybe it will also help you
understand that it is a little wordy and that perhaps the essence of
your proposal could be made more succinctly :)

The second is that the idea of prioritization between separate trees
isn't really described as being prioritization.  I think that what you
want to do is a proportional allocation of resources between those
trees, so a term like "weight" is probably more accurate.  You even
use that word later.  (Oh crap, I just realized that this is a classic
case of "the names aren't important, the standards committee always
changes them anyway" scenario, sorry.)

Probably more substantially, you need to be a little more concrete
when it comes to requirements for managing placeholders and garbage
collection.

The settings seem like over-engineering to me.  I'm sure that a server
implementation can arrive at a reasonable set of behaviours that
doesn't degrade too badly for their common workloads without settings
being exchanged.  When it comes to resource exhaustion, I think that
it's probably more appropriate to deal with those in the DoS
considerations than with settings.

On the over-engineering theme, the idea that you can reprioritize
multiple streams with a single PRIORITY frame concerns me.  That's
going to mess with intermediaries of all sorts.  The cost of a
PRIORITY frame for each stream is 4 bytes per stream, but then you
weren't going to bother with that anyway.

Please consider placing default values on priority.  Since you are
only going to be able to provide either a dependency or a weight, the
complementary item is going to inherit a default.

Received on Monday, 28 October 2013 22:35:03 UTC