Re: Priority straw man

Thanks for the proposal Osama!

Overall, I like this proposal. It incorporates a lot of our feedback
about the problems we've identified with the existing prioritization
mechanism. It is simpler in terms of protocol understanding, although
it has some other complexity costs, namely in usage, at least on the
client. I am hesitant to claim that this proposal is strictly better
or worse than our stream dependencies proposal, because I see some of
the appeal of keeping it simple. Let me point out some downsides and
things to consider:

* From a client perspective, when you only have priority levels, it
becomes harder to decide how to allocate the priority level ranges.
During dynamic request allocation (for example, during web document
parsing), it's common to want to insert a request at a priority level
in between two other requests. document.write() is an obvious example
of this. And let's be clear, this is extremely common in web
documents, and even more common with web apps where much more of the
loading occurs dynamically using scripts. A dependency list makes this
elegant since you simply need a list insertion operation. With integer
priority levels, now you have to pre-plan the integer ranges and leave
spaces in between to allow insertion of stream priorities in between
different streams. And it's unclear where to insert it...halfway in
the priority range between two streams? When we get it wrong, we may
need to blast out a lot of PRIORITY frames to correct this.
* Also from a client perspective, how do you describe a pipeline of
ordered resources? Video frames are the obvious example. You want
frame 1 before frame 2 before etc.
* Let's now make it more complicated. What happens when you fast
forward or rewind in the video? What happens when you scroll within a
loading document? How do you dynamically reprioritize large numbers of
streams?
* What's WinInet's API going to look like? Is it going to punt
knowledge/responsibility of HTTP/2 priority levels out to the
application, and let the application decide how to heuristically
assign these priorities?

By keeping the protocol semantics simple, we impose more burden on
application developers to utilize heuristics to assign priorities. Is
it the right tradeoff?

I think that HTTP/2 removes the need for many browser/client-side
heuristics which is a great thing. I'd like to remove more of them. I
think that this new proposal is a step in the right direction, but it
doesn't go as far as I'd like. But I wholeheartedly approve of it as
an improvement over what currently exists in the spec.

Cheers.

On Thu, Feb 6, 2014 at 8:44 AM, Peter Lepeska <bizzbyster@gmail.com> wrote:
> I like the way that the dependencies give us additional information about
> the way that the page is constructed. This information can be useful for
> various applications I can think of. However, if this is our goal:
>
> "The purpose of prioritization is to allow an endpoint to express how it
> would prefer its peer allocate resources when managing concurrent streams.
> Most importantly, priority can be used to select streams for transmitting
> frames when there is limited capacity for sending."
>
> Then I can't think of anything that the dependency-based approaches allows
> us to do that cannot also be accomplished via Osama's proposal and I agree
> with the five benefits he outlines.
>
> Can anyone else think of a benefit to the dependency-based approach from the
> perspective of allowing an endpoint to express how it would prefer its peers
> to allocate network resources?
>
> Thanks,
>
> Peter
>
>
> On Thu, Feb 6, 2014 at 8:59 AM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
> wrote:
>>
>>
>> On Feb 4, 2014, at 3:16 PM, Osama Mazahir <OSAMAM@microsoft.com> wrote:
>>
>> > Priority is definitely useful when you have more DATA to send than
>> > network capacity.  However, Microsoft has no interest in implementing
>> > dependencies; neither advertising nor honoring across IE, IIS, client stack
>> > APIs and server stack APIs.
>> >
>> > Being able to express an ordering relation is valuable but the approach
>> > should be more decoupled from the stream lifecycle and more stateless on the
>> > server.  Below is our feedback and suggested changes.  The one-liner
>> > explanation of the change is: replace the Stream Dependency field with a
>> > numerical priority field.
>> >
>>
>> +1
>>
>> I prefer Osama's proposal. Without relying on "ghost" streams is a good
>> property.
>> The complexity of dependency is only paid by the client that wants it and
>> server just uses the numerical value. Also the simple browser which uses
>> static priority based on content type works fine without additional priority
>> adjustment which described in
>> http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0415.html
>>
>> Best regards,
>> Tatsuhiro Tsujikawa
>>
>>
>> On Wed, Feb 5, 2014 at 5:55 AM, Michael Sweet <msweet@apple.com> wrote:
>>>
>>> +1
>>>
>>> Seems like this will work for both client->server and
>>> client(s)->proxy->server(s) without too much effort in the proxy, and it
>>> gives us a simple method of grouping priorities to prevent starvation.
>>>
>>>
>>> On Feb 4, 2014, at 3:16 PM, Osama Mazahir <OSAMAM@microsoft.com> wrote:
>>>
>>> > Priority is definitely useful when you have more DATA to send than
>>> > network capacity.  However, Microsoft has no interest in implementing
>>> > dependencies; neither advertising nor honoring across IE, IIS, client stack
>>> > APIs and server stack APIs.
>>> >
>>> > Being able to express an ordering relation is valuable but the approach
>>> > should be more decoupled from the stream lifecycle and more stateless on the
>>> > server.  Below is our feedback and suggested changes.  The one-liner
>>> > explanation of the change is: replace the Stream Dependency field with a
>>> > numerical priority field.
>>> >
>>> > Certain details, such as the bit widths (X, Y and Z), are purposefully
>>> > omitted to keep the focus on design.
>>> >
>>> > ==== OVERVIEW
>>> >
>>> > - A stream is assigned to a group
>>> > - A stream is assigned a priority that represents its importance, with
>>> > respect to other streams, within its group
>>> > - A group is identified by a group ID
>>> > - A group is assigned a weight that represents its importance, with
>>> > respect to other groups, within its connection
>>> >
>>> > The client knows the relative importance of streams and is trying to
>>> > convey a simple representation of that information to the server so that the
>>> > server can choose to allocate resources more intelligently.  Priorities and
>>> > weights are merely advisory and do not guarantee any specific server
>>> > behavior.
>>> >
>>> > Group weight defines a proportional definition of importance with
>>> > respect to other groups.  For example, if Group1, Group2 and Group3 are
>>> > assigned weights 1, 3 and 6, then ideally they receives 10%, 30% and 60% of
>>> > the resources, respectively.
>>> >
>>> > Within a group, stream priority defines a strict ordering of
>>> > importance.  If two streams have the same priority then their resource
>>> > assignment is server implementation specific (e.g. round robin, shortest job
>>> > next, first in first out, etc).
>>> >
>>> > The PRIORITY frame payload (the same payload can also be included as
>>> > part of the HEADERS frame) contains:
>>> > - Group ID        (X bits)
>>> > - Group Weight    (Y bits)
>>> > - Stream Priority (Z bits)
>>> >
>>> > Similar to what it does currently, the payload assigns the given stream
>>> > (from the encapsulating frame header) to the specified Group ID, sets the
>>> > given Group Weight and assigns the stream the given Stream Priority within
>>> > that group.
>>> >
>>> >
>>> > ==== MOTIVATION
>>> >
>>> > 1) Robustness
>>> > This avoids the server from having to track relationship dependencies
>>> > between streams.  Consequently, the design race where the a stream will
>>> > close while prioritization information that creates a dependency on that
>>> > stream is in transit is eliminated.  Which also eliminates having to
>>> > maintain state about closed streams after closure (and all subsequent timer
>>> > or load based purging).  Increasing the decoupling from the stream lifecycle
>>> > is design goodness.
>>> >
>>> > 2) Changing a stream priority is clearer
>>> > In the case where a stream has to be reprioritized, all its children
>>> > need to be reprioritized to their new parent via new dependency
>>> > advertisements.  With simple priority numbers, this becomes a simple one
>>> > priority change operation.  See
>>> > http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0395.html
>>> >
>>> > 3) Simplicity
>>> > Simpler to describe.  Simpler for basic server and proxies to
>>> > implement.  Don't pay for complexity in the base cases.  The client is free
>>> > to have arbitrarily complex prioritization determination schemes (e.g. not
>>> > necessarily tied to rendering tree) and can afford to spend CPU/memory/etc
>>> > on this.
>>> >
>>> > 4) Equivalency
>>> > The tree examples used in the current issue #364 proposal can be
>>> > represented using this weight+priority scheme.  Having Z bits (i.e. the
>>> > Stream Priority width) will allow us to represent a tree of depth 2^Z.
>>> >
>>> > 5) Simple Priority Collapsing
>>> > Proxies, and perhaps servers, may want to limit the amount of
>>> > concurrent priorities/depth they track.  Using numerical priorities opens
>>> > the ability to have a stateless reduction/mapping.  For example, a
>>> > proxy/server might do something like: internal_priority = wire_priority >>
>>> > 3.
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: Martin Thomson [mailto:martin.thomson@gmail.com]
>>> > Sent: Monday, February 3, 2014 9:45 AM
>>> > To: HTTP Working Group
>>> > Subject: Re: Priority straw man
>>> >
>>> > I'm starting to get ready for -10, which I would very much like to push
>>> > soon.
>>> >
>>> > More feedback would be nice, but absent stronger feedback, I'm going to
>>> > push the button on this for -10.
>>> >
>>> > p.s., The suggestion for PRIORITY on stream zero requires additional
>>> > changes and a little more support, so I'll ask for that to be tracked
>>> > separately.
>>> >
>>> > On 26 January 2014 13:34, Martin Thomson <martin.thomson@gmail.com>
>>> > wrote:
>>> >> As requested, a writeup on prioritization.
>>> >>
>>> >> As a pull request: https://github.com/http2/http2-spec/pull/364
>>> >>
>>> >> In HTML form:
>>> >> http://martinthomson.github.io/drafts/priority.html#StreamPriority
>>> >> http://martinthomson.github.io/drafts/priority.html#PRIORITY
>>> >>
>>> >> Comments or pull requests happily accepted.
>>> >
>>>
>>> _________________________________________________________
>>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>
>>
>

Received on Friday, 7 February 2014 22:47:22 UTC