[Bloat] curious.....

[Sebastian Moeller]

Hi Dave,


On Dec 10, 2013, at 20:05 , Dave Taht <dave.taht at gmail.com> wrote:

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

	Santa Barbara, how nice. Since we left California this spring I started to miss the Pacific; funny since we rarely went to the beach. Anyway I envy you :)

> 
> 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 guess I like knobs, they give me a warm fuzzy feeling; I do prefer not having to touch those knobs though :)

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

	At least in the past there were alternatives to QOS in OpenWRT, I am not sure whether these survived to recent restructuring though.

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

	Ah, I guess I should actually try to test how this works with my VoIP. What I like about the 3 tier system is that if the need arises it will be relatively simple to control the latency of specific traffic by marking it appropriately. I guess it is a belts and suspender thing. I have a question though; with simplest.qos we still use HTB svn though there is no hierarchy, so maybe we could switch to TBF (assuming TBF is actually less computationally demanding than HTB)?

> But that breaks
> with tradition too much, and ietfers
> are off specifying 1024 different behaviors based on the 8 bits of the
> tos field,

	This sounds quite complicated, and I am unsure whether that is really required for a home router :)

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

	Ah, okay, so would you agree that simple.qos then should be the default?

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

	To allow at least a few packets worth of queueing?

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

	Sorry wrong country, I have to pass.

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

	Done, okay, this was easy :) Since I am still on 3.10.18-1 I will first upgrade to the most recent one to see the changes you made to the AQM code… Also this will allow me to test my hypothesis about sysupgrade being affected by mount-utils. 

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

	If I understand it correctly the TSQ patch should only affect traffic that terminates at the router; so it might affect netsurf sessions to the router but should not affect normal routing, or am I wrong here?


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

	I should be able to pull this off, even though I am under a deadline right now.

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

	Do you want to rename every occurrence of AQM or would you be happy with just changing the labels on the webpage? Since that is easy I will fold this into my modification...

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

	Yeah, but we only run tc while setting things up and even if it would take a minute we would not care?

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

	Ah, I see, also if included in the kernel this actually would have a fighting chance to make it into the firmware of commercial routers and help people who have no time/fun to tinker with things.

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

	Mmmh, I see qos-scripts is still part of cero's packages, I guess I will try figuring out whether/how that would work.

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