Re: Some HTTP 2.0 questions

------ Original Message ------
From: "William Chan (陈智昌)" <willchan@chromium.org>
To: "Martin Thomson" <martin.thomson@gmail.com>
Cc: "Adrien de Croy" <adrien@qbik.com>; "Roberto Peon" 
<grmocg@gmail.com>; "Mark Watson" <watsonm@netflix.com>; "HTTP Working 
Group" <ietf-http-wg@w3.org>
Sent: 5/12/2013 12:24:43 p.m.
Subject: Re: Some HTTP 2.0 questions
>I think they should use strict prioritization. If it's long-lived 
>prioritization, the client is free to update the advisory priority with 
>a new PRIORITY frame.
if there are multiple clients on the connection, this is just a race to 
the top priority level.  Also requires the client to try to figure out 
what the server is doing to send more commands that the server then 
needs to process amongst all the other things it is already doing.  I 
don't think this will result in a great deployment experience.

we found from our bandwidth control experience, that you still need to 
process some lower priority stuff occasionally.

Maybe this means we should ditch priority for weighting.  Or strongly 
discourage priority (if it is to be strict) in favour of weighting?

>Moreover, in the prioritization proposal I emailed out before and 
>converted into an I-D, it's possible to reprioritize to assign 
>weighting instead of dependencies. If you truly want weighting, use a 
>weight.
>
>
>On Wed, Dec 4, 2013 at 3:10 PM, Martin Thomson 
><martin.thomson@gmail.com> wrote:
>>
>>On 4 December 2013 13:23, Adrien de Croy <adrien@qbik.com> wrote:
>>>Surely in practise there will need to be some processing of pending 
>>>lower-priority streams whilst there is still higher priority traffic 
>>>pending.  So the prioritisation would be more like a weighting than a 
>>>strict prioritisation.
>>
>>Yes, that would be how I'd interpret that.  We should probably even 
>>*say* that, so that we don't generate situations where clients are 
>>reluctant to prioritize certain types of resources in certain ways 
>>lest they generate a starvation situation for themselves.
>