1 / 28

Multiscale Traffic Processing Techniques for Network Inference and Control

Multiscale Traffic Processing Techniques for Network Inference and Control. R. Baraniuk R. Nowak E. Knightly R. Riedi V. Ribeiro S. Sarvotham A. Keshavarz R. King. NMS PI meeting Monterey November 2004. SPiN S ignal P rocessing i n N etworking. Effort 1.

ulema
Télécharger la présentation

Multiscale Traffic Processing Techniques for Network Inference and Control

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. Multiscale Traffic Processing Techniques for Network Inference and Control R. Baraniuk R. Nowak E. Knightly R. Riedi V. Ribeiro S. SarvothamA. Keshavarz R. King NMS PI meeting Monterey November 2004 SPiNSignal Processing in Networking

  2. Effort 1 Spatio-Temporal Available Bandwidth Estimation On-line localization of the tight link in a path

  3. Key Definitions • Available bandwidth: left-over capacity on link • Tight link: link with least available bandwidth • Goal: • locate tight link in space and over time • using end-to-end probing

  4. Applications • Science: where do Internet tight links occur and why? • Network aware applications • Server selection • Route selection • Network monitoring • - locating hot spots

  5. Methodology Path available bandwidth Methodology: • For m>tight link, A[1,m] remains constant Sub-path available bandwidth

  6. Packet Tailgating • Packet train contains: • Large packets stressing, with m hops life time • Small packets tailgating, full life time • Purpose: • Large packets “measure” bandwidth via their delay • Small packets transport this timing information to the receiver

  7. Methodology Departure pattern Queuing against departure Real world experiments Number of chirps  Estimation against true x-traffic Internet experiment 12 chirps Lite-probing: pathChirp • real world tool • Queuing delay  cross traffic • Averaged excursions available resources • Light weight • Probe at various rates simultaneously • …converges in a handful of RTTs

  8. avail time space Bandwidth: a Probabilistic entity • Available bandwidth depends on temporary congestion level of potential tight links UIUC – Rice Probability of being tight link Estimates taken 10 mins apart REAL WORLD EXPERIMENTS UIUC (J. Hou)– Rice Available sub-path bandwidth

  9. STAB: Spatio Temporal available Bandwidth • STAB detects new tight link and reduced available bandwidth around 250 secs into simulation Estimate ns2 Simulation setting: Double web farm in ns2 (420 clients, 40 servers) Truth

  10. GUI: ease of configuration • Running on windows • Instrumental for distribution and transfer

  11. GUI in action • See Demo

  12. Connection-level Analysis and Modeling of Network Trafficunderstanding the cause of burstsdetect changes of network state Effort 2

  13. 99% Mean Bursts and Dominance Connection level separation: • Detrimental bursts caused by the ONEstrongest connection • ….called Alpha connections Origin of Alpha: • High rate  today from small RTT (round trip time) • Not congestion controlled Beta connections: • All the rest • Well controlled = + Overall traffic 1 Strongest connection Alpha Residual traffic Beta

  14. Burst Model • Alpha traffic = High rate ON-OFF source • bottleneck at the receiver (TCP advertised window)  Rate determined by RTT • Current state of measured traffic • Analysis: Queues will explode with TCP’s ability to achieve large rates (HSTCP, BIC) Beta (top) + Alpha Variable Service Rate • Queue-tail Weibull (as for self-similar • traffic) unless • rate of alpha traffic larger than • available bandwidth • and duration of alpha ON period heavy tailed

  15. Free parameters Total Alpha Beta • Beta users: rate determines file size • Alpha users are “free” Duration - Rate Duration - Size X Size - Rate

  16. SIMULATION Scheme RD: Rate Duration independent Scheme SD: Size Duration independent Scheme SR: Size Rate independent Real Trace Total Alpha Beta

  17. Network-User Driven Traffic modelMixture fit of alpha-beta • Alpha: free to choose files  RATE DISTRIBUTIONS • Beta: patience factor  FILE SIZE DISTRIBUTIONS • RAPID PERFORMANCE ASSESSMENT • TCP Control: manages only BETA traffic effectively  Congestion and admission control Alpha (SR) + Beta (RD) Original trace (Bellcore)

  18. Effort 3 Model based Protocols

  19. Prediction and what if scenarios • High-performance protocols pushed • HSTCP • STCP • XCP • FAST-TCP • BI-TCP • RTT bias • alpha-beta differentiation between flows more pronounced for STCP and HSTCP (which have large RTT bias). • Need for RTT-fair high-performance TCP

  20. TCP Africa Adaptive and Fair Rapid Increase Congestion Avoidance • Hybrid  two modes • Fast mode: (absence of congestion) • Rapid, opportunistic increase of window (rate) • Slow mode: (presence of congestion) • Linear (slow) increase in congestion avoidance • Congestion inference: • Current average RTT – minimal RTT (Vegas-type)

  21. TCP Africa • Hybrid  two modes • Fast mode: (absence of congestion) • Rapid, opportunistic increase of window (rate) • Slow mode: (presence of congestion) • Linear (slow) increase in congestion avoidance • Congestion inference: • Current average RTT – minimal RTT (Vegas-type) • Induces LOSSES infrequently (like Reno) • Combines aggressiveness of HSTCP with reliability and low loss induction of Reno

  22. RTT Fairness • Against peers with different RTT • HSTCP: low RTT overwhelms • Africa: RTT bias is comparable to Reno

  23. Safety • Degrade performance of other flows • …as compared to normal conditions • ns2 sim: Reno over 100Mbps link • …and with 1 Gbps Africa acceptable HSTCP poor Africa acceptable HSTCP poor

  24. Impact and Transfer

  25. Software • STAB • pathChirp • Alpha-Beta decomposition • User Interface on Windows (GUI) • 80% completed • Free, available at spin.rice.edu

  26. Publications Enable transition to DoD contractors • Note and understand • Write own code • IEEE Internet Computing Magazine • pathChirp and STAB • Computer Networks • Special issue on LRD traffic • Alpha-Beta / Network-User driven traffic model • IEEE Signal Processing • special issue on SPiN • IEEE SP Magazine • Special issue on Complexity in Networking • Network modeling, MWM, role of multifractal scaling • InfoCom 2005 • TCP Africa

  27. Tech Transfer and Integration • GUI: Pathchirp Running on Windows • Raytheon: Doug Fowler discussing transitions pathChirp • Sensor networks: Steve Beck (BAE Austin) • Hitachi • David Diep makes pathChirp IPv4 and IPv6 compatible • Computer Sciences Corporation (DoD contractor) • Steve Tsang uses MWM for DSN VoIP User Interface • GridLab Project (Verstoep) • Deployed pathChirp for Grid computing measurements • SPAWAR (consulted Phuong Nguyen) • J9 (consulted Jasom Boyer) • GaTech (Riley-Fujimoto) • On-line pathChirp inference in integrated demo to detect UDP storms • UC Riverside (Faloutsos) • On-line Traffic estimation / demystify LRD • UIUC (Hou) and ISI (Heidemann) • Integration of probing schemes into network • simulators JavaSim and ns-2 • SLAC (Cottrell) • Large scale monitoring using pathChirp

  28. Ongoing work • pathChirp: chirp-web • Tight links on high speed networks • Anomaly detection through chirp-web • a/b: Network/user-driven traffic model • Through simulation and measurements assess impact of protocols, applications, clientele, end-host server • Parameters from network and user specifications • High-speed protocols and congestion control • continue to integrate advanced modeling/probing     techniques into new protocols

More Related