[e2e] Why do we need congestion control?
Jon Crowcroft
Jon.Crowcroft at cl.cam.ac.uk
Wed Apr 3 02:41:40 PDT 2013
lets do a simple thought experiment
lets say you have two users sharing at least one router's output port/link
as part of their path, and both users are greedy
lets say you have a choice in each user whether to use either
1) feedback based rate adjustment (don't care if its VJCC cwnd or TFRC based)
or
2) a rateless erasure code
you could have both users' flows use 1 or both 2 or a mix, i.e. 3 cases
1+1, 2+2 or 1+2
now, how do you choose the code to get max goodput for the 3 cases...
>>
>>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
>>
>>
>>--------------030907090300010502060106
>>Content-Type: text/html; charset=ISO-8859-1
>>Content-Transfer-Encoding: 7bit
>>
>><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 at 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 at web.de"><detlef.bosau at 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 at web.de">detlef.bosau at web.de</a> <a class="moz-txt-link-freetext" href="http://www.detlef-bosau.de">http://www.detlef-bosau.de</a>
>>
>></pre>
>> </body>
>></html>
>>
>>--------------030907090300010502060106--
cheers
jon
More information about the end2end-interest
mailing list