Well thank you @MHM Cisco World. That's very kind.
Actually, unlikely I'm the "best" in QoS, but having worked QoS extensively, in a good sized international WAN, I believe I figured out a few things, which don't seem to be well presented in typical QoS materials.
Also, actually, much of my (personal) underlying QoS "theory" is plagiarized, not from QoS materials, but from computer resource management, especially sharing CPU and/or disk drives. Is some ways, apps sharing bandwidth is like apps sharing CPU. Yes, often some apps are prioritized over other apps, but how do (more-or-less) equal priority apps share CPU?
Way, way back, FIFO was used for some CPU sharing, but you got very unpredictable, per particular app instance, results (much like "typical" FIFO sharing of network bandwidth even still used today).
For years now (decades actually), CPU sharing is often much more involved than simple FIFO and or simple PQ, yet, again, what's the default queuing for most interfaces, FIFO. Or, yea, we can PQ VoIP, but beyond that, we now have 12-class models, and/or optionally 3 priority drop levels, but if your "pipe" has more than 70% utilization, how do your users perceive network performance?
Something I don't recall posting on these forums, is where I would argue, for QoS, saying, when someone works with a 1 KB file across a network versus working with a 50 MB across the network, they expect the former to take less time than the latter. And, it does, assuming two users aren't doing both things concurrently. But, if two users are doing both things concurrently, sometimes the 50 MB user interaction will "crush" the 1 KB user interaction. This is the kind of situation QoS can preclude.
BTW, years ago, there were studies where predictability and/or consistency were very important to users using a system. I.e. a consistent 5 second response was better than a 1 second response most of the time, but with occasional 30 second responses. I.e. if you had to, you would artificially slow the 1 second response to 5 seconds so as to guarantee no 30 second responses.
I can see the logic of this, but personally, I would question why there are 30 second responses and work to mitigate them. To me, if most responses could still be 1 second, with an occasional 3 second response, I think that better than all responses being 5 seconds.
Laugh, but I also believe and say computer systems should wait on people, people should not wait on computer systems.
Something I believe I've posted before is, in the business where I had implemented QoS, the WAN lead considered QoS just voodoo. Well, until the day, one WAN core router rebooted itself over night, and dropped its QoS configuration. The WAN lead, later said, that morning when he came in, his telephone was lit like a Christmas tree, remote sites complaining, what's wrong with the network?
He discovered the WAN router that had rebooted, also discovered its missing QoS statements, reapplied them, and the telephone calls stopped! (BTW, this was before we were running VoIP or video conferencing apps - did add them a few years later, no big deal.)
I also believe I posted this before, this international company was split into 3 semi-autonomous regions. Our region (only one with QoS) didn't have remote users constantly complaining about network performance. Further, the two other regions, were constantly upgrading WAN bandwidths, which "surprisingly" (to them) didn't seem to stop the continuous network performance complaints within those two other regions.
I did try to convince the two other regions to try QoS, but they felt is wasn't needed, as (again) at that time we weren't supporting any real-time traffic like VoIP, and "we know" you only really need to consider QoS when supporting VoIP, etc.
(Oh, yea, and when we did start to support VoIP and video conferencing, those other two regions did implement QoS. Using what I worked up over 5 years? No, let's copy examples from Cisco [?], that should be what we need. [Cisco, at that time, I believe was still using their Olympic model. Well, LLQ/PQ for real-time traffic was good, although believe their users still complained about their other network app performance, but it wasn't any/much worse, so not really a problem.] They did allow our region to continue to use our own QoS policy.)
Sorry, just realized I'm on my QoS soapbox. Why stop now . . .
For years, "we need" FE, gig, 5gig, 10gig, 25gig, 40gig, 100gig, and ???, but do we need QoS?
"Well maybe for VoIP and/or video conferencing".
Oh, and if you do use QoS, here's our 12-class model where you provide 11% bandwidth for this class, and 2% bandwidth for that class, and use RED on this class beginning drops at 112 packets with 100% drops at 838 packets if in the 2nd drop probability class, but for this class . . . (Laugh, and I wonder why QoS is considered complex and/or voodoo.)
Anyway, possibly no surprise, but I believe QoS is very much underappreciated for what it can do (also much under supported by current technology).
