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

[Cannara]

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.

Alex

Christian Huitema wrote:
> 
> > > 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