Re: Why do we need congestion control?
Lachlan Andrew <[email protected]>
| Newsgroups | gmane.network.end2end |
|---|---|
| Message-ID | <CAPpWWaKMn6MzUj461UuXjvLx9gQnu4n=DhFZreOnEPQMsgOLKg@mail.gmail.com> |
On 3 April 2013 08:20, Detlef Bosau <[email protected]> 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