[e2e] Multiple TCP-friendly Sessions and Cong. Control in user-mode?
touch at ISI.EDU
Wed Apr 10 09:52:48 PDT 2002
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.
More information about the end2end-interest