Re: Is the end to end paradigm appropriate for congestion control?

It's interesting that so many people still talk about CSMA/CD as if it 
were still real. IEEE 802.3i added a full duplex mode to Ethernet (known 
as 10BASE-T) in 1990, and 802.3u (100 BASE-TX) effectively eliminated 
the half duplex, CSMA/CD mode for speeds of 100 Mbps and higher on 
Ethernet.  The full duplex modes of Ethernet have a flow control signal 
that moderates congestion, and on-switch buffers for storage of frames 
(either full or partial) in-flight. Nowdays, you only see CSMA on 
unlicensed broadcast networks, e. g. Wi-Fi.

You can't effectively manage congestion solely with the knowledge end 
points have, but any congestion management scheme needs end point 
cooperation since end points are the sources of congestion. The 
Internet's congestion problem is insufficient signalling from the 
elements that can immediately detect congestion - the switches - back to 
the elements that create it. There have been and are efforts to improve 
the signalling - ECN and PCN - and there was a botched attempt to deal 
with it in the original versions of IP with source quench. The longevity 
of the Jacobson CC and efforts to extend its life like AQM are quite 
unfortunate.

The problem with end-to-end is the lack of overall system knowledge in 
any given end point.

On 11/11/2013 4:23 AM, Detlef Bosau wrote:
> I know this question is as heterodox as could be.
>
> Nevertheless. A TCP packet on its way from source to sink will typically
> travel quite some packet switching nodes, each of which
> introduces a potential flow control problem. A switching node typically
> does "store and forward" - and whenever a queue on the node cannot be
> drained sufficiently fast - be it due to a throughput shortage on the
> outgoing link, be it due to a large amount of incoming traffic - the
> switching node has to throttle down incoming traffic or it must discard
> packets.
>
> Both scenarios are possible with TCP: An unexpected throughput shortage
> may occur on wireless networks, unexpected traffic may be caused
> by any competing sender.
>
> I'm - after years - still not comfortable with the concept of "storage
> on the line", which is basically the motivation for our sliding window
> model.
> A line (fibre, copper, air interface) may or may not offer a certain
> amount of transient storage capacity, depending on quite some factors,
> one of which is the MAC scheme. E.g. in CSMA/CD nets, there is no more
> then ONE packet on the line. Hence, the concept of a
> "Latency-Throughput-Product" must be used with extreme caution.
>
> I'm sometimes not quite sure whether particularly VJCC actually works
> around a "concatenated flow control problem", which in the late 80s
> really WAS a concatenated flow control problem because the vast majority
> of a paths "capacity" was located on the switches - and not on the lines.
> (At least to my understanding.) And because we did not want to touch the
> switches, in other words we wanted to keep thins small and simple, we
> worked around this flow control problem using an end to end congestion
> control.
>
> Detlef
>
> (expecting flames...)
>

-- 
Richard Bennett
Visiting Fellow, American Enterprise Institute
Center for Internet, Communications, and Technology Policy
Editor, High Tech Forum
(408) 829-4944 (mobile)
(415) 967-2900 (office)