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

[David P. Reed]

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

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
>designers?
>
>
>best
>-Shiv