[Bloat] curious.....

Tue Dec 10 14:05:51 EST 2013

I am here:

http://conferences.sigcomm.org/co-next/2013/program.html

this week, so expect emails from me to be sparse to non-existent.

On Sat, Dec 7, 2013 at 3:24 AM, Sebastian Moeller <moeller0 at gmx.de> wrote:
> Hi Dave,
>
>
> On Dec 6, 2013, at 19:15 , Dave Taht <dave.taht at gmail.com> wrote:
>
>> On Fri, Dec 6, 2013 at 9:19 AM, Juliusz Chroboczek
>> <jch at pps.univ-paris-diderot.fr> wrote:
>>>> I note that openwrt's qos-scripts still do not do ipv6 properly, and I think
>>>> cerowrt's aqm system is better in most respects, and it's easy to
>>>> include on an openwrt system.
>>>
>>> Perhaps you should push your system to OpenWRT?
>>
>> There is still some work going on to streamline the gui. there are
>> less features in the aqm-scripts for
>> prioritizing packet types than qos-scripts.
>
>         Do you think these additional features are essential? I assume that openwork would not immediately drop their QOS packet so "AQM/SQM" and QOS will live together for some time, so having slightly different features might still be okay.

Most people like knobs. I don't - most people also have a tendency to
turn up everything to 11. So it is perhaps too idealistic of me to try
and come up with something that handles the bulk of shaping needs with
no knobs whatsoever.

I would certainly like openwrt folk to fix qos-scripts to work right
with ipv6 in particular, but the connection tracking element is
required in the current qos-scripts, and substantial changes to how it
works would need to be made.

So offering sqm-scripts as an alternative in the main distro would be good,
especially for ipv6 users, but also because I do think it's generally better.

>> I just had to come up with
>> a way to disable it at high (> 80 mbit) rates on incoming traffic (not
>> enough cpu in cerowrt), so I'd like it to run faster, maybe using drr
>> in that case, or something like what free.fr uses...
>>
>> And there are actually two aqm/packet scheduling shapers in there (a
>> simple 1 tier and a 3 tier one)
>
>         What is your opinion, should we default to the single tier version or the 3 tier version?

I actually get such great results from simplest.qos on normal traffic,
*on systems running at 5Mbit+* even with bit torrent, that I'm tempted
to recommend that rather than the three tier system. But that breaks
with tradition too much, and ietfers
are off specifying 1024 different behaviors based on the 8 bits of the
tos field, so I fear that only 3 bins is controversial, and 1 bin,
anathema.

Below that prioritization is truly needed and helps, and there
certainly is a vague zone between 5 and 30MB on the traffic  types I
see in the home. So 3 bins
seems to continue to make sense in the general case.

Recently I had some correspondence with the person at free that
deployed fq_codel, who has deployed *at scale* a three tier system
similar to cero's but it runs at line rate w/adsl, and combines prio,
drr, and fq_codel. It's running on the "revolution V6" box. There was
an interesting short algo to increase target at bandwidths below
5mbit, which seems to make sense.

Does anyone here have free.fr access and can do a rrul measurement?

And in terms of research still ongoing I'd like (someone) to take a
hard look at gargoyles' "acc".

>> , and it supports a variety of
>> aqm/scheduling  algorithms, not just fq_codel, which is there for the
>> research but will confuse the end users…
>
>         I guess it should be relatively easy to hide this under the control of a "I know what I am doing give me all the knobs to play with" checkbox with a scary name, say "research"… :)

Sure. "Advanced".

>         Question, I tried to send you a version of aqm.lua that hides the detailed link layer fields in the GUI if none is selected as link layer adaptation mechanism did that ever reach you (I have some issues with my mailer so it might not have made it out of my system for good)? But in the same vain, hiding "Queueing discipline" and "Queue setup script" should be simple…

I saw it whiz by as I was doing a zillion other things that week.
Sorry! There were two other patches I really wanted in the that
release - the fix to TSQ and pie v4. The first was put into 3.10.23,
and the second hit netdev a few days ago.

I am limited to working on cero on sundays right now so I can
incorporate your latest patch if it arrives by sunday morning.

>
>> and I am not happy with
>> "aqm" at a word, because the packet scheduling part counts for a LOT,
>> so i'd rename it to sqm or someting like that.
>
>         What about the long and verbose "Latency and Bandwidth Control" or something else that talks about the "benefit" to the user?

That's better. I agree that makes sense to accentuate the positives.

"Latency and Bandwidth Optimization"? LBO?

>>
>> So I'd argue it needs some love. And a solid set of requirements that
>> it meets before it is as standardized as, say, wondershaper is. And if
>> it got that standardized, I think it would run a heck of a lot faster
>> if it got poured into C.
>
>         Just curious, isn't the kernel doing all the work for us? I ,foolishly?, assumed that the script is just configuring the kernel and since this is done rarely why would we bother about the run time…

HTB's code is highly flexible and highly inefficient .

tc is an incredibly flexible construction set for discs. This also
comes at the expense of inefficiency as well.

One of the points of fq_codel is it combines a drr-like algorithm with
the codel algorithm in the same code so, for example, we get buffer
sizes much more under control than if we were to use
tc to combine, say DRR + codel or DRR + pie (or QFQ + pie). And there
is a great deal of synergy between several characteristics of the two
basic algorithms.

So I keep hoping with a successor to aqm-scripts, call it "cake", that
we can make something even better - that scales to 200+mbit on current
hardware, uses less memory, groks diffserv and packet prioritization
sanely, makes your networks scale farther, and will make your teeth
whiter and improve your sex life.

>> However it is pretty stable and could definitely use more eyeballs,
>> and it works right with ipv6 and seems better than qos-scripts on most
>> benchmarks... so I'll ask the openwrt folk if they want it upstream.
>>
>> In the interim, existing openwrt users can add ceropackages-3.3 into
>> their feeds.
>>
>> And incorporate it into their build with
>>
>> ./scripts feeds install aqm-scripts luci-app-aqm
>
>         Note: people should at least disable openwork's QOS before activating "AQM"; or should we teach AQM to either disable qos on activation or at least warn the user about a potential conflict. I assume people will want to compare the performance of both…

Yes, the two packages should either be mutually exclusive or aware of
each other.

> best
>         Sebastian
>
>>
>>
>>
>>> -- Juliusz
>>
>>
>>
>> --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
>> _______________________________________________
>> Bloat mailing list
>> Bloat at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html