Re: Priority straw man

Jeff,

On Feb 8, 2014, at 1:22 PM, Jeff Pinner <jpinner@twitter.com> wrote:
> I will try to clarify my concerns and address Michael's response:
> 
> On Sat, Feb 8, 2014 at 8:50 AM, Michael Sweet <msweet@apple.com> wrote:
> Jeff,
> 
> I look at the groups as relative QoS groups, e.g. group 1 needs 80% of the bandwidth and group 2 needs 20%.  And within each group you use the priority to determine the order of packet delivery.  And within the priority each client can determine an optimal subdivision of values to allow for insertion of new streams without painful re-prioritization.
> 
> 
> Let's assume for sake of argument and simplicity we have 2 priority levels (add more levels and add more streams and the point remains the same). Let's also assume, as a proxy, we receive from some client two groups, each with two streams:
> 
> G1 (80% w/ S1 (pri 0) and S3 (pri 1)) and G2 (20% w/ S5 (pri 0) and S7 (pri1))
> 
> If I need to proxy this to some backend, I will likely need to merge the priority groups (as I have more incoming connections than outgoing connections). So with "n" incoming connections, I will send to the backend something like:

I don't see how this would necessarily follow.  A equally valid implementation would preserve the client's priority groups and create additional outgoing connections as needed should the group ID space be exhausted at a particular point in time.

> ...
> Clearly re-prioritizing the incoming streams adds complexity, as does re-weighting the groups. But I believe that even in these cases dependencies become simpler to proxy than priorities because the relative ordering is explicit.

True, however prioritization only truly addresses optimization of page delivery.  In today's typical video + static content web site world, priorities by themselves could easily cause resource starvation - Osama's weighted group proposal addresses that quite nicely and partitions the priorities into those groups where the re-prioritization problem is a lot simpler (or at least a lot less likely IMHO...)

> Let's not make this every potential prioritization scheme, but rather focus on the common use cases and how they can be represented and implemented efficiently for the client/user agent, proxy, and server.  Exactly controlling the order of resource delivery is NOT a common requirement and can already be achieved through serialization by the client if it is really important.
> 
> 
> Now you could always argue that the above example is not a common use case or that the proxy could always fall back on ignoring priority. However I do believe that multiplexing incoming connections over a single outgoing connection is common and will become more so as HTTP/2 adoption increases. As for ignoring priority, if the scheme we come up with is difficult enough to proxy that proxies will end up ignoring it, then clients will fall back on using heuristics.

I agree on this point (which also applies to servers I think).

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair