[Cerowrt-devel] SQM Question #4: What are the major features of simple.qos, simplest.qos, and drr.qos scripts

[Cerowrt-devel] SQM Question #4: What are the major features of simple.qos, simplest.qos, and drr.qos scripts

[Rich Brown]

QUESTION #4: What are the major features of (and/or differences between) the simple.qos, simplest.qos, and drr.qos scripts?

I’ll use this information to flesh out the Details… section for that section of the page.

Re: [Cerowrt-devel] SQM Question #4: What are the major features of simple.qos, simplest.qos, and drr.qos scripts

[Dave Taht]

I ended up taking today off and not trying to do an edit, and I'm only
going to try to answer this one question tonight as the others are too
hard for this time of night.

Thank you for breaking your questions down into bite sizes pieces.

On Sat, Dec 28, 2013 at 8:35 PM, Rich Brown <richb.hanover@gmail.com> wrote:
> QUESTION #4: What are the major features of (and/or differences between) the simple.qos, simplest.qos, and drr.qos scripts?

Simplest.qos is the simplest possible htb based shaper, with only a
single fq_codel qdisc (with 1024 queues) Advantages are that it does
optimal mixing and uses the least memory. (it works pretty good down
to about 16 queues actually)

Simple.qos is a three tier system that can use diffserv and simple
prioritization to give or remove priority to certain kinds of
identifiable flows.  Right now it gives priority to locally generated
dns and ntp packets, and a couple diffserv markings, and deprioritizes
CS1. It would be nice if it was feature-competitive with qos-scripts,
which have (for example) l7 inspection to find common torrent-like
protocols, and a gui with lots of knobs to control that aspect.

I waffle on calling things "tiers" rather than "queues". "levels?"
"Bands?" Band is used in the pfifo_fast and prio qdiscs, maybe we
should call it that. A queue can be a queue, but an fq_codel queue
consists of up to 64k flows which can also be considered queues. And
it's turtles all the way down.

drr.qos snuck in there accidentally on a commit. It's not functional
and I should remove it. I'd intended to build up a emulation of more
or less exactly what free.fr has deployed, but haven't got around to
writing the code.

Their system:

prio 1     Strict priority fq_codel
prio 2 -> DRR 1 Best Effort fq_codel (80% weight)
         -> DRR 2 Background fq_codel (20% weight)

The advantage of it is that you can run it without htb at all and
still get a 3 tier shaper that works at *line rate*. (free wrote their
own very tight DSL driver and doesn't have to muck with htb on
egress). A disadvantage is unless the prio 1 queue is well admission
controlled... it can starve the best effort and background queues.

(originally, maxime at free tells me that this was a 3 band prio
shaper but found that too much traffic was marked background, and too
easily starved. I hope that this will be the final nail in the coffin
for advocates of strict prio queues in general use)

If we ever get around to trying to get tbf working perhaps that + a
free.fr-like system might be more cpu efficient than htb.

"Cake" if I ever get around to finishing it does a form of weighting
for 3 bands, and can't starve a queue under any circumstances. Me
being me I emulated this with qfq first, but qfq is too heavy....

I will probably use free's example in an upcoming rfc.

PS I'd like to do a writeup/rant about everything that is wrong with
wondershaper and get it published somewhere that will knock various
links to it out of the top spot on google.

PPS perhaps a glossary of terms is needed, for things like "band",
"admission controlled", "starvation", weighting.

> I’ll use this information to flesh out the Details… section for that section of the page.
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

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

[Cerowrt-devel] Questions about the use of HTB & fq_codel in simple.qos, simplest.qos

[Rich Brown]

[-- Attachment #1: Type: text/plain, Size: 2968 bytes --]

I've been thinking about the message we're sending re: QoS/prioritization vs SQM, and I'm not clear on what our story is. Here's what I understand:

- On one hand, we say that good SQM algorithms (fq_codel, for example) will do an astonishingly good job of minimizing latency without any parameters (except perhaps link speed for slow bottlenecks)

- On the other hand, our example sqm-scripts (simplest.qos, simple.qos) have a HTB based shaper installed that (if I understand Dave Täht's description below) seems designed to limit the rate of various kinds of traffic before it gets to fq_codel. (The HTB shaper would, a priori, require some kind of configuration/parameter.)

My questions:

- Why do we provide an HTB-based shaper in simple.qos and simplest.qos?
- Do the shapers in these sqm-scripts actually limit bandwidth for various kinds of traffic? Might that not leave unused bandwidth?
- Or do they just shunt certain packets to higher or lower priority fq_codel tiers/bands/levels (terminology used in Dave's note below)?
- And if the latter, how does the "link" (I'm not sure of the proper term) know which of the tiers/bands/levels to dequeue next?

I'll state up front that I'm not entirely clear on the distinction between shapers, qdisc's, IFBs, etc. But I'm groping around for a simple, clear recommendation for what we should tell people to do so they can:
	a) Make their router work very well, with minimal latency
	b) Spend their time more usefully than tweaking QoS/priority settings (for example, by actually playing the game that whose lag you're trying to minimize :-)

Many thanks!

Rich

On Dec 29, 2013, at 2:24 AM, Dave Taht <dave.taht@gmail.com> wrote:

>> QUESTION #4: What are the major features of (and/or differences between) the simple.qos, simplest.qos, and drr.qos scripts?
> 
> Simplest.qos is the simplest possible htb based shaper, with only a
> single fq_codel qdisc (with 1024 queues) Advantages are that it does
> optimal mixing and uses the least memory. (it works pretty good down
> to about 16 queues actually)
> 
> Simple.qos is a three tier system that can use diffserv and simple
> prioritization to give or remove priority to certain kinds of
> identifiable flows.  Right now it gives priority to locally generated
> dns and ntp packets, and a couple diffserv markings, and deprioritizes
> CS1. It would be nice if it was feature-competitive with qos-scripts,
> which have (for example) l7 inspection to find common torrent-like
> protocols, and a gui with lots of knobs to control that aspect.
> 
> I waffle on calling things "tiers" rather than "queues". "levels?"
> "Bands?" Band is used in the pfifo_fast and prio qdiscs, maybe we
> should call it that. A queue can be a queue, but an fq_codel queue
> consists of up to 64k flows which can also be considered queues. And
> it's turtles all the way down.
> ... Dave notes that inclusion of ddr.qos was a build error...


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [Cerowrt-devel] [Bloat] Questions about the use of HTB & fq_codel in simple.qos, simplest.qos

[Jonathan Morton]

> On 10 Apr, 2015, at 00:35, Rich Brown <richb.hanover@gmail.com> wrote:
> 
> - Why do we provide an HTB-based shaper in simple.qos and simplest.qos?
> - Do the shapers in these sqm-scripts actually limit bandwidth for various kinds of traffic? Might that not leave unused bandwidth?
> - Or do they just shunt certain packets to higher or lower priority fq_codel tiers/bands/levels (terminology used in Dave's note below)?
> - And if the latter, how does the "link" (I'm not sure of the proper term) know which of the tiers/bands/levels to dequeue next?

The short answer is: because cake isn’t out in the real world yet.  We’re working on it.

HTB and IFB as used in those scripts is a stopgap solution, to take control of the bottleneck queue so that fq_codel can work on it.  Cake includes a shaper which does the job more effectively and more efficiently.

Ultimately, what we’d like is for fq_codel (or even something as sophisticated as cake) to be implemented in the *actual* bottleneck queues, so that artificially taking control of the bottleneck isn’t necessary.

> I'll state up front that I'm not entirely clear on the distinction between shapers, qdisc's, IFBs, etc. But I'm groping around for a simple, clear recommendation for what we should tell people to do so they can:
> 	a) Make their router work very well, with minimal latency
> 	b) Spend their time more usefully than tweaking QoS/priority settings (for example, by actually playing the game that whose lag you're trying to minimize :-)

If they’ve got a router with the sqm-scripts installed, use those and follow the directions.  The implementation is a little messy, but it works and it keeps things simple for the user.

When cake arrives, the implementation will get simpler and more efficient.

 - Jonathan Morton

Re: [Cerowrt-devel] [Bloat] Questions about the use of HTB & fq_codel in simple.qos, simplest.qos

[Rich Brown]

[-- Attachment #1: Type: text/plain, Size: 2501 bytes --]

Hi Jonathan,

Thanks for the response - this is really helpful. As I said in my original note, I'm casting about for usable advice that we can offer to people today. I want it to be unarguably true, and I want to understand the nuances so that I don't get tripped up by Gotcha's. 

I'm currently focussed on OpenWrt, as that's a platform where it's easy to roll out fq_codel in current builds simply by downloading a couple packages. I'll work on a draft note with recommendations for OpenWrt and send it past the list for comments. Thanks again.

Rich


On Apr 9, 2015, at 6:02 PM, Jonathan Morton <chromatix99@gmail.com> wrote:

> 
>> On 10 Apr, 2015, at 00:35, Rich Brown <richb.hanover@gmail.com> wrote:
>> 
>> - Why do we provide an HTB-based shaper in simple.qos and simplest.qos?
>> - Do the shapers in these sqm-scripts actually limit bandwidth for various kinds of traffic? Might that not leave unused bandwidth?
>> - Or do they just shunt certain packets to higher or lower priority fq_codel tiers/bands/levels (terminology used in Dave's note below)?
>> - And if the latter, how does the "link" (I'm not sure of the proper term) know which of the tiers/bands/levels to dequeue next?
> 
> The short answer is: because cake isn’t out in the real world yet.  We’re working on it.
> 
> HTB and IFB as used in those scripts is a stopgap solution, to take control of the bottleneck queue so that fq_codel can work on it.  Cake includes a shaper which does the job more effectively and more efficiently.
> 
> Ultimately, what we’d like is for fq_codel (or even something as sophisticated as cake) to be implemented in the *actual* bottleneck queues, so that artificially taking control of the bottleneck isn’t necessary.
> 
>> I'll state up front that I'm not entirely clear on the distinction between shapers, qdisc's, IFBs, etc. But I'm groping around for a simple, clear recommendation for what we should tell people to do so they can:
>> 	a) Make their router work very well, with minimal latency
>> 	b) Spend their time more usefully than tweaking QoS/priority settings (for example, by actually playing the game that whose lag you're trying to minimize :-)
> 
> If they’ve got a router with the sqm-scripts installed, use those and follow the directions.  The implementation is a little messy, but it works and it keeps things simple for the user.
> 
> When cake arrives, the implementation will get simpler and more efficient.
> 
> - Jonathan Morton
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]