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