Re: Why do we need congestion control?
Jon Crowcroft <[email protected]>
| Newsgroups | gmane.network.end2end |
|---|---|
| Message-ID | <[email protected]> |
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 <[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> >>> 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 >>[email protected] 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@mail.gmail.com" >> type="cite"> >> <pre wrap="">On 3 April 2013 08:20, Detlef Bosau <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></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:[email protected]">[email protected]</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