[Bloat] Some updates on hacking on AQMS

[Dave Taht]

On Thu, Jun 23, 2011 at 11:01 PM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
> Le jeudi 23 juin 2011 à 17:10 -0600, Dave Taht a écrit :
>> On Thu, Jun 23, 2011 at 4:45 PM, Juliusz Chroboczek <jch at pps.jussieu.fr> wrote:
>> >> It really seems that ECN support could be added generically for all
>> >> qdiscs that currently do packet drop. Creating a generic mark_or_drop
>> >> function is easy.
>> >
>> > As hinted in a previous message -- please don't.  Every qdisc must be
>> > examined individually to check if it is suitable for ECN.
>> >
>> > Consider also the following.  If the administrator specifies a maximum
>> > rate of 100 Mbit/s, he probably doesn't expect the outgoing traffic to
>> > exceed that rate under any circumstances.  If you start marking instead
>> > of dropping, you must make sure that the resulting traffic is still
>> > under 100 Mbit/s, including the marked packets.
>>
>> In designing this particular concept I made sure that was an option,
>> in the mildly recorrected:
>>
>> http://www.bufferbloat.net/projects/bloat/wiki/Save_the_Ants
>>
>> Try harder to not shoot the ants, but make ecn marking a first class
>> option throughout the qdiscs...
>>
>> if possible..
>
> I believe it was done.
>
> qdisc implementations are not random, but follow extensive research
> works.

All of which is either invalidated, obsolete, or newly revalidated
since the advent of wireless, the increase in using TCP for short
transfers, and nat becoming predominant, the increase in traffic
volume overall, and the introduction of both voice and video calling
on the web, and the introduction of massive amounts of video traffic
to the Internet, sadly most of which are unclassifyable and on port
80...

... The workloads have changed, the characteristics of traffic have
changed, and experiments need to be re-run.

> Before doing a change like that, you must redo all the experiments and
> show the pro/cons ;)

I'm kind of hoping to be building a platform where others can do that easier.

> Once qdisc queue is _full_, its too late, you have to drop packets
> anyway. And its not because at least one flow is not responsive :
> It might be because one thousand flows began their life at the very same
> moment :(

Painfully aware of that.

>
>
>
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com