<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">Just some few remarks.<br>
<br>
DTCP assumes fair AQM. How is this achieved? Particularly: Fair
queueing is criticized for being to expensive. Isn't "fair AQM"
similarly expensive?<br>
<br>
Second question: Jon and you refer to Jain's fairness index. Fine.
From a bird's perspective, we can assess the JFI for a given
network. However: How is good fairness then achieved by the
protocol? (I just got the Snoeren-Paper, this will be enlightening
here :-))<br>
<br>
As a last remark: You always assume greedy flows here. When I
claimed our problem would be that we neglect the existence of
mice, I received a PM, I certainly would be kidding. Now, we all
are one whole day older ;-) And we go on to neglect the existence
of mice!<br>
<br>
<br>
Only as some few remarks.<br>
<br>
<br>
DB<br>
<br>
BTW: It would be interesting to discuss code strength here which
certainly depend on the (corruption caused) loss rate and the
(congestion caused) drop rate here and which directly affect a
flow's goodput. Even more, and that's a quite basic criticism: You
once more solve all congestion problems purely end to end. <br>
Actually, that's one of the major flaws in congestion control at
all. When I correctly understand the principles of Jerry Salzer's
paper, it would be nice to solve problems at their origin. Or at
least there, where they can be solved effectively. So, when
resource distribution is being done best at routers, it should be
done at routers. And not at the end points. And when the
adaptation of an FEC scheme to an actual link noise situation is
being done best at the radio interface, where the noise situation
is immediately known e.g. by observation and assessment of a pilot
signal, adaptation should be done there and not at the end points
"200 ms later". Particularly, it does not make sense to bother the
whole network with the overhead of some extremely strong FEC
scheme because there is one flow which has to pass a noisy air
interface. And we place the error protection / recovery on the
end nodes while this fits into some e2e-religion.<br>
According to Joe's remark some days ago, it would make much more
sense to locally retransmit a faulty block now and then locally
than to let the whole world suffer from unnecessary overhead.
However, the only correct answer which scheme is eventually to be
chosen is "it depends..." and than we have to carefully discuss
the necessary trade offs.<br>
<br>
<br>
<br>
<br>
Am 03.04.2013 13:47, schrieb Emmanuel Lochin:<br>
</div>
<blockquote cite="mid:515C16B9.3070007@isae.fr" type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<div class="moz-cite-prefix">On 03/04/2013 11:41, Jon Crowcroft
wrote:<br>
</div>
<blockquote cite="mid:E1UNKCN-0005kR-8M@mta1.cl.cam.ac.uk"
type="cite">
<pre wrap="">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...</pre>
</blockquote>
<br>
Hi Detlef,<br>
<br>
You might have missed the last curves in my PDF. However, I think
you should have look to these recent work:<br>
<br>
M. Kim, M. Medard, J. Barros "Modeling network coded TCP
throughput: a simple model and its validation" Valuetools 2011 :
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.mit.edu/%7Emedard/papers2011/Modeling%20Network%20Coded%20TCP.pdf">http://www.mit.edu/~medard/papers2011/Modeling%20Network%20Coded%20TCP.pdf</a><br>
<br>
and our work here : <br>
<br>
<span class="person_name">Tournoux, Pierre-Ugo</span> and <span
class="person_name">Lochin, Emmanuel</span> and <span
class="person_name">Lacan, Jérôme</span> and <span
class="person_name">Bouabdallah, Amine</span> and <span
class="person_name">Roca, Vincent</span> <a
moz-do-not-send="true"
href="http://oatao.univ-toulouse.fr/4867/"><em>On-the-fly
erasure coding for real-time video applications.</em></a>
(2011) IEEE Transactions on Multimedia : <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://oatao.univ-toulouse.fr/4867/">http://oatao.univ-toulouse.fr/4867/</a><br>
<br>
to have an idea of the coding scheme used.<br>
<br>
Also, there are proposal that enable adaptive FEC (or adpative
on-the-fly coding in my case) to adapt the coding scheme use. <br>
<br>
EL<br>
<br>
</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>