The ONL Tutorial

Tutorial >> Filters, Queues and Bandwidth TOC

Mapping Flows to a Single Queue

Earlier, we used a General Match (GM) filter at an ingress port to map flows to VOQs and therefore forward packets to an egress port that was different than specified by the Route Table. This page shows how we can give special treatment to some flows at an egress port through the use of GM filters. This can effect the scheduling of the packets since queues in an egress port are scheduled by a weighted DRR (Deficit Round Robin) scheduler.


Fig. 1. Mapping All Flows to Queue 300.

Fig. 1 shows the port table at egress port 2.6 obtained by selecting Port 2.6 => Egress Filters in the main RLI window; i.e., it shows the egress side Flow Table (EM Filters) and Filter Table (GM Filters). The GM Filter Table was defined by selecting Edit => Add General Match Filter in the Egress Filters panel for the three filters.

The three filters at egress port 2.6 match packets going to any destination (0.0.0.0/0) in NSP 1 from n2p2, n2p3 and n2p4 respectively. Note that the port and protocol fields in all three filters are wild-carded so that they don't care about these header fields. All three filters map their matching packets to QID 300, one of the reserved flow QIDs (256-439). The priority has been set to 50 for all three filters to give them higher priority than the Route Table. Our remaining task is to define the queueing characteristics of queue 300.

Fig. 1 also shows the Queue Table obtained by selecting Tables => Queue Table and then adding an entry for QID 300 by entering Edit => Add Egress Queue in the Port 6 Queues panel. We have accepted the default threshold value (32,000 bytes) and quantum value (2,048) for now. Since the 64 datagram queues and reserved queue 300 all have a quantum of 2048, they will all get an equal share of the link bandwidth. We could give a greater share of the bandwidth to the packets matching the GM filters by increasing the quantum field for queue 300. We enter File => Commit in the main RLI window to install the new parameters.


Fig. 2. Monitoring Queue 300 at Egress Port 2.6.

Fig. 2 shows how to monitor queue 300 at egress port 2.6 to demonstrate that queueing is occuring. We select Port 6 => Egress => Qlength in the main RLI window, and fill out the Add Parameter dialogue box to monitor queue 300 every 1 second.


Fig. 3. Incremental Bandwidth and Length of Queue 300.

Fig. 3 shows both the incremental bw and the Queue Lengths charts aligned to show the correspondence between the traffic and queue length. The traffic chart is still showing the traffic volume through VOQ 6 at ingress ports 2.2, 2.3 and 2.4 and through VOQs 2, 3 and 4 at ingress port 1.7 when the outgoing link at port 2.6 has a capacity of 300 Mbps. At T = 1,541, queue 300 develops a backlog since the traffic coming into egress port 2.6 is 500 Mbps or 200 Mbps over the link capacity. This backlog remains until T = 1,573 when only the one 250 Mbps traffic source from n2p4 is still transmitting. Note also that the peak queue length is near 32,000 bytes, the threshold value of queue 300.

A Larger Threshold for Queue 300


Fig. 4. Queue 300 With Larger Threshold.

Fig. 4 shows that we have now increased the threshold to 1,000,000 bytes allowing a greater maximum queue backlog before discarding packets.


Fig. 5. Incremental Bandwidth and Length of Queue 300 (Larger Threshold).

As expected, Fig. 5 shows that queue 300 at egress port 2.6 now has a peak queue backlog of 1,000,000 bytes instead of 32,000 bytes.

Packet Drops


Fig. 6. Monitoring Packet Drops at Egress Port 2.6.

We can verify that the threshold for queue 300 is in fact forcing packet drops by monitoring the packet drops at egress port 2.6. Fig. 6 shows how to set up this monitoring by selecting Port 2.6 => Egress => FPX General Counter and electing to watch FPX Counter 66 (see FPX Counters for other drop counters).


Fig. 7. Packet Discards at Egress Port 6.

Fig. 7 shows that indeed egress port 2.6 is dropping around 17,000 packets every 3 seconds when two flows are competing for the egress link, and around 39,000 packets every 3 seconds when all three flows are competing for the same link.

A rough calculation shows that the Discards chart above shows the correct behavior. When there are two 250 Mbps flows (beginning around T = 2,770), the aggregate input rate to port 2.6 is 500 Mbps or 200 Mbps over the 300 Mbps egress link rate; that is, the +2.3 to 2.6 plot is around 500 Mbps, and the +1.7 to 1.3 plot is around 300 Mbps. For 1,500 byte (12,000 bit) packets, 200 Mbps translates into about 16,700 pps (packets per second). This compares well to the 17,000 discards in the Discards chart. When there are three 250 Mbps flows, the aggregate input rate to port 2.6 is 750 Mbps or 450 Mbps over the 300 Mbps output link rate. Since this discard rate of 450 Mbps is about 2.25 higher than the 200 Mbps drop rate for two flows, we expect the number of discards to be also about 2.25 times 16,700 pps or 37,575 pps. This compares well to the 38,000 discards in the Discards chart.


 Revised:  Mon, July 31, 2006 

  
  

Tutorial >> Filters, Queues and Bandwidth TOC