Re: PRIORITY extension

On Sun, Jul 13, 2014 at 9:10 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> I don't really understand why the flow control mechanism is not sufficient
> to implement priority?
>
> My understanding of the use-case for priority is when a client received
> many push promises and/or makes make parallel requests, then it can
> stipulate which ones it wants to receive first.  Why can't it use flow
> control windows to achieve this?
>
>
Tatsuhiro is right.

The most important reason is that the semantic you want is "among the N
things you have *available to send right now* these are the releative
importances and dependencies". And the receiver providing the priorities
cannot know the available set. It knows the outstanding set of requests but
some of them may be blocked (on disk i/o, on backend callouts, on auth,
etc..). Any scheduling algorithm benefits from having choices - if you
reduce the choices sometimes the answer is wasted idle bandwidth.

Right now with h1 browsers do silly tricks that more or less approximate
your suggestion (and indeed I'm contemplating some h1 changes that would
look even more like your suggestion). The most well known is that image
requests are basically held back while impt html/js/css is transferring.
This helps responsiveness because the image parallelism doesn't slowdown
the stuff that blocks rendering (that's why we do it), but it also results
in wasted idle bandwidth - only when the blocking resources have been
transferred do the image requests go out and that creates at least a 1 RTT
delay when compared to a prioritization scheme where the requests are all
sent immediately with the appropriate priorities.. (and its actually worse
than that if any of the html/js/css blocks). An h2 game where flow control
windows were turned up and down (h2 actually doesn't let you turn them down
- though of course it could be added) would be a similar mechanism.

Priority is a much better answer - send the requests as soon as you are
aware of them, but label the priority appropriately.