Accuracy of Link Capacity Estimates using Passive and Active Approaches with CapProbe Rohit Kapoor, Ling-Jyh Chen, M. Y. Sanadidi, Mario Gerla Dept. of Computer Science, University of California at Los Angeles

Packet pair Techniques Ideal Case: June 2004 ISCC 2004

Packet Pair and Train Dispersion June 2004 ISCC 2004

Packet Pairs Bandwidth Histogram Packet-pair estimates: multimodality with cross traffic: Light load conditions(20%) (b) heavy load conditions(80%) SCDR is caused by dispersion expansion PNCM is caused by dispersion compression June 2004 ISCC 2004

Packet Train Bandwidth Histogram As trains get longer, get “Asymptotic Dispersion Rate” or ADR ADR is not equal to Residual (available) Capacity We found and proved a physical interpretation (to be published): ADR is the flow share, when merges are proportional to arrival rates at each link Dovrolis’ results obtained for non-responsive cross traffic flows June 2004 ISCC 2004

CapProbe: The Main Idea Observation: Both expansion and compression of dispersion involve queuing due to cross traffic: Dispersion expansion => second packet queued more Dispersion compression => first packet queued more Packet pair with minimal end-to-end delay sum, is likely to be dispersed corresponding to narrow link capacity Looking for packet pair with minimal delay sum is inexpensive CapProbe appears accurate in most of our experiments, simulations and measurements CapProbe fails under heavy (~>75%) utilization by non-responsive (UDP) traffic June 2004 ISCC 2004

CapProbe Ideal Case: no cross traffic Real Case: dispersion may be compressed or expanded by the cross traffic Under-estimation due to expansion Over-estimation due to compression June 2004 ISCC 2004

CapProbe Both expansion and compression are due to queuing A Packet-Pair sample with Minimal Delay Sum can be used for Capacity Estimation 4 mbps narrow link, TCP cross traffic, June 2004 ISCC 2004

Wireless Measurements Bad channel retransmission larger dispersions lower estimated capacity Experiment No. Capacity Estimated by CapProbe (kbps) Capacity Estimated by Strongest Mode (kbps) 1 5526.68 4955.02 2 5364.46 462.8 3 5522.26 4631.76 4 5369.15 5046.62 5 5409.85 449.73 Results for Bluetooth-interfered 802.11b, TCP cross-traffic June 2004 ISCC 2004

Comparison to Earlier Tools UCLA-2 UCLA-3 UA NTNU Time Capacity Cap Probe 0’03 5.5 0’01 96 0’02 98 0’07 97 5.6 0’04 79 0’17 83 0’22 0’09 99 95 Pathrate 6’10 0’16 5’19 86 0’29 6’14 5.4 5’20 88 0’25 6’5 5.7 5’18 133 6.8 0’26 6’20 5.8 132 Pathchar 21’12 4.0 22’49 18 3 hr 34 21’21 22’53 31 35 21’45 22’48 32 20’43 3.9 27’41 21.18 29’47 30 June 2004 ISCC 2004

Implementation Issues User vs. Kernel Mode generation of probes and measurements End systems processing speed Probe packet size June 2004 ISCC 2004

Testbed User mode and kernel mode implementations Slow system: Pentium II 500MHz CPU; Fast system: Pentium IV 1.8 GHz CPU Probe packet sizes varied from 500 Bytes to 5K Bytes June 2004 ISCC 2004

Measurement Experiments on Internet Unit: Mbps PKSize (bytes) YAHOO NTNU WLSH 1 2 3 User mode 1 (slow machine) 500 571.4 285.7 452.8 133.3 67.8 1.45 1.41 1000 421.1 61.5 160.0 381.0 216.2 1.51 1.47 1.5 3000 338.0 237.6 79.2 827.6 444.4 1.48 5000 231.2 156.2 239.5 209.4 210.5 243.9 User mode 2 (fast machine) 64.5 148.1 400 54.1 56.3 40.8 1.26 1.28 156.9 150.9 160 82.5 95.2 2.17 1.50 103.4 112.1 117.0 111.6 123.7 93.1 1.49 1.46 99.5 100.8 102.6 89.9 102.3 107.8 Kernel mode 9.2 10.2 89.4 90.9 74.0 1.39 1.42 69.6 79.3 78.6 93.0 85.1 91.6 1.44 92.0 86.3 90.0 96.2 98.4 95.6 95.0 86.8 91.3 96.4 Narrow Link Capacity 100 NTNU: National Taiwan Normal University; WLSH: Wuling Senior High School, Taiwan, Ling Jyh taught computer use in that school !! NTNU connects to UCLA with 100Mbps bottleneck link; WLSH connects to UCLA with 1.5Mbps bottleneck link (T1) User Mode 1 user level process, no kernel implementation, runs ICMP packets (modified Ping program) User Mode 1 produces inaccurate time stamps and thus wrong dispersion measurements, except for low speed link (1.5Mbps) User Mode 2 similar to above, except fast machine Kernel mode: in Linux Kernel 2.4.22, uses ICMP still like above June 2004 ISCC 2004

Discussion For high speed networks, either a high time resolution machine or a large probing packet size is needed for accuracy Fine resolution may not be possible in user mode A large packet size increases the chances expansion of dispersion Required time resolution T = pksize / C: Packet Size Narrow Link Capacity 100 Mbps 10 Mbps 1 Mbps 500 bytes 0.04 ms 0.4 ms 4 ms 1000 bytes 0.08 ms 0.8 ms 8 ms 3000 bytes 0.24 ms 2.4 ms 24 ms 5000 bytes 0.40 ms 40 ms .04 instead of .05 because 500 bytes!!! Required time resolution for accurate estimation June 2004 ISCC 2004

Passive CapProbe CapProbe is an active approach and using ICMP packets. Passive approach is less intrusive, thus more scalable Passive CapProbing within TCP requires back to back TCP packet transmission Simulation => 15~20% of TCP data packets are sent back-to-back June 2004 ISCC 2004

Simulation The network topology used in our simulations consists of a six-hop path with capacities {10, 7.5, 5.5, 4, 6 and 8} Mbps. DelACK is disabled in the simulation. Different cross traffic are used, with packet size 1000 bytes and 200 bytes. June 2004 ISCC 2004

Passive CapProbe Active CapProbe June 2004 ISCC 2004 Comparing Passive and Active Cross traffic indicated in boxes Capacity is 4 Mbps As cross traffic load increase, more inaccuracy in passive approach CBR cross traffic is also a problem in active approach at high load June 2004 ISCC 2004

Conclusion Either a high time resolution machine or a large probing packet size is necessary for accurate capacity estimation Passive CapProbing within TCP is feasible, minor TCP sender modification helps a lot (future work) Other Future work: Experiments at speeds higher than 100 Mbps Passive CapProbing in TFRC, other applications Use of capacity estimates in TCPW and overlays construction June 2004 ISCC 2004

T h a n k s Improving Wireless Link Throughput via Interleaved FEC June 2004 ISCC 2004