[e2e] Number of persistent connections per HTTP server?
touch at ISI.EDU
Tue Oct 15 13:13:46 PDT 2002
Qiaobing Xie wrote:
> Joe Touch wrote:
>>>Hmmm, this seems to put the HTTP application into a hopeless situation -
>>>not to mux, you get the head-of-line blocking problem that is
>>>practically harmful towards the web users' experience; to mux, you get
>>>the theoretical "harmful layered mux problems" (towards the network
>>>bandwidth efficiency, I guess) :-)
>>You keep assuming two worlds:
>> 1 TCP connection without muxing on top -> HOL
>> 1 TCP connection with muxing on top -> layered muxing
>>As I said in the reply to your earlier message, please _read_ RFC2140.
>>You don't need to use a single TCP connection, and the use of multiple
>>connections can be done in a way that allows IP to mux properly without
>>creating inappropriate network load.
> That's would be nice. But I wonder in the real world (or should I say
> "today's real virtual world of WWW"), how many Web sessions are
> benefiting from RFC2140, and how many are actually doing app layer
> muxing of multiple objects over a limited number (2-4) of independent
> TCP connections. I don't know about the former, but I can guess that
> millions and millions of Web sessions are doing the later, i.e., "the
> harmful layered muxing", everyday.
The use of multiple connections doesn't require, or currently (to my
knowledge) use muxing. Multiple requests are pipelined, but not
multiplexed, at least in current widely-deployed implementations.
> Correct me if I got it wrong, but there seems to be a fundamental
> difference btw SCTP and RFC2140 - SCTP uses a single congestion control
> for all its streams (i.e., flows), while RFC2140 uses per-flow (i.e.,
> per-connection) congestion control. I am sure this has an impact to the
> current fairness debate, but I don't want to get into it because I don't
> know enough about it.
SCTP uses a single mechanism; 2140 describes how multiple connections
can share information to be _equivalent_ to a single mechanism. There
are other examples, e.g., the Congestion Manager (Sigcomm 1999).
> Btw, with or without RFC2140 and regardless of the fairness, the use of
> a large number of TCP connections to deliver an object-rich HTTP page
> may not give one the expected performance gain, the open and close of
> those short-lived TCP connections do come with a cost. But SCTP won't
> have this problem.
How much open and close cost depends on whether the establishment is
overlapped with other work, e.g., see T/TCP. SCTP avoids some of the
packet exchange, but the latency isn't necessarily different from, e.g.,
T/TCP or pre-opened TCP connections.
More information about the end2end-interest