[e2e] Multiple TCP-friendly Sessions and Cong. Control inuser-mode?
cannara at attglobal.net
Wed Apr 10 20:33:28 PDT 2002
Agree with Christian here. Having been involved, for some time, with
one of the chip vendors who supplies the major gear makers who build
everything from core to last-mile and end systems, it's clear that far
more capacity exists within the overall net than is being used. And, on
the periphery, where systems now have access to single-chip devices that
manage hundreds of thousands of flows in multi-Gb/s aggregates, it's clear
that the original need for transport-layer flow control for the network
layer's benefit is an anachronism.
Christian Huitema wrote:
> > > Sounds consistent. But, is this argument well recognized in the
> > new
> > > world where applications run over UDP/RTP and do their own CC? Are
> > > application developers implementing congestion control at the app
> > ?
> > > How far is the CM or other approaches gaining traction with
> > > designers?
> > >
> > Some applications do their own CC because they, rightly or wrongly,
> > perceive TCP as being too "heavyweight". Some just don't need
> > 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