Re: http/2 prioritization/fairness bug with proxies

[Mark Nottingham <[e-mail]>]

On 04/02/2013, at 7:35 PM, Amos Jeffries <[e-mail]> wrote:

> On 4/02/2013 7:57 p.m., Poul-Henning Kamp wrote:
>> Content-Type: text/plain; charset=ISO-8859-1
>> --------
>> In message <CAA4WUYjiBZpShKKFfHQnixc94aOLrck0oR4ykARB=[e-mail]>
>> , =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= writes:
>> 
>>> Anyway, the existing prioritization bug is as follows:
>> [...]
>> 
>>> The backend server
>>> obviously can't do this because it doesn't (at least, shouldn't!) know
>>> the clients behind the proxy.
>> This flies counter to vast experience:  Servers do almost everything
>> they can to identify the actual client (X-F-F, cookies, fingerprinting
>> etc), so I think this premise needs to be rethought.
>> 
>>> I consider all those options as suboptimal, and thus consider this
>>> issue to be a protocol bug. Our SPDY/4 prioritization proposal
>>> addresses this by using stream groups with advisory (all this is
>>> advisory after all) [...]
>> So what does the groups buy you, for all the complexity they add ?
>> 
>> As far as I can tell:  Nothing.
>> 
>> I think the priority should simply be documented as advisory and
>> mention that intermediaries SHOULD respect them, subject to
>> local administrative policy, and leave it at that.
>> 
>> The current proposal is complex enough as it is, adding complexity
>> to not solve problems that cannot be solved technically, is not
>> an improvement.
> 
> +1. There are a lot of queuing, scheduling, and load balancing algorithms out there for the proxy to choose from and likely to be more or better ones found going forward.
> The proxy is already in a position to group (or not), or to simply delay I/O as necessary to make things fair for all clients according to their priority hints. A SHOULD is enough.

So, let's say I'm a proxy, and I currently have two clients, A and B.

Client A sends a stream of requests with the following priorities:

1 1 1 3 3 3 2 2 

and client B sends:

3 3 2 2 4 4

Let's say (for now) that they all go on the same forward connection.

With the current mechanism, you have to rewrite the priorities to balance their connections. So, you might change B's request stream priorities to:

2 2 1 1 3 3

But what should I do when, a few milliseconds later, B emits a request with priority "1"? I don't have a "0" priority. 

I suppose I could de-prioritise client A's requests, but that would just move the problem to the other end of the scale (least priority).

I imagine that a clever implementer would find a way to re-balance the priority space so that these effects were mitigated. However, not all implementers are clever, and even the clever implementers will do it in different ways, leading to variations in behaviour.

To me, grouping seems like a very easy way around this; you can maintain the relative priority of requests from a single context without rewriting them, and level out the weightings of groups if you're a proxy. 

BTW, I think there's a similar motivation in the original use case that motivated Will; he needs to be able to balance the priorities among a set of browser tabs, when it's possible for new requests to be generated by those tabs at any time.

Cheers,


--
Mark Nottingham   http://www.mnot.net/