20021001LBEonGARR

Less than Best Effort (LBE) performance on a STM-16 link : 

Less than Best Effort (LBE) performance on a STM-16 link Experimental results Serena Alessandrini INFN – CNAF serena.alessandrini@cnaf.infn.it 3rd October 2002

Summary: 

Summary LBE philosophy Goals of the tests Network topology LBE configuration Baseline performance LBE experimental results Conclusions

LBE philosophy: 

LBE philosophy The philosophy behind LBE is that a very small percentage of network capacity is allocated to LBE so that under congestion Best Effort (BE) traffic and any higher-priority traffic class is protected from LBE traffic. In this way when LBE congestion occurs, the LBE traffic is penalized and congestion is transparent to BE traffic.

Goals of the tests: 

Goals of the tests To configure and test LBE service on layer 3 switches providing connectivity to WAN networks. Catalyst 6500 Weighted Round Robin (WRR) as scheduler algorithm To check if Catalyst does not alter the LBE DSCP of the forwarded packets To verify the performance of BE and LBE services under network congestion for TCP and UDP streams Monitored performance metrics: Throughput Packet loss Minimum, average and maximum Round-Trip-Time (RTT)

Network topology (I): 

One of the attractive features of LBE is that it can be deployed incrementally on a network path, with other routers only needing to offer DSCP transparency. Therefore LBE can be implemented only on the congested output interface Our network topology has allowed us to study the LBE service when there is interconnectivity between LBE and BE networks: Network topology (I) LBE CNAF LBE INFN Rome BE GARR

Network topology (II): 

Network topology (II) TX TX TX Linux host v 2.4.18 Linux host v 2.4.17 RX RX STM-16 link

LBE configuration: 

LBE configuration On Catalyst 6500: interface GigabitEthernet3/1 description to bo12kgp (GARR-G) no ip address speed nonegotiate wrr-queue bandwidth 99 1       99% of capacity allocated to queue 1 and 1% to queue 2 wrr-queue cos-map 1 1 0                       // prec 0 traffic (BE) goes into queue 1,1 wrr-queue cos-map 2 1 1 2 3 4 5 6 7    // prec 1 traffic (LBE) goes into queue 2,1 switchport On workstation: we have injected LBE traffic using IPERF, we have to specify the TOS field in the command line iperf -c 192.168.101.3 -p 60011 -u -b 100M -S 0x20 (hexadecimal) -t 60 -i 10

Baseline performance: 

Baseline performance According to the bandwidth-delay product, the minimum send/receive socket buffer size has to be: Bottleneck bandwidth * RTT = 1Gbps * 4.55 msec ~= 570 MBytes Baseline TCP and UDP performance from Bologna to Rome: UDP : Maximum TX/RX rate = 956 / 540 Mbps TCP : Maximum rate = 560 Mbps We have presumed that the bottleneck is at the end-nodes and not the network.

LBE experimental results: 

LBE experimental results Test 1: 1 UDP and/or 1 TCP BE streams and UDP LBE traffic TCP and UDP BE traffic is protected from packet loss in case of LBE congestion NO packet loss occurs both for TCP and UDP BE traffic

LBE experimental results: 

Test 2: multiple TCP BE streams (Constant UDP LBE traffic load = 980 Mbps, 4 UDP LBE streams) NO packet loss even in case of multiple BE TCP streams packet loss experiences only by LBE UDP streams LBE experimental results

LBE experimental results: 

Test 3: BE and LBE performance for different LBE traffic loads (with 2 TCP BE streams) NO packet loss occurs for BE traffic NO throughput loss occurs for BE TCP traffic under different level of LBE network congestion An increase in UDP LBE bandwidth involves proportionally in packet loss increment: from 26.9% to 69.39% LBE experimental results

LBE experimental results: 

Test 4: 1 TCP BE and 1 TCP LBE concurrent streams with different background UDP LBE traffic LBE experimental results TCP LBE max possible rate is around 850 Kbps !!! 179 dropped packets by TCP BE traffic !!! some dropped packets for TCP BE traffic counted at the Catalyst output interface!!! With two concurrent TCP streams, 1BE and 1LBE, the LBE stream is the most penalized both in case of light and high congestion This problem requires further investigations. It could be related to the burstiness introduced by TCP LBE streams injected by hosts with high-speed interfaces (GigaEthernet).

LBE experimental results: 

For any test with LBE congestion we have monitored the RTT (through the ping command) for both BE and LBE traffic. We have calculated the difference between the average RTT measured under LBE congestion and the average baseline RTT (obtained without congestion and without LBE traffic in background): RTT_diff = avg RTT_Load – avg RTT_baseline LBE experimental results The avg RTT_diff : For BE traffic is around 0.4 msec (maximum = 3.27 msec) for LBE traffic is around 0.85 msec (maximum = 4.57 msec)

Conclusions: 

Conclusions With different congestion levels and different traffic profiles, the correctness of  the configuration of WRR and LBE service is proved BE traffic is generally protected from packet loss under LBE network congestion. no significant increase in both BE and LBE  RTT during congestion Best-Effort performance (UDP receive rate and TCP throughput) protected from LBE congestion

Conclusions: 

some Best-Effort performance loss in case of high LBE load and TCP LBE traffic: the performance loss depends on the overall amount of LBE traffic injected. The goodness of this kind of test topology configuration is proved Conclusions