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

[Soo-hyeong Lee]

I think the most significant differences are that TCP controls 'window' not rate and that TCP can benefit from 'self-clocking'.
TCP sets its sending rate to only slightly higher than available rate thus resulting in (slower than) linear increase of queue length.
However, EPRCA, a scheme for ABR service, increases its sending rate exponentially in time (proof is in PS) thus requiring a large amount of buffer.

There is another aspect: the target of research being either unknown future application or known existing application.
TCP research is typically done on existing applications. 
However, as far as I know, the research on ABR has been focused on some unknown application that will be satisfied when available bandwidth is efficiently and evenly shared and minimum bandwidth is guaranteed. I don't think this type of application exists so far.

Sincerely yours

Soo-hyeong

PS : 
<Proof that EPRCA means exponential rate increase in time>

first assume that the RTT is T,
that the rate x(t) increases by 1 whenever RM cell is returned, 
and that an RM cell is inserted every Nrm cells have been transmitted.

Now the returning RM cell interval is Nrm/x(t-T).
For every increase of 1, time is passed by Nrm/x(t-T).
For rate increase dx greater than 1, time should be advanced by (Nrm*dx)/x(t-T) which corresponds to dt.
In other words, dt = (Nrm*dx)/x(t-T), which is dt/dx = Nrm/x(t-T).
Here we see, dx/dt = x(t-T)/Nrm, which implies x(t) must be an exponential function.


----- Original Message ----- 
From: "Alhussein Abouzeid" <hussein at ee.washington.edu>
To: <end2end-interest at postel.org>
Sent: Wednesday, April 18, 2001 8:42 AM
Subject: [e2e] Two sides of a coin: TCP/ECN/RED versus ATM/FECN


> 
> 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?
> 
> comments?
> 
> Hussein.
> 
> 
>