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

[Joe Touch]

Shivkumar Kalyanaraman wrote:
> 2 questions:
> 
> 1. What is the current thinking about instantiating multiple TCP-friendly
> flows between the same pair of src-dest IP addresses? Is it
> good/bad/friendly-to-TCP ?

It should act just like multiple TCP connections between the same pair. 
It is per-connection friendly, but per-user or process unfriendly.

> The reason I ask is that we have found it to be useful for video
> streaming and other such apps (incl large file transfer) -- which can
> monitor the RTT/rate/volatility/loss-rate of each TCP-friendly flow and
> map traffic on a packet-by-packet basis to different flows. 

If these are TCP-like flows between the same endpoints, the above should 
be the same, over the long term.

If they're not the same, then the connections aren't really acting like 
multiple TCP-friendly flows.

> 2. As part of congestion manager or earlier attempts to manage
> non-TCP flows, have folks considered the impact of implementing congestion
> control schemes at the user-mode (and not kernel mode like TCP). If busy
> video servers implement congestion control above RTP, there would be
> significant OS process scheduling jitter which would add to the
> burstiness. We have observed severe burstiness effects in our experimental
> studies even with just about 50 odd threads (especially since we use a
> non-real-time OS like Linux).... Looks like another argument to go for the
> congestion manager approach.

It's an argument for implementing congestion control where the 
scheduling jitter is low. That can mean separating congestion control 
from the protocol (CM), OR using in-kernel implementations of 
coordinating protocols (RFC2140) OR using a real-time OS with less 
scheduling jitter at the user level.

Joe