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

[Joe Touch]

Shivkumar Kalyanaraman wrote:
>>>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? 

Yes. Or that they overlap where they each congest.

> 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)?

It is not a property of MPLS, but of the use of multipath routing. If 
two connections are routed differently, then yes, this wouldn't work.

However, there is some excellent recent work at CMU by Aditya Akella 
showing that it's better to assume sharing, detect that the paths should 
be decoupled, and decouple them than to assume the paths are decoupled 
to start. I.e.,
'tis better to have shared and decoupled than never to have shared at 
all' :-)
http://www.cs.cmu.edu/~srini/Papers/presentations/2001.10.PDL/falsesharing_akella8x11.pdf

(at least that's my phrasing of it :-)

>>>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.

Basically because opening multiple connections is more aggressive, and 
gets better performance as a result. There is no current disincentive to 
doing so. (that's what I meant above)

> At the internetwork, all we care about is stability and a base
> notion of fairness (which is flow-level TCP friendliness). 

Users care about performance as well as friendliness. Right now 
performance pays; unfriendliness gets the TCP-crowd on your back, but 
doesn't necessarily cause consumers to choose correctly.

Joe