[e2e] Number of persistent connections per HTTP server?

Vadim Antonov avg at kotovnik.com
Mon Oct 14 16:27:38 PDT 2002

On Mon, 14 Oct 2002, Joe Touch wrote:

> See:
> D. Tennenhouse, "Layered Multiplexing Considered Harmful", Protocols for 
> High-Speed Networks, 1989.

David Tennehouse is very concerned with cross-talk, which is not the issue
with parallel TCP sessions, so the only reason why not to multiplex N TCP
sessions into one between the _same hosts_ is fairness, if desired
fairness is on per-flow basis (which is kind of arguable definition
anyway, since it creates an incentive for antisocial behaviour
(i.e. creation of multiple mice flows instead of a single larger flow)).
I'd say that per-host fairness is a much better idea.

Doing multiplexing within single TCP session effectively shares the timing
and congestion control information between flows, which is a good thing
(this can be achieved by storing that info on per-peer-host basis in the
TCP stack, instead of TCBs - however, this technique breaks down in case
of NATs which can make different boxes appear to be the same box, or in
case of per-flow load sharing in the network).

The issue of bandwidth fairness can be addressed pretty easily by adding
a "fairness factor" by which TCP stack should decrease reaction to packet
loss, and increase window size increment, so the dynamical parameters of a
single flow would be the same as those of N parallel flows.

Obviously, this would leave open an opportunity for abuse (heh, most
browsers do abuse network anyway by opening multiple parallel TCP

One big mistake in the TCP design is the lack of clear separation between
different functions: i.e. error correction, congestion control, port
multiplexing, flow control and stream packetizing. This makes a good
implementation of a multiplexing protocol over TCP rather difficult.


More information about the end2end-interest mailing list