Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt

Hi all,

quick comment on ledbat. The main use case for bitTorrent was huge buffers in home routers (where in fact the configuration could be changed by the user but usually the user does not know what to do and just keeps the default config and complains about bitTorrent disturbing Skype calls). This is the reason why the target value is 100ms which is very large but there are (I guess still) home routers which have even larger buffers. For those cases ledbat will still help the problem because these home routers will not suddenly implement AQM. However, the large target value of 100ms has further the effect that if the bottleneck is somewhere deeper in the network where buffers usually are anyway smaller than 100ms (because the link speed is much higher), ledbat traffic will compete equally with other traffic (of other users), which is more or less intentionally as also the bitTorrent user wants to finish its download at some point.

Mirja

> Am 22.05.2015 um 07:51 schrieb Dave Taht <dave.taht@gmail.com>:
> 
> On Thu, May 21, 2015 at 10:18 PM, Simon Barber <simon@superduper.net> wrote:
>> On 5/18/2015 10:00 AM, Dave Taht wrote:
>>> 
>>> LEDBAT was probably my first concern and area of research before entering
>>> this project full time. I *knew* we were going to break ledbat, but the two
>>> questions were: how badly? (ans: pretty badly) and did it matter? (not that
>>> much, compared to saving seconds overall in induced delay)
>> 
>> LEDBAT is about more than just reducing the delay caused by the steam - it's
>> also about the bandwidth impact. AQM solves the delay situation, but breaks
>> the bandwidth reduction that LEDBAT can achieve today when other traffic is
>> present.
> 
> In pointing out that paper I have to stress that their "good" ledbat result,
> (read the text around table 3)
> 
> "was look! it's scavenging!"
> 
> And mine was:
> 
> "with over 7 seconds of inherent delay on the link!"
> 
> Revisiting the data sets with reasonable amounts of buffering on the link,
> a correctly functioning tcp stack, and a few other variables more under
> control would be good... (much as I pushed for dctcp to be looked at
> once real patches landed for it)
> 
> ... as would investigating actual behavior of ledbat on real links with
> aqm and fq technologies on them. While I poked into it quite a lot,
> I did not do much more rigorous than observe that web traffic
> worked a lot better when torrent was present in a fq/aqm'd environment
> and that cubic outcompeted it slightly, generally.
> 
> There was supposed to be someone else updating the tcp_ledbat
> kernel module we used, but that never got fixed, and it is in a dire
> need of update since the change to usec from msec and other
> major tcp modifications in the linux kernel.
> 
> 
>> 
>>> while we have long recommended CS1 be set on torrent, it turns out that a
>>> lot of gear actually prioritizes that over BE, still. It helps on the
>>> outbound where you can still control your dscp settings. Many torrent users
>>> have reported just setting their stuff to max outbound and rate limiting
>>> inbound, and observing no real effects on their link.
>> 
>> 
>> Do you have examples of the gear that prioritizes CS1 over best effort? How
>> often have you seen it? Did you see it in places where it would be
>> important?
> 
> Yes. a lot. and yes. More details I can do later.
> 
>> Simon
> 
> 
> 
> -- 
> Dave Täht
> Open Networking needs **Open Source Hardware**
> 
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
> 
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm