[e2e] Why do we need congestion control?

[Detlef Bosau]

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.


DB

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)
>> 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
>


-- 
------------------------------------------------------------------
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130403/bf9cd33d/attachment.html