W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

Re: Suggestion for NEW Issue: Pipelining problems

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 24 Jul 2007 15:59:36 +0200
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1185285576.25507.24.camel@henriknordstrom.net>
On mån, 2007-07-23 at 16:57 -0700, Roy T. Fielding wrote:

> If the connections are used infrequently and are susceptible to
> timeouts occurring while the next request is in transit, then the
> data sent across the network far exceeds any average
> *congestion-control* benefit obtained by avoiding the separate
> connections.

Indeed. And also causes a fair bit of other headaches.

There is also the related case of a server forgetting to do a graceful
close when it needs to close the connection after a response, and this
causing even already sent responses in the TCP pipe to get flushed.

>  A new connection will be required anyway and the
> request message is sent twice (though whether that message hit
> the network or not seems to depend on the TCP implementation).

And timing details..

> That should be testable to find the actual trade-off point where
> a client should close the connection, but I have no experimental
> evidence and no time to set up an experiment.

It's very dependent on the connection timeout used by the server, and
there is no standard or even recommendations on what timeouts to use.

It's one of those shortcomings of TCP, missing an advisory close
operation allowing either endpoint to gracefully ask if it's ok to close
the connection.

> In any case,
> pipelining is still worthwhile for many reasons, particularly
> when we have control over both sides of the connection, so we need
> it defined in HTTP regardless of any single client's request profile.


> BTW, do you know of any good (experiment-quality) evaluations
> of HTTP over SCTP?

Saw some when I looked into this. But unfortunately I don't have
references..  The conclusions from what I can remember was that it
currently performs rather poorly in comparision to pipelined HTTP over
TCP, part due to the inability to batch fragments from different
messages in the same IP packet to utilize the MTU fully, part from SCTP
implementations not performing as well as they could. But also that SCTP
is fairly young and implementations likely to improve over time likely
making it perform noticeably better.

I don't think there is any question that HTTP over SCTP has a great
potential in reducing the average perceived latency of viewing complex


Received on Tuesday, 24 July 2007 14:00:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:31 UTC