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

Alhussein Abouzeid hussein at ee.washington.edu
Tue Apr 17 16:42:37 PDT 2001

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?

In essence, TCP/ECN/RED is the same as rate control in
ATM networks FECN/BECN/PRCA (I think); The allowed cell rate of the
source is changed according to the congestion status of the network;
an occurrence of congestion is detected at each intermediate switch by
monitoring the queue length of its cell buffer; If the queue length
exceeds a threshold, the switch sets the (explicit congestion indication) bit,
and when the destination end system receives a cell with marked EFCI bit,
it sends a resource management(RM) cell back to the source along the
backward path (other famous variants, including per-flow handling, not
mentioned here); Upon receiving the RM cell, the source end system decreases
its cell transmission rate multiplicatively; when a certain time expires
without receiving any RM cells, the source assumes that there is no
congestion in the network and periodically increases its rate additively.

Yes, there are minor differences (e.g. using average queue size in RED
versus instantaneous queue size, ACKs are always sent while RM's are only
sent when congestion hapens,etc.),
but the fundamental algorthms: Explicit Congestion Notification based on
queue size and AIMD of traffic in response to congestion signals remain
conceptually the same.

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?



More information about the end2end-interest mailing list