[e2e] Number of persistent connections per HTTP server?

[Qiaobing Xie]

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.

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.

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.

-Qiaobing

> 
> joe