Re: About draft-nottingham-http-pipeline-01.txt

On Fri, Mar 25, 2011 at 08:13:46PM +0000, Brian Pane wrote:
> Willy Tarreau wrote:
> > It's not clear to me when reading it. Maybe I missed an important point,
> > but the only relevant item I've found was about the fact that adding
> > the header is forbidden for proxies.
> 
> Speaking of which, what's the rationale for prohibiting proxies from adding the Assoc-Req header?

Mark said he found proxies that were able to propagate pipeline between both
sides. In this environment, that makes sense.

> There's a use case where it seems reasonable to allow proxies to add the header: a reverse proxy in front of the web server (e.g., a load balancer or cache) might be quite capable of handling pipelined requests, but it might have to serialize requests to the origin server if the latter isn't known to support pipelining properly.  This arguably is a very useful setup, as it enables pipelining between the client and the reverse proxy (usually the high-RTT part of the trip), just not between the reverse proxy and the origin server (usually the low-RTT part of the trip).

I agree, that's the point I'm concerned with. In my opinion, we should allow
proxies and reverse-proxies to set the header in these two cases :

  - they're not sending pipeline requests, which means that whatever is
    returned by the origin server is irrelevant to the client's choice of
    pipelining or not ;

  - they do pipeline but they have a way to control that the next hop
    has properly handled it (either by configuration, or by checking
    existing Assoc-Req themselves, or by any other means)

This would make it possible for reverse proxies to generate the header for
server farms which are unable to correctly do it. It would make it possible
for proxies who know they don't pipeline to offer global pipelining to their
clients.

> Some additional thoughts on http://tools.ietf.org/html/draft-nottingham-http-pipeline-01 (from my perspective as somebody who's developed web servers and reverse proxies; I'd love to hear some input from the browser implementers too) ...
> 
> The use of the HTTP Link header for pipeline hinting is a double-edged sword.  The response header is often the easiest and least expensive place to add something to an existing web application.  The one downside I see is that response headers on a lot of websites are getting close to 1 MTU in size already, so adding Link headers on every response is not necessarily ideal.  Sending the Link headers on the first response per session (or, for the sake of efficient implementability, the first response per connection) might be a good balance, however.
> 
> The "/.well-known/pipeline" URI is straightforward to implement, but my concern is that it doesn't provide an answer fast enough in the following scenario:
> 
> - Dynamic content is served from www.example.com.
> - Static content is served from a CDN, let's call it static.example.org.
> - A client requests a page from www.example.com and receives an HTML document containing lots of links to static.example.org.
> - The client then has to request static.example.org/.well-known/pipeline/ before it can tell whether static.example.com supports pipelining on all its resources.

Good point, and from recent analysis I performed on several sites,
I found that each average page was composed of a bunch of different
hosts. Oh, BTW, this doc reports 7 to 8 hosts per page on average :

   http://code.google.com/speed/articles/web-metrics.html

> In contrast, if the Link header in the www.example.com response indicates that static.example.org supports pipelined requests for all its resources, the client doesn't need to incur a round-trip delay to static.example.org to query /.well-known/pipeline/ before it can begin pipelining its requests.

While that would help for hosts under the same responsibility, that
would not change anything for the ones added on the page by advertisers
or other partners. Still it might indeed help.

Regards,
Willy

Received on Sunday, 27 March 2011 06:41:02 UTC