[e2e] Number of persistent connections per HTTP server?

[Joe Touch]

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.

Joe