[e2e] Multiple TCP-friendly Sessions and Cong. Control in user-mode?

[Shivkumar Kalyanaraman]

> > So, I read the community consensus is that we do not care about
> > per-user or process unfriendly provided we are per-connection
> > friendly (and/or we cannot do anything about it anyway)...
>
> I'm not sure I'd read that. The whole point of CM and 2140 is to do
> better than per-connection, or at least to allow applications to use
> multiple connections without incurring the behavior of multiple
> connections as a result.
>

Joe,

Does not this control of multiple connections as a single entity assume
that all these connections are mapped to the same path? With MPLS
increasingly deployed in ISPs and multi-homing by enterprises, would it
not be possible for flows between pairs of machines being mapped to
different paths in the near future (if not happening already)?


> > How far is the CM or other approaches gaining traction with end-system
> > designers?
>
> The incentive for being TCP friendly is competing with the incentive for
> individual application performance. It isn't clear that any alternate
> approach (to being greedy and using existing simple code to use multiple
> connections) will be widely-adopted until there is backpressure to do so.

I am not following your intent above -- could you clarify? I am not
suggesting that each flow be TCP-unfriendly. I am simply asking why should
an application not be allowed to open multiple sessions, and are any of
the alternative approaches you mentioned gaining any traction in the real
world.

At the internetwork, all we care about is stability and a base
notion of fairness (which is flow-level TCP friendliness). TFRC or a
some binomial schemes can give us this. Applications have different
utility for bandwidth -- small file transfers could do with one flow.
Large file transfers or streaming could use multiple flows.

Then applications should be free to choose how many TCP-friendly flows
they need to instantiate to do their job, and they could do some
innovative connection setup procedure to do that: eg: have a
multi-SYN/multi-ACK which sets up the initial connection information
reliably for N connections where N is a parameter of the multi-SYN... A
range of port numbers (and initial sequence numbers) at one of the sides
could be included in the multi-SYN... Or we could use in-band SYN/ACKs to
trigger setup of new connections given one (or an existing) reliable
connection.

best
-Shiv