[e2e] Why do we need congestion control?

[Detlef Bosau]

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


-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30
70565 Stuttgart                            Tel.:   +49 711 5208031
                                            mobile: +49 172 6819937
                                            skype:     detlef.bosau
                                            ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130403/88c47f47/attachment.html