Re: http/2 prioritization/fairness bug with proxies

[William Chan (陈智昌) <[e-mail]>]

On Mon, Feb 4, 2013 at 5: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.

Sorry, I wasn't clear. I meant within the protocol itself. You're
absolutely correct that there are methods of identifying particular
clients. That said, as Mark notes, one of the original use cases
motivating this discussion is the tabbed browser case. I like to think
of a browser network stack as a proxy, servicing network requests for
the various tabs. While other methods do exist to handle identifying
particular tabs, they aren't particularly good ones.

But let's return to the premise. Do you believe it's better to rely on
these client fingerprinting methods to implement prioritization,
rather than providing more explicit signals in the protocol itself?

>>
>>> 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'm sorry I didn't address this in the first email. I confess I
thought it was obvious. Grouping lets you do relative prioritization
within a group, as opposed to across the entire session.

>>
>> 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.

AFAICT, delaying I/O is a suboptimal solution. Since client-side
advisory priorities informs the server of the response ordering, a
proxy which passes through the same priorities will allow higher
priority stream responses to starve lower priority ones. In your
proposed solution of delaying I/O, the proxy would need to withhold
WINDOW_UPDATE frames for streams that it wants to deprioritize, in
order to prevent the server from sending the response data for the
higher priority streams. In effect, this uses the stream receive
window mechanism to implement prioritization. I think that having the
receiver implement prioritization via receive windowing is worse than
having the client inform the server of advisory priorities and letting
the sender (the server) order as appropriate.

>
> Amos
>