1 / 31

Estimating Shared Congestion Among Internet Paths

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.

bethan
Download Presentation

Estimating Shared Congestion Among Internet Paths

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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}@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 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

  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 routers and 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 iYY Shared routers and PoCs YiY

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

  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. 3 4 0 1 2 T 0 1 3 2 0 1 2 0 d1 d2+ Synchronization Lag = 3T Synchronization Lag Sender 1 CBR Flow 1 PoC Sender 2 CBR Flow 2 PoC Time 0

  14. Synchronization Lag 3 4 5 6 7 8 0 1 2 T Sender 1 CBR Flow 1 0 1 3 4 5 6 7 2 PoC 3 4 5 6 0 1 2 Sender 2 CBR Flow 2 3 4 0 1 2 PoC Time 0 d1 d2+ Note: is bounded by RTTmax/2 Synchronization Lag = 3T

  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 fof the total length Burst of Flow 1 Flow 1 Packet Drop Transmitted Packet Flow 2 Burst of Flow 2

  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 S2 S1 • 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 M1 M2 R1 R2 Overlay Node

  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 Node Ambiguous Hops

  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 N1 d1 R1 d2 d4 S1 d3 M1 M2 S2 R2 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 YiY YiY 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

More Related