[e2e] Why do we need congestion control?
detlef.bosau at web.de
Wed Apr 3 06:40:14 PDT 2013
Just some few remarks.
DTCP assumes fair AQM. How is this achieved? Particularly: Fair queueing
is criticized for being to expensive. Isn't "fair AQM" similarly expensive?
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 :-))
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!
Only as some few remarks.
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.
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.
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.
Am 03.04.2013 13:47, schrieb Emmanuel Lochin:
> 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)
>> 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 :
> 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 :
> 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.
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
detlef.bosau at web.de http://www.detlef-bosau.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the end2end-interest