Re: Some HTTP 2.0 questions

Actually, I quite liked the large priority value space and the strict-ish
rule that the server should always send the highest priority data available.

That would enable the use-case I described, where audio and video chunks
are given priority values equal to their presentation time (in ms, say).
That nicely copes with the case where the chunk boundaries are not aligned
between audio and video.

...Mark


On Thu, Dec 5, 2013 at 9:01 AM, James M Snell <jasnell@gmail.com> wrote:

> 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.
> >>>
> >>>
> >>
> >
>