The packet precedence has no effect on the dropping scheme

WFQ uses these two parameters that affect the dropping of packets:

■ The congestive discard threshold (CDT) is used to start dropping packets of the most aggressive flow, even before the hold-queue limit is reached.

■ The hold-queue out limit (HQO) defines the maximum number of packets that can be in the WFQ system at any time.

There are two exceptions to the WFQ insertion and drop policy, as follows:

■ If the WFQ system is above the CDT limit, the packet is still enqueued if the per-flow queue is empty.

■ The dropping strategy is not directly influenced by IP precedence.

HQO is the maximum number of packets that the WFQ system can hold.

CDT is the threshold when WFQ starts dropping packets of the most aggressive flow.

N is the number of packets in the WFQ system when the N-th packet arrives.

HQO is the maximum number of packets that the WFQ system can hold.

CDT is the threshold when WFQ starts dropping packets of the most aggressive flow.

N is the number of packets in the WFQ system when the N-th packet arrives.

The figure illustrates the dropping scheme of WFQ. The process can be organized into these steps:

Step 13 Drop the new packet if the WFQ system is full (hold-queue limit reached) and the new packet has the worst finish time (the last in the entire system).

Step 14 Drop the packet with the worst finish time in the WFQ system if the system is full. Enqueue the new packet.

Step 15 When the WFQ system is above the CDT limit, a new packet is dropped if that packet is the last in the WFQ system, even though the WFQ system is still within the hold-queue limit.

Step 16 When the WFQ system is above the CDT limit, and if a new packet would not be the last in the WFQ system, the new packet can be enqueued and no other packet is dropped.

When the WFQ system is below both the HQO and the CDT limit, newly arriving packets are enqueued normally.

WFQ Scheduling

This topic describes how finish time is calculated based on weight and how it is used in the operation of WFQ.

Finish Time Calculation

The length of queues (for scheduling purposes) is not in packets but in the time it would take to transmit all the packets in the queue. The end result is that WFQ adapts to the number of active flows (queues) and allocates equal amounts of bandwidth to each flow (queue).

The side effect is that flows with small packets (usually interactive flows) get much better service because they do not need a lot of bandwidth. They need low delay, however, which they get because small packets have a low finish time.

The figure illustrates how two queues (queue A and queue B) are contesting for link bandwidth. For this example, assume that the time units are in ms and time T (value 0 is used in the figure) is the starting point.

Queue A receives packets in the following order and times:

■ Packet A1 arrives at time T + 0 ms and requires 100 ms to be transmitted.

■ Packet A2 arrives at time T + 60 ms (the input interface is obviously faster than the output interface because the arrival time of packet A2 is before the finish time of packet A1) and requires 20 ms to be transmitted.

■ Packet A3 arrives at time T + 70 ms (the input interface is obviously much faster than the output interface) and requires 10 ms to be transmitted.

Queue B receives packets in the following order and times:

■ Packet B1 arrives at time T + 50 ms and requires 300 ms to be transmitted.

■ Packet B2 arrives at time T + 100 ms and also requires 300 ms to be transmitted.

The finish times of packets in Queue A are as follows:

■ Packet A1 has a finish time which is the sum of the current time (because the queue was empty at the time of arrival) and the time it takes to transmit this packet (100 ms): FTA1 = 0 ms + 100 ms = 100 ms.

■ Packet A2 has a finish time which is the sum of the finish time of the last packet in queue A (packet A1) and the time it would take to transmit this packet (20 ms): FTA2 = 100 ms + 20 ms = 120 ms.

■ Packet A3 has a finish time which is the sum of the finish time of the last packet in queue A (packet A2) and the time it would take to transmit this packet (20 ms): FTA3 = 120 ms + 10 ms = 130 ms.

The finish times for the packets in queue B are as follows:

■ Packet B1 has a finish time which is the sum of the current time (because the queue was empty at the time of arrival) and the time it takes to transmit this packet (300 ms): FTm = 50 ms + 300 ms = 350 ms.

■ Packet B2 has a finish time which is the sum of the finish time of the last packet in queue B (packet B1) and the time it would take to transmit this packet (300ms): FTB2 = 350 ms + 300 ms = 650 ms.

The packets are scheduled into the hardware queue (or the TxQ) in the ascending order of finish times:

Note WFQ prevents reordering of packets within a single flow (conversation). Small packets are automatically preferred over large packets.

Wfq Weight Calculation

The figure introduces the weight into the finish time calculation. The time it takes to transmit the packet is divided by IP Precedence increased by one (to prevent division by zero).

The WFQ implementation in Cisco routers is optimized in these ways:

■ The real time it takes to transmit the packet is not relevant. The packet size can be used instead because it is proportional to the transmit time.

■ The packet size is not divided by IP precedence (division is a CPU-intensive operation). Instead, the size is multiplied by a fixed value (one multiplication value for each IP Precedence value).

Packets with IP Precedence one appear half the size they really are. The result is that these packets receive twice as much bandwidth as packets with IP Precedence zero.

Finish Time Calculation with Weights

• Finish time is adjusted based on IP precedence of the packet.

If Flow F Active, Then FT(Pk+1) = FT(Pk) + Size(Pk+1)/(IPPrec+1) Otherwise FT(P0) = Now + Size(P0)/(IPPrec+1)

• IOS implementation scales the finish time to allow integer arithmetic.

If Flow F Active, Then FT(Pk+1) = FT(Pk) + Size(Pk+1)*32384/(IPPrec+1) Otherwise FT(P0) = Now + Size(P0)*32384 /(IPPrec+1)

• RSVP packets and high-priority internal packets have special weights (4 and 128).

— QOS-U

The first formula in the figure is the first optimization in which the finish time is really the sum of packet sizes divided by an increased IP precedence value.

The second formula shows further optimization in which, instead of dividing, the packet size is multiplied by 32,384 / (IP Precedence + 1). A number for each different IP precedence value is stored in a table and therefore does not have to be calculated for each packet.

Packets belonging to RSVP flows and system packets have special low weights that guarantee them more bandwidth.

Note Cisco IOS versions before Release 12.0(5)T use a new formula in which the weight is calculated on this formula: Weight = 4096 / (IP Precedence +1).

IP Precedence

Weight

0

32384

1

16192

2

10794

3

8096

4

6476

5

5397

6

4626

7

4048

32 (virtual IP precedence)

128

1024 (virtual IP precedence)

4 (RSVP)

• RSVP packets and high-priority internal packets have special weights (4 and 128).

• Lower weight makes packets appear smaller (preferred).

• These numbers are subject to change.

The figure shows the mapping between IP precedence values and WFQ weights.

Note These figures are subject to change. Refer to the Cisco IOS documentation for the latest information on WFQ weights.

Was this article helpful?

0 0

Post a comment