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

Christian Huitema huitema at windows.microsoft.com
Wed Apr 10 15:38:07 PDT 2002


> > 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?
> >
> 
> Some applications do their own CC because they, rightly or wrongly,
> perceive TCP as being too "heavyweight".  Some just don't need
reliable
> transfer but want to be responsible citizens.  This is all part of the
> justification for DCP. Indeed, a good argument for not putting CC in
> user space is that getting congestion control right is not easy and
> applications can get it wrong.

This is an often heard argument. It is also somewhat patronizing, and
very probably wrong. It would perhaps be useful to first check whether
the TCP congestion control, as we know it today, is in fact the right
solution. There are at least three arguments against it:

1) A lot of evidence points to a bandwidth glut in the middle of the
network. It is not at all clear that we have to be scared by "the
potential for non-congestion-controlled datagram flows to cause
congestion collapse of the network." We may want to consider efficient
sharing of bottlenecks such as narrowband "last mile" connections, but
that is a very different problem than congestion collapse.

2) There is also some evidence that the current assumption equating
packet losses with an indication of congestion is probably wrong. Packet
losses can be caused by events unrelated to network congestion, e.g.
noisy wireless links, routing events, and faulty hardware. 

3) The current TCP algorithm does not scale to high bandwidth. More
precisely, it requires that the packet loss rate drops as the square of
the desired bandwidth, which can be very hard to achieve in practice,
and is not in any case required to achieve stability.

I would argue that many of the RTP/UDP implementations use algorithm
that are both more sophisticated than TCP, and also better suited to
their task.

-- Christian Huitema




More information about the end2end-interest mailing list