Re: Why do we need congestion control?

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" <[email protected]> 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
> bytes.
>
> I don't know.
>
> Different from traditional TCP, the receiver issues ACKs in certain
> intervals - independent from what he actually has successfully received,
> correct?
>
> 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 <[email protected]> <[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> <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:          [email protected]                     http://www.detlef-bosau.de
>
>