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

[Soo-hyeong Lee]

I am sorry I have to make a correction on my previous message.
Rate increase speed should be broken down into two parts.

1) When the bottleneck link is underutilized,
TCP congestion-avoidance increases its sending rate linearly over time.
EPRCA increases its sending rate exponentially over time. (Proof is in the previous message.)

2) When the bottleneck link is fully utilized,
TCP congestion-avoidance sets its sending rate to availible rate + 1/RTT.
EPRCA increases its sending rate linearly over time, whose slope is \frac{available bandwidth}{Nrm}. (Proof is in the PS)
Thus the queue length evolves as a square of time in EPRCA.

My point is that EPRCA increases the sending rate much above its available rate, thus requiring more buffer than is required in TCP/ECN to avoid loss. If buffer is the same, EPRCA should exhibit less throughput than TCP does.
I'd be very glad if you can correct my possible errors.

Sincerely yours.

Soo-hyeong

PS:
 <Proof of EPRCA Rate Increase Speed in Full-Utilization Case>
First assume that the available bandwidth, BW,  is constant,
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.

Then the following holds:
dx=1
dt = Nrm/BW,
which means linear rate increase over time (if BW is constant).


----- Original Message ----- 
From: "Soo-hyeong Lee" <shlee at mmlab.snu.ac.kr>
To: "Alhussein Abouzeid" <hussein at ee.washington.edu>; <end2end-interest at postel.org>
Sent: Wednesday, April 18, 2001 12:58 PM
Subject: Re: [e2e] Two sides of a coin: TCP/ECN/RED versus ATM/FECN


> 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.
> > 
> > 
> > 
>