- 153 -
In the fourth profile mode, all queues are served using a WFQ service discipline.
5.15.1.3 Delay Bound
In the absence of a sophisticated QoS server and signaling protocol, the Switch may not know the mix
of incoming traffic ahead of time. To cope with this uncertainty, the delay assurance algorithm
dynamically adjusts its scheduling and dropping criteria, guided by the queue occupancies and the due
dates of their head-of-line (HOL) frames. As a result, we assure latency bounds for all admitted frames
with high confidence, even in the presence of system-wide congestion. The algorithm identifies
misbehaving classes and intelligently discards frames at no detriment to well-behaved classes. The
algorithm also differentiates between high-drop and low-drop traffic with a weighted random early drop
(WRED) approach. Random early dropping prevents congestion by randomly dropping a percentage of
high-drop frames even before the Switch’s buffers are completely full, while still largely sparing
low-drop frames. This allows high-drop frames to be discarded early, as a sacrifice for future low-drop
frames. Finally, the delay bound algorithm also achieves bandwidth partitioning among classes.
5.15.1.4 Strict Priority and Best Effort
When strict priority is part of the scheduling algorithm, if a queue has even one frame to transmit, it
goes first. Two of our four QoS configurations include strict priority queues. The goal is for strict
priority classes to be used for IETF expedited forwarding (EF), where performance guarantees are
required. As we have indicated, it is important that strict priority traffic be either policed or implicitly
bounded, so as to keep from harming other traffic classes.
When best effort is part of the scheduling algorithm, a queue only receives bandwidth when none of the
other classes have any traffic to offer. Two of four QoS profile modes include best effort queues. The
goal is for best effort classes to be used for non-essential traffic, because we provide no assurances
about best effort performance. However, in a typical network setting, much best effort traffic will indeed
be transmitted, and with an adequate degree of expediency.
Because we do not provide any delay assurances for best effort traffic, we do not enforce latency by
dropping best effort traffic. Furthermore, because we assume that strict priority traffic is carefully
controlled before entering the Switch, we do not enforce a fair bandwidth partition by dropping strict
priority traffic. To summarize, dropping to enforce bandwidth or delay does not apply to strict priority or
best effort queues. The Switch only drop frames from best effort and strict priority queues when global
buffer resources become scarce.