[e2e] Two sides of a coin: TCP/ECN/RED versus ATM/FECN

[Ted Faber]

On Tue, Apr 17, 2001 at 04:42:37PM -0700, Alhussein Abouzeid wrote:
> 
> Hi all,
> 
> I was wodering why is it that people seem to regard (and hence analyse)
> the TCP/ECN/RED congestion control scheme as a fundamental new idea?

As new as quantum physics, no.

From high enough up, many things look the same that are not on closer
examination.  The big differences are the location of the intelligence
(endpoints vs. network internals) and the failure modes.

I understand that the ATM stuff is evolving, and my experience with it
is stale.  I'm going by your description, and making allowances for
bright people having fixed some of the flaws I remember.

In TCP the intelligence is at the endpoints.  Routers and switches
have to know nothing at all.  If there are internal switches that
don't implement RED or ECN, the system performs reasonably (as
reasonably as TCP circa 1988 or better:-)).  As a result more new (and
old!)  technologies can run TCP.

The ATM control you described depends on intelligence and fixed
algorithms in the network.  If switches in part of the network don't
know how to send RM cells when they get congested, no source throttles
back, and congestoon collapses that part of the network or worse.
There are a variety of things you can do to try to support that
situation, but it complicates rather than simplifies your controls.
The underlying idea here is that the network internals are fairly
tightly administered, and that the switching systems are fairly
homogeneous.

The phone company and other centralized communications services were
based on that idea of tight control, and TCP style congestion control
is new in the sense that it performs fairly well without it.  TCPs
requirements for uniformity are less strict so the owners of the
infrastructure can be less tightly affiliated.

The other difference with the two is in stability.  In a congested TCP
network, the window size and the self-clocking bound the number of
outstanding bytes/source.  In the event of congestion collapse, a
source reacts by sending fewer bytes (no ACKS), and the amount
of data it has outstanding falls.  This is almost certainly the best
thing for the congested network.

In an extremely congested network running the controls you describe,
the endpoints have no requirement to be able to detect congestion
unless the network tells them.  (Wise applications would be able to do
so, but we're probably drifting back toward TCP then.)  In a
pathological case, all the RM cells would be lost and all the sources
would increase their rates.  That can't be good for the congested
network.  Again, you can make changes to fix this, and indeed I think
(well, hope really) that modern ATM congrestion avoidance systems are
more fail-safe than this.  At their core, though, congestion systems
that require communication with network elements for their correct
operation tend to get into the most trouble when the network is
congested and communication is difficult.

Again, that idea is a break with telco and other centralized network
control and is therefore new.

> The issue behind this question is; Is there any reason for not using
> the well developed analysis of congestion control in the context of
> the not-very-relevant-here ATM for analysing TCP/ECN/AQM if the
> Internet transport-layer congestion control already borrowed (or by
> conincidence used essentialy the same) fundamental algorithms?

Ummm, I'm uncertain that your arrow of causality points the right way.
Ramakrishnan/Jain and Jacobson published on the AIMD stuff before the
ATM congestion controls were on the drawing board.  And feedback
control in general predates either type of network, going back before
the steam engine.

In summary: there are significant differences in the systems.
TCP/ECN/RED were novel in their placement of intelligence and
assumptions of dumb or malicious network internals.  Learning from the
past is good: study TCP and steam engines. (:-))


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20010417/a830e948/attachment.bin