Re: PRIORITY extension

2014/07/14 10:14 "Greg Wilkins" <gregw@intalio.com>:
>
>
> 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?
>
> Is it the case that priority is needed for small resources that will not
need a window update to be sent?   But in that case, if you have 80
resources being pushed at you, 70 of them are probably in single frames so
by the time the client knows which ones it wants first they have probably
already been sent / queued etc.?
>
> ie in all the scenarios that I can imagine, I can see flow control
windows being able to be used to control priority just as well as priority
frames.
>
> Perhaps somebody can writeup a few good examples of how they see priority
helping where flow control cannot?
>
> thanks
>

Supporse client requested 2 resouces and they have priority weight 200 and
20.  With priority, server can send low prioritized resource with full
bandwidth if higher one is blocked (e.g., waiting file io or processing or
flow controll etc).
Without priority and small flow controll window is used, low prioritized
resource cannot use full bandwidth and suffers from performance
degradation. You may argue that client can increase window in this case,
because of latency it is too late to doing this and just make things messy.

Best regards,
Tatsuhiro Tsujikawa

>
>
>
>
>
>
>
> On 14 July 2014 10:58, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
>>
>>
>> 2014/07/14 9:46 "Patrick McManus" <pmcmanus@mozilla.com>:
>>
>>
>> >
>> > The whole point of h2 is a prioritized, muxxed protocol with improved
connection handling.
>> >
>> > Let's complete that work.
>> >
>>
>> I couldn't agree more.
>> Removing PRIORITY is really bad idea.
>>
>> Best regards,
>> Tatsuhiro Tsujikawa
>>
>> > -P
>> >
>> >
>> >
>> > On Sun, Jul 13, 2014 at 7:55 PM, David Krauss <potswa@gmail.com> wrote:
>> >>
>> >>
>> >> On 2014–07–13, at 4:46 AM, K.Morgan@iaea.org wrote:
>> >>
>> >> > As far as I can tell, everything in h2-13 related to PRIORITY is
completely optional (please correct me if I'm wrong).
>> >> >
>> >> > I've repeatedly seen arguments against adding anything optional to
the spec. So why does PRIORITY get a pass? If it's truly optional, it could
easily be moved to a separate RFC as an extension.
>> >>
>> >> I’m in favor.
>> >>
>> >> Clients wishing to send PRIORITY should know whether the server is
just going to ignore it. It’s a good signal to use another prioritization
strategy, for example by reducing concurrency (start streams later).
>> >>
>> >> Also, it’s had the most churn of any part of the spec and practical
experience will take more time. Extension status will enable faster
evolution.
>> >>
>> >>
>> >
>
>
>
>
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
scales
> http://www.webtide.com  advice and support for jetty and cometd.