Re: Some HTTP 2.0 questions

I'm certainly not an expert on the priority issue but relative
weighting definitely seems significantly better than the currently
insanely large priority value space. Perhaps even something as simple
as a single 8-bit increment would work... e.g.

0000 0000 = default priority weight
0001 0000 = +1
0010 0000 = +2
0011 0000 = +3
 ...
1111 0000 = +15
0000 0001 = -1
 ...
0000 1111 = -15

These would be proportional weights that could be adjusted and
balanced as necessary.

I dunno, like I said, I'm not an expert in this particular area so
this particular idea may just be nonsensical. Looking forward to
seeing the proposed modification.


On Wed, Dec 4, 2013 at 4:29 PM, William Chan (陈智昌)
<willchan@chromium.org> wrote:
> +1
>
> Just to be clear, you've identified a problem with a single priority
> context, since it makes every priority value global. But you could group
> streams into a priority context/group, in which case you have relative
> prioritization within groups. And amongst different groups, you should
> probably use weighting.
>
>
> On Wed, Dec 4, 2013 at 3:44 PM, Roberto Peon <grmocg@gmail.com> wrote:
>>
>> With our proposal (which Will is writing up), we address the proxy problem
>> directly.
>> It was one of the motivations for the proposal in the first place :)
>>
>> -=R
>>
>>
>> On Wed, Dec 4, 2013 at 3:42 PM, Adrien de Croy <adrien@qbik.com> wrote:
>>>
>>>
>>>
>>> ------ 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.
>>>
>>>
>>
>

Received on Thursday, 5 December 2013 17:02:46 UTC