W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Some HTTP 2.0 questions

From: James M Snell <jasnell@gmail.com>
Date: Thu, 5 Dec 2013 09:01:53 -0800
Message-ID: <CABP7RbdHECGeu1=1Ox3dojJhaB0Gt2X_cb=wQebRJeWE5WYFFQ@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Roberto Peon <grmocg@gmail.com>, Adrien de Croy <adrien@qbik.com>, Martin Thomson <martin.thomson@gmail.com>, Mark Watson <watsonm@netflix.com>, HTTP Working Group <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC