- From: ??? <willchan@chromium.org>
- Date: Tue, 5 Feb 2013 01:42:14 +0900
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Feb 4, 2013 at 5:35 PM, Amos Jeffries <squid3@treenet.co.nz> wrote: > 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. 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 >
Received on Monday, 4 February 2013 16:42:42 UTC