Re: http/2 prioritization/fairness bug with proxies

On 4/02/2013 7:57 p.m., Poul-Henning Kamp wrote:
> Content-Type: text/plain; charset=ISO-8859-1
> --------
> In message <CAA4WUYjiBZpShKKFfHQnixc94aOLrck0oR4ykARB=hF5h8nkfA@mail.gmail.com>
> , =?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.

Amos

Received on Monday, 4 February 2013 08:35:56 UTC