[e2e] Why do we need congestion control?
vinayakh at gmail.com
Wed Apr 3 18:48:50 PDT 2013
And a bit more work work so d wrote I have read each war were in each week
of this message e rather Read
On Apr 3, 2013 3:40 AM, "Detlef Bosau" <detlef.bosau at web.de> wrote:
> Let me frame the problem in a different way, then I think it becomes
> obvious where we talk at cross purposes.
> Let me assume a greedy, infinite data stream.
> Let me call the original data stream "information bytes" and the encoded
> stream "code bytes" (as in usual channel coding).
> Now the problem is that we want to *reliably* convey data from a sender
> to a receiver.
> How long does it take to convey 1000 bytes without errors? O.k., this may
> be independent from the RTT - however, how is the RTT defined?
> When the channel is error free, it may perhaps (due to overhead) suffice
> to send 1500 bytes - and the receiver can correctly the first 1000 bytes.
> When there is little noise, we may perhaps need 10.000 bytes.
> Perhaps, we have some channel outages during the transfer and need 200.000
> I don't know.
> Different from traditional TCP, the receiver issues ACKs in certain
> intervals - independent from what he actually has successfully received,
> So I see that this RTT is in fact independent from the time it takes to
> successfully convey a certain amount of data - to the price that this time
> is hardly known.
> As a general remark I recall the well known fact: TANSTAAFL.
> Whenever a certain sophisticated technology insinuates the existence of
> some perpetual motion machine, we should stop our thoughts immediately and
> look for the error. The error may be not obvious. But it exists. Without
> any reasonable doubt. When a long formal deduction leads to result which is
> known to be wrong, there must be a flaw in the deduction.
> In this case the flaw may be (and this is quite often met) some, if very
> slight and subtle, confusion of terms.
> Am 03.04.2013 01:18, schrieb Lachlan Andrew:
> On 3 April 2013 08:20, Detlef Bosau <detlef.bosau at web.de> <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.
> Lachlan Andrew Centre for Advanced Internet Architectures (CAIA)
> Swinburne University of Technology, Melbourne, Australia<http://caia.swin.edu.au/cv/landrew> <http://caia.swin.edu.au/cv/landrew>
> Ph +61 3 9214 4837
> Detlef Bosau
> Galileistraße 30
> 70565 Stuttgart Tel.: +49 711 5208031
> mobile: +49 172 6819937
> skype: detlef.bosau
> ICQ: 566129673detlef.bosau at web.de http://www.detlef-bosau.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the end2end-interest