Re: Priority straw man

+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