Subject: Fwd: I-D Action:draft-nottingham-http-pipeline-01.txt

From: Mark Nottingham <[email-masked]>
Date: Mon, 14 Mar 2011 11:16:58 -0700

FYI.

Begin forwarded message:

> From: [email-masked]
> Date: 13 March 2011 11:45:01 PM PDT
> To: [email-masked]
> Subject: I-D Action:draft-nottingham-http-pipeline-01.txt
> Reply-To: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Making HTTP Pipelining Usable on the Open Web
> 	Author(s)       : M. Nottingham
> 	Filename        : draft-nottingham-http-pipeline-01.txt
> 	Pages           : 10
> 	Date            : 2011-03-13
> 
> Pipelining was added to HTTP/1.1 as a means of improving the
> performance of persistent connections in common cases.  While it is
> deployed in some limited circumstances, it is not widely used by
> clients on the open Internet.  This memo suggests some measures
> designed to make it more possible for clients to reliably and safely
> use HTTP pipelining in these situations.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nottingham-http-pipeline-01.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 14 Mar 2011 20:21:34 +0100

Hello Mark,

First, thanks for this update on your proposal. After having spent
some time thinking on the issue, and a bit of experience at a mobile
phone operator where transparent proxies are everywhere on the client
side, I really think that the current proposal will not make the
situation significantly improve, despite the initially good idea.

Please let me explain.

Pipelining issues are connection-specific : a client may decide to
pipeline or not to pipeline over a given connection. The client
does not know whether there are transparent proxies in the chain
(or "interception proxies", let's call them all "transparent" for
the sake of easier explanation).

When those transparent proxies are specific to the site the client
is visiting, it can make sense to rely on Assoc-Req, because after
all, it's the site's admin responsibility to ensure that their
servers will correctly build the header. In fact there's another
issue on this point, let's see later.

But when the transparent proxies are on the client side, the header
basically brings no information. In fact, either all sites work, or
all of them fail. If the transparent proxy is unable to cope with
pipelining, granted some sites will be blacklisted from time to time,
but it will still not be possible to blacklist all connections passing
through this reverse-proxy.

However, when the transparent proxy supports pipelining, it will not
be used for the vast majority of sites which do not make use of the
header, while it's unrelated to them. And for the few ones that will
emit the header reporting an issue between the transparent proxy and
the site itself, the client will refrain from pipelining while it's
unrelated to its side.

I see an easy solution to this : transparent proxies on the client
side will have to be modified to 1) remove any Assoc-Req header from
responses, and 2) forge it themselves to send a valid-looking response
to the client. However, this is contrary to what is specified in the
draft. Given the small time it takes to upgrade client-side proxies
at places such as ISPs, and given the noticeable benefits for every
internet site, I'm quite sure that every operator will do it whatever
is written in the spec.

Now for the server side, we're suggesting adding the header on the
servers themselves in order to validate the whole chain. I see two
difficulties with that :
  - large sites take more time to be modified, even in order to
    add just a header ;

  - it's more and more common on the server side to "route" requests
    via various layers of application proxies and servers, and URLs
    are rewritten, mapped, prefixed, or have their prefixes stripped.
    It's enough to see the damage done on the Location response header
    to understand what type of molestation they support on the request
    path. In these environments, the cost of adding an Assoc-Req header
    will be high compared to the perceived benefits (application authors
    test them on the local network anyway).

Thus it will be difficult (read expensive) to reliably add this header
on the server side for a little perceived benefit. Also, it will be
enough to get it wrong only once for the site to be blacklisted by
many clients anyway, rendering the efforts useless. Also, there will
be issues with duplicate headers, URLs containing commas being handled
differently by some clients when presented in the Assoc-Req header,
etc...

Another point I'm seeing is on the efficiency and deployment speed.
I don't know how many sites there are on the net, but getting all of
the valid ones emit the header will take ages. We can relate that to
the number of sites which support keep-alive and HTTP compression.
The main reason is that there is little incentive on the server side
to work on this, because the benefits are not directly perceived.

On the other hand, there are much less network operators than there
are web sites. When one operator gets the header right in his proxies,
those are millions of users which instantly get pipelining on the whole
internet.

A few months ago I would have said that pipelining was mostly useful
between the client side and the server side. Having seen the huge RTTs
that can be experienced by a mobile phone, I now know that the most
important location is there, between the mobile phone and the operator's.
And operators have a real incentive to reduce their customers' page load
time, it's a strong competitive argument. So whatever they can do, they
will do. And specifically, they're systematically setting up transparent
proxies in order to cut their customers' RTT and optimize their TCP
behaviour.

>From what I observe around me, internet access grows faster via mobile
phones than via DSL. I may be wrong but I'm pretty sure that some
statistics would back me.

That means that we can address most of the pipelining deployment issues
by targetting the client side and providing a real perceived benefit to
those who will deploy the feature, and it should concern more and more
internet users in very little time, because there are people willing to
push that mechanism forwards.

On the architecture point of view, I'd say that if we want clients to
make efficient use of pipelining, we should only bother them with the
connections they're manipulating, it should not be end-to-end, because
they don't care what's on the other side of the proxies and they can't
do anything about that.

At minima, the header should be announced in the Connection header and
be emitted by any intermediary. That could ensure that the intermediary
closest to the client has the final word and that the client reliably
knows what it can do. It would also help a lot with the URL rewriting
issues, because most components involved in rewriting URLs are reverse
proxies. They would delete the header on the server side and rewrite it
on the client side.

It still complies with your goal of spotting the baddest intermediaries,
because the ones not processing the Connection header will simply pass
the responses as they get them, and if they're the last element in the
response path before the client and they fail their pipelining, they
will be detected.

I really think that encouraging proxies (explicit and transparent) to add
the header themselves would really speed up adoption and have the expected
benefit you're looking for.

Also, one point I'm thinking about. I noticed a situation where pipelining
did not bring any advantage over the fact that some sites use a large number
of domain names for their hosts. The reason is that the first request to a
server is not pipelined, so if a client has to fetch 100 objects over 50
connections, it does only 2 non-pipelined requests over each (and I'm not
making up numbers, I've seen that).

Ideally we should find a solution so that a proxy (explicit or transparent)
can indicate to a client that it supports pipelining for whatever site the
client wants to access. That way the client will be able to make effective
use of its connections to pipeline all requests, starting from the first
ones. I think that doing so with an explicit proxy configuration is easy,
we could say that if a client is configured to use a proxy and it gets an
Assoc-Req response header, then it knows that all connections to the same
proxy can be pipelined. (For the transparent case, it's tougher because I
see no way to tell the client without risking to pass such an information
from a site's proxy to a proxy-less client).

Well, that was a long mail, but I'd really like that you take some time to
think about this approach. It remains compatible with your design without
some of its drawbacks and with faster adoption.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 14 Mar 2011 16:48:52 -0700

> Hello Mark,

Hi Willy.

[snip]

> issue on this point, let's see later.

Sorry, a transparent/intercepting proxy that's specific to a site? Are you talking about gateways ("reverse proxies") or are you saying that some networks are selectively deploying proxies that are only used for accessing certain sites?

I'm aware of a few content firewalls that work this way (e.g., in Australia, the much-ballyhoo'd Internet Filter would redirect requests to certain IPs to an intercepting proxy) -- are you thinking of this, or something else?

> basically brings no information.

The draft (clearly, I hope!) conveys a strategy for dealing with interception proxies; do you have any feedback on that? Assoc-Req is not intended to address all of the problems associated with them.

[snip]

> internet site, I'm quite sure that every operator will do it whatever

I see your point about mobile networks -- they may want to optimise the connection between the browser and proxy, since they're more latency-sensitive than most other intermediary administrators. However, it seems to me that this is a specific client->proxy optimisation, not a general one that replaces the other mechanisms in the draft. 

Let me have a think about it and perhaps we can come up with something that helps pipelining to next-hop proxies without disturbing other use cases.

>  - large sites take more time to be modified, even in order to

Do you have any data to back this up? In my experience, this is not trivial, but it is workable, especially when you dangle a substantial performance improvement as a carrot.

>    test them on the local network anyway).

I'll treat this as a response to the note requesting feedback on the design of the Assoc-Req value in -01.

> differently by some clients when presented in the Assoc-Req header,

Indeed, why try at all? I'm sure you'll be able to find problems of this nature with most any proposal someone makes.

> the number of sites which support keep-alive and HTTP compression.

Yet, strangely, many sites do deploy keep-alive and compression, and enjoy the benefits.

> to work on this, because the benefits are not directly perceived.

?!?! I know of many server admins who salivate at the potential performance benefits that this brings. It's a huge incentive. 

[snip]

> push that mechanism forwards.

Yes, this is why I've been working with browser vendors, and as you may know, my employer has no small concern in assuring that its considerable array of content is delivered quickly.

> they don't care what's on the other side of the proxies and they can't

Pipelining can certainly be hop-by-hop, but head-of-line blocking is most often caused by the origin server. Therefore it's important to give it some control over the use of pipelining. 

> proxies. They would delete the header on the server side and rewrite it

This would require that intermediaries be rewritten and redeployed. I think your analysis WRT incentives is flawed; IME the majority of proxy administrators don't care about fine-tuning latency, they care about controlling access and/or reducing bandwidth use. 

[snip]

> some of its drawbacks and with faster adoption.

Thanks for the feedback, Willy.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 15 Mar 2011 11:43:12 +0100

Hi Mark,

> Sorry, a transparent/intercepting proxy that's specific to a site? Are you talking about gateways ("reverse proxies") or are you saying that some networks are selectively deploying proxies that are…

I'm mostly thinking about load balancers, that are invisible to the client,
but HTTP optimizers (compressors, content aggregators) are also included.

> The draft (clearly, I hope!) conveys a strategy for dealing with interception proxies; do you have any feedback on that? Assoc-Req is not intended to address all of the problems associated with the…

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.

> I see your point about mobile networks -- they may want to optimise the connection between the browser and proxy, since they're more latency-sensitive than most other intermediary administrators. H…

I agree that it's specific to client->proxy, and because it deals with
latency, it's one place where pipelining is expected to show the most
important improvements if it can be generalized.

> Let me have a think about it and perhaps we can come up with something that helps pipelining to next-hop proxies without disturbing other use cases.

That would be the general idea. I don't intend to shake every thinking
that has led to this draft, but rather to fuel the discussion with new
elements. As you may remember, we've discussed about it in the past,
and letting it cool for a few months and taking into account what is
encountered in field helps figuring some new important points.

> Do you have any data to back this up? In my experience, this is not trivial, but it is workable, especially when you dangle a substantial performance improvement as a carrot.

All the "large" sites I know are behind several layers of reverse-proxies
which are shared between multiple applications. I would even say application
components, because nowadays, no application administrator can define where
"the" application is, rather what server components it's made of. Most of
these components forward the requests they're not responsible for to a next
hop, a bit like portals. In these environments, dealing with URLs is generally
difficult because they're rewritten at many places, sometimes stripping the
first directory part at each level. For this reason we see hard-coded links
in pages and hard-coded Location headers for redirects, because noone is
able to build a correct one. I've header an architect once tell me that the
application was "relocalisable" in that it never knows its URLs, it's at the
end of a long chain and processes what it receives...

In practice, they often rely on the hosting infrastructure to serve error
pages because it's easier for them. In such environments, the amount of
efforts needed to get Assoc-Req right on every response is considerable,
and must be done for all hosted applications. On the opposite, doing it
on the first level of reverse proxy offers it a lot cheaper to all
applications.

> Yet, strangely, many sites do deploy keep-alive and compression, and enjoy the benefits.

My observations on prod traffic at a few places tends to indicate that
many sites still using Apache 1.3 as a reverse proxy have to disable
keep-alive due to the pre-forked model. Also, while many sites do indeed
deploy compression, they still represent a very low percentage of what
can be found in large proxies' logs. I'm not dismissing the merits of
these two mechanisms, I just want to give an example of some improvements
that are not always deployed by some sites because they don't find an
immediate advantage for them while some clients would benefit from them
(eg: mobile users).

> ?!?! I know of many server admins who salivate at the potential performance benefits that this brings. It's a huge incentive. 

On large sites it can lead to a dramatic reduction of the number of concurrent
connections, which is a good thing. But on small sites, this advantage is not
necessarily perceived.

> Yes, this is why I've been working with browser vendors, and as you may know, my employer has no small concern in assuring that its considerable array of content is delivered quickly.

But you agree that content providers as large as your employer are not that
many. If we want browsers to adopt pipelining by default, we should ensure
that many sites contribute to that effort, not just the 10 biggest ones.

> Pipelining can certainly be hop-by-hop, but head-of-line blocking is most often caused by the origin server. Therefore it's important to give it some control over the use of pipelining. 

I'm not sure what you mean here. Right now I know no intercepting proxy
which is able to forward pipelined requests. They accept pipelined requests,
but process one at a time. So the first proxy always terminates pipelining.

I've also encountered a heavily modified version of a well-known proxy
(sorry, my work is done under NDA, I can't disclose more) which supports
connection aggregation and optional pipelining when sending multiple
aggregated requests to a same server. So here again, pipeline client
requests may be split then possibly re-aggregated over existing
connections, and possibly pipelined with other concurrent requests. This
is an example of when pipelining between the proxy and the server might
happen regardless of the client's decision to pipeline or not. Where I've
seen this, the option was not enabled due to the usual issues with pipelining
on the net.

> This would require that intermediaries be rewritten and redeployed. I think your analysis WRT incentives is flawed; IME the majority of proxy administrators don't care about fine-tuning latency, th…

I see your point. Gateways generally don't touch the headers specified in
Connection, so they should not have to be touched. Client side proxies are
generally very flexible and making them add a header is more a matter of
configuration than upgrade.

However I agree with you that for most client sites, there is little
incentive to make efforts to enable pipelining.

So based on this, I think we could summarize some points :
  - some server sites will have little incentive in adding the Assoc-Req
    headers in their servers when those servers have complex URL handling,
    and they don't always see an immediate benefit ;

  - some client sites will have little incentive in doing the job in their
    proxies (or upgrading them) in order to present this header to their
    clients for the very same reasons ;

  - some server sites will want to make most clients reliably enable
    pipelining in order to push the data as fast as possible outside ;

  - some client sites will want to make most of their clients reliably enable
    pipelining for any destination in order to reduce the effect of huge RTTs
    and large numbers of connections.

So maybe we could achieve something which is less aggressive than adding a
Connection header. Basically we could suggest how an intermediary should
proceed with the header if it wants to offer pipelining to all of its clients
(remove any Assoc-Req response header it receives from the server, and add one
by itself).

That would work both on server-side with reverse proxies and is just a matter
of configuration. That would also work on client side with proxies.

Also I'm thinking that we might want to improve on that by allowing explicit
proxies to set an "Assoc-Req: *" to indicate to their clients that they can
pipeline any request that is sent to them, regardless of the destination. Of
course, for this one the Connection header will have to be set, because we
only want that header to be delivered to the client when it's the next hop!
But allowing explicit proxies do to that would be of tremendous help and
would allow many clients that use their ISP's proxy to benefit from pipelining
for the entier internet. I'm even realizing that we don't need the "Assoc-Req:*"
in this case, sending "Connection: Assoc-Req" is enough to indicate to the
browser that it's supported and to get rid of any possible response at the
same time.

Best regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Mar 2011 14:12:06 +1100

> but HTTP optimizers (compressors, content aggregators) are also included.

Right. These aren't transparent or intercepting proxies, because they're deployed by the server. Presumably, when a site was testing to see how they support pipelining, they'd include testing these. 

> the header is forbidden for proxies.

See:
  http://tools.ietf.org/html/draft-nottingham-http-pipeline-01#section-5

> end of a long chain and processes what it receives...

Yes, I'm familiar with these as well.

> on the first level of reverse proxy offers it a lot cheaper to all

Yes, that's what I'd assume they'd do (insert assoc-req on the FE and perform due diligence to make sure it isn't messed up in the background). Assoc-req could also be used in those 'back end' hops, of course (with its payload changing each time the URL changed). 

I suspect this would also help improve security; IME different products act inconsistently when they rewrite the Host header.

> immediate advantage for them while some clients would benefit from them

Sure. That doesn't mean that we should hold performance for the rest of the Web back.

> connections, which is a good thing. But on small sites, this advantage is not

I'd love it on my personal site. *shrug*

> that many sites contribute to that effort, not just the 10 biggest ones.

Of course. It would be helpful if you could try to characterise what makes the proposal more suited to large sites than small ones; I can't see anything that precludes them or biases away (assuming that browser and server vendors incorporate appropriate changes where necessary).

> but process one at a time. So the first proxy always terminates pipelining.

According to my testing, some proxies do handle pipelining, to various degrees, so "always" seems a bit overstated here.

> seen this, the option was not enabled due to the usual issues with pipelining

Sure...

>    and they don't always see an immediate benefit ;

I think that's a manageable problem, depending on some changes to the reverse proxy software. I believe that this will come soon after browsers support something, as there will be a strong incentive to do so. See also the request for feedback in the definition of assoc-req in -01, which may mitigate some concerns here.

>    clients for the very same reasons ;

I'd broaden that to say there's little incentive for them to do anything, in many (not all) cases. In the long term, we can improve this by working with the Squid team, the Traffic Server team, commercial products, etc., but we can't assume that currently-deployed products will be upgraded quickly.

>    pipelining in order to push the data as fast as possible outside ;

Yes.

>    and large numbers of connections.

Yes -- and this isn't addressed by the draft yet.

> (remove any Assoc-Req response header it receives from the server, and add one

Assoc-Req is all about making the client more comfortable that the response it's seeing is actually associated with the request it thinks it is. Removing it would be counter-productive; it's not an indicator that pipelining is desirable, etc. 

Having intermediaries add a header indicating that they want pipelining is one way to go about it, but I'm very aware that in the past, people have argued against a "I support pipelining" flag because a) HTTP/1.1 support is already this flag, and b) just as it is now, the first implementation that gets pipelining wrong will make that flag meaningless. 

Hmm. Perhaps a *new* hop-by-hop header that allows the client to associate a request with a response would be useful here; the client could generate the identifier, and since it's hop-by-hop, it wouldn't interfere with caching.

E.g.,

GET http://www.foo.com/ HTTP/1.1
Host: www.foo.com
Hop-ID: a
Connection: Hop-ID

HTTP/1.1 200 OK
Hop-ID: a
Connection: Hop-ID

The problem here is that clients don't have a strong incentive to send this header, unless they're sure that it's going to be useful. They could do so when they're configured to use a proxy, but AIUI the cases you're talking about involve intercepting proxies, so they couldn't be sure. 

> pipeline any request that is sent to them, regardless of the destination.

See above.

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 22 Mar 2011 07:27:57 +0100

Hi Mark,

On Tue, Mar 22, 2011 at 02:12:06PM +1100, Mark Nottingham wrote:
(...)

> I suspect this would also help improve security; IME different products act inconsistently when they rewrite the Host header.

Yes I've also been used to observe that (especially requests with multiple
or invalid Host headers).

> Sure. That doesn't mean that we should hold performance for the rest of the Web back.

No, indeed my comments are about trying to ensure that we deploy pipelining
more aggressively than what I expect the draft will currently permit ;-)

> I'd love it on my personal site. *shrug*

Because you precisely know what it saves. I've been fighting with some
people at a mobile operator to try to show them that pipelining will
definitely save both page load time and bandwidth (compared to using
many hosts to serve pages). After many tests, they concluded that there
was no gain at all and it was not worth trying to explain their users
how to enabled it in their browser!

I *know* it can save a lot, but only if properly used. The only reason
it did not save much there was because the first request on every new
connection was never pipelined until the client saw HTTP/1.1 in the
response. And since sites nowadays are composed of hundreds of objects
fetched from tens of hosts, it's hard to heavily benefit from pipelining
there, they prefer to open many parallel connections. Needless to say I
was a bit frustrated, because I had not expected that at all :-/

> Of course. It would be helpful if you could try to characterise what makes the proposal more suited to large sites than small ones; I can't see anything that precludes them or biases away (assuming…

The points where I think pipelining helps when properly used :
  - it reduces page load time
  - it reduces concurrent connection counts
  - it saves bandwidth by limiting the number of segments and ACKs

First point is important to sites which take care of always serving pages
very fast. Many sites I know are happy when their dynamic requests respond
in less than 1 second... So saving a few RTTs there is not much of their
concern (as I said, many are still running without keep-alive due to limits
imposed by the components). However, big ones are very careful about the
client's experience.

The second point only impacts those who have to deploy a number of front
servers which directly depends on the number of connections. If you find
you're happy with an Apache and its 256 connection limit by default, you
won't see what reducing the connection count will bring you. But if you
can half the number of front servers just because of this, it's a lot
different. Once again, only "large" sites are concerned with this point.
I'd say any site which has to run a handful of front servers.

The last point will only concern sites which pay bandwidth usage. Many
sites nowadays run on various link sizes where the cost doesn't change
whether they use the link or not. The issue comes when they have to
bump the link to a new offering. Right now, a large number of sites
need less than 100 Mbps to run and scale for years to come, and those
100 Mbps are among the cheapest offerings that can be found around. So
if a site is running at 50 Mbps and discovers that pipielining can save
5% bandwidth, they won't care. On the opposite, a site that peaks at
10Gig will always be interested to save 5%, because that's sometimes
what can make their usage percentile lower, and save a bit on their
operator's expense.

Also, all those points' benefits will always take some time to achieve,
because a lot of validation is necessary, sometimes even development.
Large sites can invest a lot of time to save a few percent. I know some
who even spend a lot of time trying to modify TCP stacks to save some
packets. Smaller sites don't want to pay to save a few percent.

> According to my testing, some proxies do handle pipelining, to various degrees, so "always" seems a bit overstated here.

You've found proxies which do pipelining with the servers ? Nice. If
you can send me a few pointers (even off-list if you prefer), I'm
interested in giving a look at them just out of curiosity. In my
opinion, if we find such proxies that also support aggregating client
connections to the same server, then we have to add provisions for that
in the draft, otherwise they'll be able to break regardless of the client
checks : even if the client detects a faulty intermediary and decides not
to pipeline anymore, it will not prevent the proxy from continuing to do
so.

(...)
> I think that's a manageable problem, depending on some changes to the reverse proxy software. I believe that this will come soon after browsers support something, as there will be a strong incentiv…

I agree on this point. As I explained above, one of the showstoppers is
"why bother with it, browsers won't use it anyway unless we explain to
customers how to enable it by hand on a small bunch of them".

> I'd broaden that to say there's little incentive for them to do anything, in many (not all) cases. In the long term, we can improve this by working with the Squid team, the Traffic Server team, com…

That's always been my assumption too.

> Assoc-Req is all about making the client more comfortable that the response it's seeing is actually associated with the request it thinks it is. Removing it would be counter-productive; it's not an…

When I mean "remove it", it's in order to replace it to avoid duplicates etc...
That would go that way, with a controlled client-side intercepting proxy :

Client           int.proxy                  whatever                server
   GET /foo                GET /foo                GET /app1/foo
   --------------->      ------------------->     -------------------->

   Assoc-Req: /foo        nothing or whatever      nothing or Assoc-Req: /app1/foo
   <---------------      <-------------------     <--------------------

If this proxy does not make use of pipelining to talk to the origin server,
it does not care about the lack of Assoc-Req in the response, nor about
possibly faulty Assoc-Req values due to improper handling on the server
side. However what it cares about is the fact that it informs the client
what request the response is related to. So it can reliably remove any
occurrence of the response header and insert its own. That way the client
still validates that its pipelined requests are correctly processed.

> Having intermediaries add a header indicating that they want pipelining is one way to go about it, but I'm very aware that in the past, people have argued against a "I support pipelining" flag beca…

I agree, but here we're not saying "I support pipelining", we're giving
a piece of information to the browser so that it can decide whether we
correctly support pipelining or not, which is the principle of the Assoc-Req
header : don't trust what the server is saying, check it. Here for the
client, the server is the intercepting proxy, so that works exactly as
it should have done on the origin server.

When the proxy is an explicit one, it should be the same principle. Also,
a proxy (intercepting or explicit) which supports pipelining with the
server must obviously check the assoc-req response header to know if it
can still pipeline there.

> The problem here is that clients don't have a strong incentive to send this header, unless they're sure that it's going to be useful. They could do so when they're configured to use a proxy, but AI…

We've talked about that in the past, and to be fair, I think it would
be the most flexible solution because it could be deployed by steps
and progressively be used everywhere (just as keep-alive was deployed).
Also I think it is compatible with gateways that don't remove the headers
listed in Connection, because that leaves the ability for the browser to
check if the communication to the next visible hop is OK. But IIRC you
said that browser vendors really want to limit the amount of uploaded
bytes and that they'd avoid to send a header that has limited use.

Can't we simply put a value in the Connection header BTW ?
Eg: Connection: r=12 ?

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 22 Mar 2011 08:21:43 +0000

>Can't we simply put a value in the Connection header BTW ?

That would be my preference as well.  Putting it in a separate header
adds extra text-processing but no value.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Brian Pane <[email-masked]>
Date: Fri, 25 Mar 2011 20:13:46 +0000

> the header is forbidden for proxies.

Speaking of which, what's the rationale for prohibiting proxies from adding the Assoc-Req header?

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

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.

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.

The "quick" link relation type might lead to a problem in practice; how would one apply it to the <link> tag?
I don't think
    <link rel="quick" rel="stylesheet" type="text/css" href="http://static.example.org/style.css">
is valid; and even if it is, it's unclear whether client implementations would still recognize it as a stylesheet link.

Finally, I think there's value in enabling some sort of wildcard hint mechanism, perhaps in the form of a simple prefix match.  For example, given:
    Link: <http://www.example.org/i/>; REL=quick
the client could expect http://www.example.org/i/logo.png to be quick, but not http://www.example.org/login.html

-Brian

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 27 Mar 2011 08:40:28 +0200

> 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 pipel…

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.

> - 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 de…

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