1 Estimating Shared Congestion Among Internet Paths Weidong Cui, Sridhar Machiraju Randy H. Katz, Ion Stoica Electrical Engineering and Computer Science Department University of California, Berkeley {wdc, machi, randy, Sahara Retreat Summer 2003

2 Motivation Applications using path diversity for better performance –multimedia streaming - independent losses –parallel downloads – better throughput –overlay routing networks - backup paths for robustness Traceroute will not work –ICMP may be filtered –False positives –Conservative N1 N2 N3 N4 N5 N6 N7 Congested Links

3 Problem Formulation Problem: Given two paths in the Internet, estimate the fraction of packet drops at shared points of congestion (PoCs) using probe flows along the paths Limitations of existing solutions –Work only with Y and Inverted Y topologies –Return a “Yes/No” decision on shared PoCs

4 Our Approach Assumptions –Most routers still use drop-tail queuing discipline –Most traffic is TCP-based Basic idea –Count correlated (simultaneous) packet drops of two probe flows (UDP or TCP). Droptail Queues +TCP => Bursty Drops Packets traversing a PoC around the same time are likely to be dropped or not dropped together. –Why not delay/jitter? Algorithm –Determine synchronization lag –Calculate the fraction of correlated packet drops –“Inflate” the fraction using delay jitter correlation

5 Synchronization Lag We need to know which two packets traverse the queue around the same time No knowledge on times of traversal at shared PoCs (if any) –Senders may not be synchronized –The delay from senders to a shared PoC is unknown 0 CBR Flow 1 CBR Flow 2 Time Sender 1 Sender 2 PoC 0 T 1 0 d1d1 2 0 Synchronization Lag = 3T d2+d Note: is bounded by RTT max /2

6 Determine Synclag Assuming UDP-based CBR probe flows: construct 2 sequences of 1s(drops) and 0s Synclag is loosely bounded by 2*RTT max For a given synclag, cross-correlation coefficient (CCC) of the 2 (synclag-shifted) sequences can be calculated Try various values of synclag and calculate CCCs Use the synclag that maximizes the CCC of (synclag-shifted) packet drop sequences

7 Correlate Bursty Packet Drops All packets during congested period at PoC may not be dropped Correlate bursts of packet drops and avoid false negatives Flow 1 Flow 2 Burst of Flow 1 Burst of Flow 2 Synclag-shifted times Packet Drop Transmitted Packet b

8 Correlate Bursts with Overlap Bursts at different PoCs may have small overlap Consider bursts with a minimum degree of overlap to prevent false positives Flow 1 Flow 2 Burst of Flow 1 Burst of Flow 2 Synclag-shifted times Packet Drop Transmitted Packet

9 Evaluation Methodology Challenges –Hard to verify our results because congestion information about links not available –Hard to simulate real network traffic in ns simulations Methodology –Create overlay topologies on Planetlab –Each overlay node records packet arrivals –Drops on “overlay links” can be inferred Probe flows: –UDP (active): CBR traffic –TCP (passive): UDP-Encapsulated Application: MPEG streaming over two paths Parameters –UDP probing rate = 100Hz –Burst interval = 15ms –Burst overlap = 50%

10 4-I and 4-II Topologies (UDP) 4-I topology 4-II topology 80% of the estimates > 0.8

11 Evaluation Metrics Cannot infer if drops are not shared –Drops between N1 and M1 can be at a shared PoC Bounds on fraction of drops at shared PoCs –Lower bound: d3/(d1+d2+d3+d4) –Upper bound: (d2+d3+d4)/(d1+d2+d3+d4) S1 S2 R1 R2 M1M2 d2 d3 d4 d1 N1 N2

12 4-YV Topology (UDP) 4-YV topology 80% paths show at least 0.8 times actual value Better way to verify the accuracy?

13 2-I Topology(TCP) – Base Case 2-I topology TCP ~ 80%-0.6; bursty sending and fewer drops? How to improve the performance of TCP-based estimation?

14 Conclusions Problem –Estimate the fraction of packet drops on shared PoCs Challenges –Synchronization lag –False positives –False negatives Results –Can estimate the actual fraction of shared drops within a factor of 0.8 in 80-90% UDP experiments –Can work with any general topology

15 Open Questions Better way to verify the accuracy of the estimated fraction? How to improve the performance of TCP-based estimation? How to work with RED? –Correlate delay? –Correlate packet loss probability? Applications exploiting our technique? –Media streaming? –Application level multicast? –Parallel downloads? –Backup path routing?