<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Let me frame the problem in a different
way, then I think it becomes obvious where we talk at cross
purposes.<br>
Let me assume a greedy, infinite data stream.<br>
Let me call the original data stream "information bytes" and the
encoded stream "code bytes" (as in usual channel coding).<br>
<br>
Now the problem is that we want to <i>reliably</i> convey data
from a sender to a receiver.<br>
<br>
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?<br>
<br>
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.<br>
When there is little noise, we may perhaps need 10.000 bytes.<br>
<br>
Perhaps, we have some channel outages during the transfer and need
200.000 bytes.<br>
<br>
I don't know.<br>
<br>
Different from traditional TCP, the receiver issues ACKs in
certain intervals - independent from what he actually has
successfully received, correct?<br>
<br>
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.<br>
<br>
As a general remark I recall the well known fact: TANSTAAFL.<br>
<br>
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.<br>
<br>
In this case the flaw may be (and this is quite often met) some,
if very slight and subtle, confusion of terms.<br>
<br>
<br>
Am 03.04.2013 01:18, schrieb Lachlan Andrew:<br>
</div>
<blockquote
cite="mid:CAPpWWaKMn6MzUj461UuXjvLx9gQnu4n=DhFZreOnEPQMsgOLKg@mail.gmail.com"
type="cite">
<pre wrap="">On 3 April 2013 08:20, Detlef Bosau <a class="moz-txt-link-rfc2396E" href="mailto:detlef.bosau@web.de"><detlef.bosau@web.de></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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
<a class="moz-txt-link-rfc2396E" href="http://caia.swin.edu.au/cv/landrew"><http://caia.swin.edu.au/cv/landrew></a>
Ph +61 3 9214 4837
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
skype: detlef.bosau
ICQ: 566129673
<a class="moz-txt-link-abbreviated" href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a> <a class="moz-txt-link-freetext" href="http://www.detlef-bosau.de">http://www.detlef-bosau.de</a>
</pre>
</body>
</html>