View
33
Download
1
Category
Preview:
DESCRIPTION
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}@EECS.Berkeley.EDU. Short Course August 2003. Motivation. - PowerPoint PPT Presentation
Citation preview
1
Estimating Shared Congestion Among Internet
Paths
Weidong Cui, Sridhar MachirajuRandy H. Katz, Ion Stoica
Electrical Engineering and Computer Science DepartmentUniversity of California, Berkeley
{wdc, machi, randy, istoica}@EECS.Berkeley.EDU
Short Course August 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
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
4
Existing Techniques• Traceroute will not work
– Provides no congestion-related information – Will not work with ICMP filtering
• Limitations of existing solutions– Work only with Y and iY (Inverted Y)
topologies
– Return a “Yes/No” decision– Limited Evaluations
Shared routersand PoCs
5
Our Contributions• Path Independence Estimator (PIE)
– Topology-dependent (Y, iY, YiY, iYY)– Uses Stat. learning (EM) – Other parameters relatively insensitive
• A novel and extensive overlay-based measurement methodology to validate PIE
Shared routersand PoCs
YiY iYY
6
Assumptions and Solution Motivation
• Assumptions– Most routers use drop-tail queuing discipline– Most traffic is TCP-based
• Motivation for PIE– Droptail Queues +TCP => Bursty Drops– Packets traversing a PoC around the same
time are likely to be dropped or not dropped together
– Count simultaneous drops of the two probe flows
7
Challenges
• Determine times of traversal at shared PoCs based on sending/receiving times
• All packets during a bursty drop period may not be dropped; this could lead to false negatives
• Long bursts could lead to false positives
8
PIE: How It Works
• Use CBR UDP probe flows along the 2 paths
• Classify drops along each path into bursts
• Use the sending and receiving times and topology (Y, iY, iYY, YiY) to determine the times at which drops would have occurred at the PoCs
• Calculate the number of drops in simultaneous bursts
9
Classify drops into bursts• All packets during congested period at
PoC may not be dropped. Hence, use simultaneous bursts
• Use EM algorithm with Bayesian technique to determine burst interval b
Flow 1
Flow 2
Burst of Flow 1
Burst of Flow 2
Packet Drop
Transmitted Packetb
10
What are simultaneous bursts?
• To determine simultaneous bursts, we need to know the times of occurrence in terms of a common clock
• For iY topology,– Common clock is at sender– Time at shared PoC ~ sending time
• For Y topology, – Common clock is at receiver– Time at shared PoC ~ intrapolated receiving
times
11
Simultaneous Bursts (iYY)
• For iYY topology,– No common clock for all possible PoCs– Time at shared PoCs near sender ~
sending times– Time at shared PoCs near receiver ~
intrapolated receiving times– Hence, count drops in bursts that
are simultaneous with a burst (of the other flow) using sending OR receiving times
12
Simultaneous bursts (YiY)
• For YiY topology, – Common clock ~ sending time +
delay to shared routers (and PoCs)– But, clocks of the senders may not
be synchronized– Delay to shared routers is not known– Need to determine
synchronization lag = difference in clocks of senders + difference in delays to shared routers
13
Synchronization Lag
0
CBR Flow 1
CBR Flow 2
Time
Sender 1
Sender 2
PoC
PoC
0T
1
0
d1
2
0
1 2
3 4
1
d2+
0
Synchronization Lag = 3T
3
2
14
Synchronization Lag
0 1 2 3 4 5 6 7
0
T
d1 d2+
CBR Flow 1
CBR Flow 2
Time
Sender 1
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6
Sender 2
0 1 2 3 4
Synchronization Lag = 3T
Note: is bounded by RTTmax/2
PoC
PoC
15
Determine Synclag• Using the sending times, construct 2
sequences of 1s(drops) and 0s• Synclag is loosely bounded by 2*RTTmax
• 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
16
Prevent False Positives
• Bursts at different PoCs may have small overlap; this causes false positives
• Consider bursts only if the simultaneous portion > overlap ratio f of the total length
Flow 1
Flow 2
Burst of Flow 1
Burst of Flow 2
Packet Drop
Transmitted Packet
17
Evaluation
• Hard to generate “real-world” effects with ns-2 simulations; experimental evaluation
• Need large number of flows on different paths for an experimental evaluation; Planetlab
• Not possible to verify the performance of PIE since congestion information about individual links is not available; overlay-based instantiation
18
Overlay-based Instantiations
• Goal: Need 2 paths with shared and non-shared sub-paths
• Each path consists of a sequence of shared and non-shared sub-paths
• Instantiate the first and last node of each sub-path with an overlay router
S1 S2
R1 R2
M1
M2
OverlayNode
19
Overlay Instantiations (contd.)
• All PoCs on shared overlay hop are shared
• But, converse may not be true!• 2 overlay hops from/to the same
node could share a few IP routers
• Drops on ambiguous (overlay) hops may be shared Overlay
NodeAmbiguousHops
20
Overlay Instantiations (contd.)
• Bounds on fraction of drops at shared PoCs– Lower bound: d3/(d1+d2+d3+d4)– Upper bound: (d2+d3+d4)/(d1+d2+d3+d4)
• Also, use experiments in which there are few drops on the ambiguous overlay hops
S1
S2
R1
R2M1 M2
d2 d3 d4d1
N1
N2
21
Evaluation Details
• Planetlab: 45 sites all over the world• CBR UDP probes (default: 1
packet/10ms) using setitmer function in Linux
• Also used 1ms probing by polling timer• Duration of flows: 600s• 2 experimental datasets - March and
June
22
Instantiations used• 4 Overlay topologies
• 2 IP level topologies Y iY YiYYiY
Internet Internet
I topology II topology
23
Outline of Results
• I topology – Base Case Result– Effect of Probing Rate
• YiY topology– Unambiguous results– All results
• Justifying our estimation of synclag• Other observations
24
Base Case• For I topology, we expect PIE to output
1• CDF shows that PIE’s error < 0.3 in
80% of the experiments
25
Probing Rate
• Using 1ms traces for I topology, construct probes of period 10ms and 20ms separated by [1ms,2ms] and [5ms,10ms]
• Conclusions– Burst length>5ms– 20 ms probing much worse
26
YiY topology
• For YiY topology, consider cases with few ambiguous drops
• Conclusions– Overlap ratio 0.5 is good– 1 ms probing does not help (not shown)– Error < 0.3 in 88% of the experiments
27
YiY Topology
• June results similar – 2 false positive; traceroute showed shared trans-Atlantic link
• CDF of all results shows estimate > minimum fraction in 80% cases
28
Estimating Synchronization Lag
• Graph justifies the maximization of cross-correlation coefficient for typical I topology
• Disadvantage: 6% false positive rate (estimate>0.2) with 2 independent paths (II topology)
29
Other Observations
• For Y, iY and iYY topologies we see that error < 0.3 for 80% of the experiments
• Pathological sites: – All results do not include 3 sites which
strongly exhibit random dropping– Individual flows in other failed cases do not
show bursty losses; RED is likely cause
30
Conclusions
• PIE provides an estimate within 0.3 for 80% of the cases for each of Y, iY, YiY, iYY topologies
• Failed cases likely due to RED• Bursts are normally longer than 10ms;
10ms probing seems optimal (4 KBps overhead)
• Synclag estimation by maximizing CCC is mostly justified
31
Future Work
• Can we reduce the probing rate?• How can we adapt PIE to work with
passive (maybe TCP-based) probes• Issues with RED:
– How can we infer a RED-based PoC– How can we estimate shared RED-based PoCs
Recommended