Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
I need some time to digest all of this. However, from what you indicated so far, it really seems that a configured shaper indeed in some way creates its own queues in addition to the queues managed by the current queueing strategy of the interface.Let's not talk about child policies or nested policy-maps for now, as that hugely complicates things. Let's take the most simple MQC config (I guess talking about Legacy QoS CLI is largely irrelevant), which is, say:
policy-map Example
class class-default
no fair-queue
shape average 100000
This config places everything in a FIFO queue and shapes it subsequently. Now:
- When does the shaper's WFQ take place: before or after the FIFO? In other words, is the shaper's queue placed before or after the configured queueing policy?
- Why was the WFQ chosen? Would it not be simpler and equally effective to use a simpler FIFO-style queueing for each original shaped queue? Is the WFQ not going to interfere with the configured queueing policy, resulting in possible priority inversions and other ill-behaved scenarios?
- Why is there actually a separate queueing mechanism in effect with shaping? What would be incorrect with an implementation where no additional queues would be created, just the dequeueing of existing queues would be delayed accordingly?
Best regards,
Peter
Ok, I see your policy with "no FQ" in class-default should set the class to use FIFO, but I believe the shaper within the class will maintain is own queue(s) for traffic it's shaped (which I believe uses WFQ [or FQ]).
Then the question is, if this is true, is there any FIFO queue for the class (which "overflows" into the shaper) or does the shaper queue(s) totally replace the class FIFO queue? I believe the latter.
Why was WFQ used? Only Cisco could answer that, although I agree a FIFO queue would have been simplier. My guess would be since they are using same code base for any shaper (Edison's reference: "Differences Between Shaping Mechanisms"), and since shaping has been around a while, might have decided shaped traffic should be WFQ just like the default for serial T1/E1 interfaces.
On most platforms, something like this GTS:
interface x
trafffc-shape rate average 100000
will use WFQ/FQ even on interfaces with FQ disabled.
Recently, I've been using this command on a FastEthernet interface without FQ enabled. (This in lieu of a CBWFQ policy - because of a possible bug - have a TAC case open on it - but that a different story.) When there's congestion with multiple flows, you can easily see them with the show traffic-shape queue command.
Regarding you questions about ". . . possible priority inversions and other ill-behaved scenarios?" If a queue originally used FIFO and the shaper does WFQ/FQ, it's possible individual packets from different flows will arrive in different sequence from their global "FIFO" ingress, but so what? If some flows have issues with this, then likely global FIFO egress should not have been used to begin with. (Again, to be clear, individual flow sequence will be preserved.)
Personally, the biggest issue I've had with shapers using their own WFQ, is that you can't normally set number of queues, individual queue depths and/or aggregate queue depth. I've also think I've may have had issues with multiple queues at different levels of a hierarchy, because of unexpected delay/jitter issues.
For example of the latter,
policy-map parent
class class-default
shape average 10000000
service-policy child
policy-map child
class voip
priority percent 30
I wonder whether when the parent's shaper determines packet need to be queued or dequeued, whether there's an intermediate queue(s) other than the child's. If so, would it impact the voip class's actual performance? I.e. are all shaped packets immediately pushed to the child policy, or do they first need to overflow from the parent's shaper's queue(s)? Additionally if there are parent shaper queues, do dequeued child voip packet now are only scheduled "fairly" with other parent shaped queued traffic?
I don't know the answer. Further, it might be slightly different between interfaces, platforms and/or IOS versions.
