Traffic isolation based on WRR (Cat 6500)

Traffic isolation capabilities with variable number of classes

Goal: to verify the capability of WRR to deliver traffic isolation between different precedence classes in presence of TCP traffic. In this case we use TCP traffic and we assign a weight so that no packet loss is guaranteed, as seen in Test 4. This implies that we use a real weight instead of the theoretical weight, in other words, we over-estimate the weight assigned to a given class.
Equipment:

Cat6500 hardware configuration
pool of Solaris 2.7 workstations (sunlab2, 3 and 4)
receiving machine of reference (non-background) traffic: dell03.cnaf.infn.it

Network topology:

Testbed topology
Policing/marking/scheduling logical topology

Router configuration:

2 classes: precedence 1 configuration
3 classes: precedence 1 and 2 configuration
4 classes: precedence 1, 2 and 3 configuration
The threshold configuration which determines the bandwidth separation between two subqueues of a given queue. In this case the configuration is the default one.
WRR 2 classes configuration
WRR 3 classes configuration
WRR 4 classes configuration
Traffic profile:

UDP background traffic: two solaris workstations are used to inject background UDP traffic, this to produce congestion on the output interface of the Cat6500 connecting the switch to router 12000.
Script
Reference TCP streams:

Test A (2 classes):
a precedence 1 stream (marked by Cat6500) is injected by sunlab4. This stream is policed at a CIR equal to 90 Mbps. Normal and exceed bursts are set to a value which permits the TCP stream to get full bandwidth (in this case the burst size needed is 4.5 Mby).
Script
Test B (3 classes): prec 1 and prec 2 traffic is policed at 60 Mbps and 30 Mbps respectively
Script
Test C (4 classes): prec 1, 2 and 3 traffic is policed at 30, 40 and 20 Mbps respectively
Script

Test parameters:

number of streams sourced by sunlab4
policing CIR rate (and normal=maximum burst size)
number of policing/marking instances
number of WRR queues

Summary:

Classes corresponding to prec 1, 2 and 3 are è effectively protected from background traffic congestio and streams get the target rate as expected. This is due to the overestimation applied when assigning the weigth to prec 1, prec2 and prec3. However, we do see some parcentage of packet loss of queues correspnding to prec 1 and 2 under some configuration, which means that the overestimation which should be applied to TCP should be even larger than for UDP traffic. This because the input TCP traffic is extremely bursty.
Theoretical weights applied to WRR queues and TCP traffic are not capable of providing perfect traffic isolation in case of extremely bursty TCP sources.

Comments:

Test A (2 classes, prec 0 and prec 1): the following output shows the prec 1 TCP throughput as reported by the receiver for two consecutive probes:
[ 6] 740.0-750.0 sec 102 MBytes 85.8 Mbits/sec [ 6] 750.0-760.0 sec 107 MBytes 89.5 Mbits/sec
Packet loss statistics on interface GiagaEThernet 3/16, per queue:
Packets dropped on Transmit: BPDU packets: 0 queue thresh dropped [cos-map] --------------------------------------------------- 1 1 37262606 [0 2 3 4 5 6 7 ] // prec 0 queue 1 2 0 [] 2 1 593 [1 ] // non-zero pack loss on prec 1 queue 2 2 0* [] 3 1 0* [] // priority queue (not configured) * - shared transmit counter

Test B (prec0, prec 1 and prec 2): Throughput statistics:
[ 6] 240.0-250.0 sec 35.0 MBytes 29.4 Mbits/sec // prec 2 [ 6] 240.0-250.0 sec 69.4 MBytes 58.3 Mbits/sec // prec 1 [ 6] 250.0-260.0 sec 34.8 MBytes 29.2 Mbits/sec // prec 2 [ 6] 250.0-260.0 sec 69.1 MBytes 58.0 Mbits/sec // prec 1
Per-queue packet loss statistics on interface GigaEthernet 3/16:
Packets dropped on Transmit: BPDU packets: 0 queue thresh dropped [cos-map] --------------------------------------------------- 1 1 14392269 [0 3 4 5 6 7 ] // prec 0, congested queue 1 2 0 [] 2 1 464 [1 ] // prec 1, non-zero packet loss 2 2 107* [2 ] // prec 2, non-zero packet loss 3 1 107* [] // priority queue (not used) * - shared transmit counter

Test C (prec1, prec2, prec3): throughout statistics:
[ 6] 160.2-170.0 sec 44.0 MBytes 37.6 Mbits/sec // prec 2 [ 6] 160.1-170.0 sec 34.9 MBytes 29.5 Mbits/sec // prec 1 [ 6] 160.0-170.0 sec 23.1 MBytes 19.4 Mbits/sec // prec 3 [ 6] 170.0-180.0 sec 46.6 MBytes 39.1 Mbits/sec // prec 2 [ 6] 170.0-180.0 sec 35.7 MBytes 30.0 Mbits/sec // prec 1 [ 6] 170.0-180.0 sec 22.7 MBytes 19.0 Mbits/sec // prec 3
Pakcet loss statistics on interface GigaEthernet 3/16:
Packets dropped on Transmit: BPDU packets: 0 queue thresh dropped [cos-map] --------------------------------------------------- 1 1 431842 [0 4 5 6 7 ] // prec 0, background 1 2 0 [3 ] // prec 3, no pack loss! 2 1 1 [1 ] // prec 1, negligible pack loss! 2 2 0* [2 ] // prec 2, no pack loss! 3 1 0* [] * - shared transmit counter
It is interesting to see that in this test by reducing the amount of offered load on queue 2 from 90 Mbps (test A and B) to 70 Mbps, packet loss disappears. This means that for this amount of offered traffic, the overestimation degree is suffiecient to remove completely the phenomenon of packet loss. This indicates that with TCP bursty traffic the overestimation degree should be larger than with UDP, as expected.

T.Ferrari and A.Mangiarotti, March 25 2002