[e2e] Why do we need congestion control?
Emmanuel Lochin
emmanuel.lochin at isae.fr
Wed Apr 3 04:47:05 PDT 2013
On 03/04/2013 11:41, Jon Crowcroft wrote:
> 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...
Hi Detlef,
You might have missed the last curves in my PDF. However, I think you
should have look to these recent work:
M. Kim, M. Medard, J. Barros "Modeling network coded TCP throughput: a
simple model and its validation" Valuetools 2011 :
http://www.mit.edu/~medard/papers2011/Modeling%20Network%20Coded%20TCP.pdf
and our work here :
Tournoux, Pierre-Ugo and Lochin, Emmanuel and Lacan, Jérôme and
Bouabdallah, Amine and Roca, Vincent /On-the-fly erasure coding for
real-time video applications./ <http://oatao.univ-toulouse.fr/4867/>
(2011) IEEE Transactions on Multimedia : http://oatao.univ-toulouse.fr/4867/
to have an idea of the coding scheme used.
Also, there are proposal that enable adaptive FEC (or adpative
on-the-fly coding in my case) to adapt the coding scheme use.
EL
>
> >>
> >>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
>
>
--
Emmanuel Lochin
Professeur ISAE - OSSI
Institut Supérieur de l'Aéronautique et de l'Espace (ISAE)
Issu du rapprochement SUPAERO et ENSICA
10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4
Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88
Web : http://personnel.isae.fr/emmanuel-lochin/
---
"This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130403/f9d3685f/attachment-0001.html
More information about the end2end-interest
mailing list