Estimating Shared Congestion Among Internet Paths

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, istoica_at_EECS.Berkeley.EDU

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

N2
N1
N7
N3
N5
N6
N4
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 gt 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

Sender 1
CBR Flow 1
PoC
Sender 2
CBR Flow 2
PoC
Time
0
6
Determine Synclag

• Assuming UDP-based CBR probe flows construct 2
  sequences of 1s(drops) and 0s
• Synclag is loosely bounded by 2RTTmax
• 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

Burst of Flow 1
Flow 1
Synclag-shifted times
b
Flow 2
Burst of Flow 2
Packet Drop
Transmitted Packet
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

Burst of Flow 1
Synclag-shifted times
Flow 1
Flow 2
Packet Drop
Burst of Flow 2
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

• 80 of the estimates gt 0.8

4-II topology
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/(d1d2d3d4)
• Upper bound (d2d3d4)/(d1d2d3d4)

N1
d1
R1
d2
d4
S1
d3
M1
M2
S2
R2
N2
12
4-YV Topology (UDP)

• 80 paths show at least 0.8 times actual value
• Better way to verify the accuracy?

4-YV topology
13
2-I Topology(TCP) Base Case

• TCP 80-0.6 bursty sending and fewer drops?
• How to improve the performance of TCP-based
  estimation?

2-I topology
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?