"I noticed FQ Queue depth that is much less than the WRED. I guess that this is not good. As I expect that the FQ overrides the WRED config."
Laugh, depends how you define "good". It's not so much FQ overrides WRED, just the FQ and WRED thresholds, in your posted stats don't overlap. I.e. WRED, in this case, should never see queues large enough to react.
"Also, I do not understand why FQ and WRED may not be enabled together."
They can be used together, although I cannot think of a good reason to do so. Using FQ and FRED together, might be useful, though, but I don't recall any Cisco platform supporting both of those on the same platform.
"Also, I do not understand why FQ and WRED may not be enabled together.
Why wouldn't you?"
For starters, FQ drops per flow while WRED drops against, logically, a single FIFO queue. I.e. doesn't make much sense to me, unless, perhaps, you using WRED more as a WTD method or you really believe you need to drop (some?) AFx3 before AFx2 before AFx1, which you may, but with overlap?
"If I mark traffic with AF11, 12 or 13. Will FQ create three queues?"
No, FQ queues are per flow, i.e. same source/dest. addresses and port. ToS tag not considered. (Which is again, a possible case, as noted in answer to your prior question, to use WRED to drop some less important flows, in the same FQ class, before other flow, in the same FQ class.)
"And with a default queue limit? In some cases its half of the default depth (64)."
FQ has it's own ways of determining its default number of FQ queues and their depths. Some platforms will allows you to adjust FQ queue depths, but I don't recall any that support determining number of FQ queues.
"If you have a suggestion for good books/video, I would appreciate it."
Sorry, I have not found any that I really consider "good". IMO, QoS isn't really too complex, but to understand it, and use it well, you need a broad knowledge base. Most QoS material doesn't get into any queuing theory, or delve very deeply in something like TCP "goodput". Or, I don't recall any that touch upon a very similar (at least to me) problem set, which is how a resource like CPU is managed. Lastly, much material doesn't take into account the impact of other changes, like how recent TCP stacks do much more than monitor drops for flow (rate) control.
As an aside, many, I believe, don't appreciate how useful "good" QoS can be.
Years ago, I contracted with a fairly large European company that had a world wide footprint. I did a lot of work developing QoS for the Americas (about 100 locations).
The WAN lead believed QoS was just "voodoo" until the day one of the main WAN routers, at the America's HQ, rebooted itself, overnight, and somehow dropped all its QoS settings.
That morning, the WAN lead said his phone was lit like a Christmas tree, with complaints of "what's wrong with the network".
He discovered the one WAN router missing its QoS configuration, reapplied it, and the complaints stopped. Laugh, a new believer of how effective QoS can be.
Or, a couple of times a year, the company would have all the word wide network leads meet, in one of the regions. One time when they were meeting in the US, I was invited to attend. The EMEA and Asia/Pac leads were complaining that no matter how often they kept buying more and more bandwidth (with the corresponding expense), all they continued to get were complaints the network was still slow. Cough, I mentioned during the last several years the Americas have upgraded very few WAN link's bandwidth, and our user base isn't complaining? Did you know, we, the Americas, use QoS? (Alas, our European HQ engineers, also thought QoS was just worthless "voodoo". [A couple of years later, they finally decided QoS might be worthwhile, but, of course, no point in studying what we've been doing for the last five years.])
In any case, don't get too excited about the approach many QoS books, including Cisco's, suggest.
