[e2e] Is the end to end paradigm appropriate for congestion control?
richard at bennett.com
Mon Nov 11 13:59:31 PST 2013
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
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
> 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
> 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
> (expecting flames...)
Visiting Fellow, American Enterprise Institute
Center for Internet, Communications, and Technology Policy
Editor, High Tech Forum
(408) 829-4944 (mobile)
(415) 967-2900 (office)
More information about the end2end-interest