[e2e] Why do we need congestion control?

Lachlan Andrew lachlan.andrew at gmail.com
Tue Apr 2 16:18:36 PDT 2013


On 3 April 2013 08:20, Detlef Bosau <detlef.bosau at web.de> wrote:
> I only qoute one sentence:
>
> the recovery delay is
> independent of the RTT
>
> Hm. I think, we exchanged some pm on this issue, however: either I don't
> understand this sentence or I don't believe it.
>
> Perhaps, I misunderstand ist completely. However, your paper and others
> insinuate that with erasure codes a recovery the time for a packet transfer
> is somehow statistically bounded. Where is the fault in my way of thinking?

Greetings Detlef,

That statement is true.  The "recovery" isn't triggered by the loss,
and so there is no need for a RTT feedback delay to ask for
retransmission.  An ideal erasure code works by sending many "views"
or "hashes" of a file (rather than each packet corresponding to a
small piece of the file).  The sender sends continuously until the
receiver has received enough views to be able to reconstruct the file.
 There is no feedback from the receiver during this time, and so no
RTT delay.  Of course, there is a one-way delay before the first
packet is received.

Once the receiver has decoded the file, it sends a single ACK to tell
the sender to stop.  (That "single ACK" could be a stream of packets,
if the chance of losing an ACK packet is high.)  That ACK takes
another one-way delay to get to the sender, but that doesn't slow down
the "recover" of the data.  We can't avoid the need for the total
transfer to take at least one RTT, but that doesn't have to be
incurred for every packet recovery.

Cheers,
Lachlan

--
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837


More information about the end2end-interest mailing list