[e2e] Multiple TCP-friendly Sessions and Cong. Control in
David P. Reed
dpreed at reed.com
Thu Apr 11 06:52:18 PDT 2002
I am doing a very interesting app that does congestion control (*must* do
congestion control) in the app layer. Why? Since its communication
patterns consist of short bursts originated in random locations "broadcast"
to time-varying subsets of up to a million other users, the only sensible
way to do congestion control is to control app behavior by signalling
congestion information (such as ECN marks) to all known sources that might
end up using the same congested path - letting them discover congestion
only when they begin transmitting would be far too late to close the
DCF is useless for the logic of this app. The communication patterns come
from the natural behavior of human users - not because of some perverse
design. And it is the type of app that could cause serious congestion.
Of course, the Internet that is being optimized by the "let's put all the
intelligence in the routers or OS kernels" school will not support our
application at all well. :-)
But we built the Internet by layering it on top of obsolete networks (built
by people with bell-shaped heads, who never met a network that didn't have
blocking probabilities and poisson arrival times). And we'll build the
next revolution by layering it on top of a thoroughly obsolete Internet, if
its implementation gets captured by the people who think that applications
must be forced to live on top of virtual circuits that simulate phone calls
and kernel OS's that are being asked to police bad behavior based on the
intuition of designers.
At 01:32 PM 4/10/2002 -0400, 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)...
> > It should act just like multiple TCP connections between the same pair.
> > It is per-connection friendly, but per-user or process unfriendly.
> > 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.
>Sounds consistent. But, is this argument well recognized in the brave new
>world where applications run over UDP/RTP and do their own CC? Are
>application developers implementing congestion control at the app layer ?
>How far is the CM or other approaches gaining traction with end-system
More information about the end2end-interest