1 / 34

Simulating the Internet: Challenges and Methods

This article discusses the challenges and methods of simulating the Internet, including models of behavior, varying parameters, controlled environments, and reproducible results. It also explores the problems in characterizing the Internet, such as scale, drastic change, heterogeneity, link and topology heterogeneity, protocol heterogeneity, application dynamics, and traffic.

patriciaross
Download Presentation

Simulating the Internet: Challenges and Methods

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. Simulating the Internet:challenges & methods Kevin Fall Network Research Group, Lawrence Berkeley National Laboratory Berkeley, CA USA

  2. LBNL’s Network Research Group: Members: Van Jacobson, group leader Kevin Fall Sally Floyd * Craig Leres Vern Paxson * http://www-nrg.ee.lbl.gov

  3. Outline • Simulating the Internet is not easy • The VINT project: an effort in Internet-style simulation

  4. Simulations for Network Research • Models of interesting behavior • Easily-varied parameters • Controlled environment, reproducible results

  5. Problems in Characterizing the Internet • Large Scale: • even a small fraction of misbehaving entities is non-negligible • scale stresses assumptions in protocol design and implementation • Drastic Change: • will the rate of change continue? • predominant use not obvious (e.g. the web, continuous media, ?) • Heterogeneity everywhere!

  6. Link and Topology Heterogeneity • Delay and bandwidth span 5 to 6 orders of magnitude! • 20msec to 2s round-trip prop delay • 10Kb/s to 10Gb/s bandwidth range • Topology • hierarchy and clustering chosen by ISPs • performance tied to which path packets take in network • paths may change dynamically • IP routes are frequently asymmetric

  7. Protocol Heterogeneity • Adaptive and non-adaptive Internet protocols • react to congestion (TCP) • nonreactive (UDP) • Application Dynamics • multi-protocol interactions • user activity • application mix varies greatly by site • Implementations may not be consistent

  8. Traffic • Internet traffic not easily characterized • no commonly accepted model • traffic may be shaped by congestion response • Dependent on source behavior • application protocol limitations • new applications • pricing policies

  9. So, what can be done in simulation? • Strategy • 1: Look for invariants • 2: Explore the parameter space • 3: Understand the limits of simulation

  10. 1: Searching for Invariants • What do we really know about Internet dynamics? • How tocharacterizestatistically? • traffic • users • sessions • congestion, etc. • Mathematical simplicity does not imply accuracy

  11. The Self-Similar Nature of Traffic • packet arrivals not exponentially distributed • thus, arrival process is not Poisson • bursts over multiple time-scales • they exhibit long-range dependence • suggests self-similar models • (there is still contention on this point) • Implications • aggregation does not “smooth out” variation • traffic synthesis more difficult • network buffering may be much less effective than thought based on Markovian models

  12. User-generated Sessions look Poisson • user-generated session arrivals look Poisson (machine-generated connection arrivals are not) • distribution is invariant, parameterized only by a (fixed, hourly) rate

  13. Network Activity tends to have a heavy-tailed distribution • Examples: packets in a user’s TELNET session; bytes in FTP-DATA transfers • distribution looks Pareto with 0.9 < b < 1.0 • Pareto distribution with shape b has: • infinite mean if b <= 2 • infinite variance if b <= 1 • This type of Pareto has infinite mean and variance (and is very unlike an exponential) • burstiness remains across aggregation

  14. 2: Exploring the Parameter Space • Consider a large range for parameters • recall, 5-6 orders of magnitude range in bandwidth and delay • note that behavior is often non-linear in parameter values • Repeat, repeat, repeat • topology generators • randomness

  15. 3: The Limits of Simulation • Simplified Models • useful for gaining intuition and exploring parameters • danger of oversimplification • Need for a Reality Check • compare simulation results with measurement • Internet measurements often offer “surprises”

  16. The VINT Project(Virtual InterNet Testbed) • USC/ISI: Deborah Estrin, Mark Handley, John Heideman, Ahmed Helmy, Polly Huang, Satish Kumar, Kannan Varadhan, Daniel Zappala • LBNL: Kevin Fall, Sally Floyd • UCBerkeley: Elan Amir, Steven McCanne • Xerox PARC: Lee Breslau, Scott Shenker • VINT is currently funded by DARPA through mid-1999

  17. VINT Goals • provide common platform for network research • explore issues of scale and multi-protocol interaction • Specific Areas: • multicast, end-to-end transport • simulation scaling • traffic management • emulation

  18. Multicast Research • Reliable Multicast Transport • Large Scale • “SRM”-- Scalable Reliable Multicast • Multicast Congestion Management • Group formation • (still ongoing) • Layered Transmission • layered encoding • dynamic multi-group join/leave

  19. Simulation Scaling • Simulator capable of 1000s of nodes • Want 100,000s of nodes (or more) • “Session” Abstraction • abstract away some simulation details • trade detail for time/space • scales simulation by about 10X

  20. Traffic Management • Active Buffer Management • Random Early Detection Gateways • Explicit Congestion Notification (ECN) • Packet Scheduling • Class-Based Queuing (CBQ) • Round-Robin and Fair Queuing Variants • Differentiated Services • Admission Control • Reservation Support

  21. Emulation • Interface Simulator with Live Network • Live Traffic Passes through Simulated Topology • Special “Real-Time” Scheduler • may not keep synchronized under load

  22. The VINT Simulation Environment • Components: ns2 and nam • NS2 (network simulator, version 2): • Discrete-event C++ simulation engine • scheduling, timers, packets • Split Otcl/C++ object “library” • protocol agents, links, nodes, classifiers, routing, error generators, traces, queuing, math support (random variables, integrals, etc) • Nam (network animator) • Tcl/Tk application for animating simulator traces • available on UNIX and Windows 95/NT

  23. NS Supported Components • Protocols: • TCP (2modes + variants),UDP, IP, RTP/RTCP, SRM, 802.3 MAC, 802.11 MAC • Routing • global topology map, classifiers • static unicast, dynamic unicast (distance-vector), multicast • Queuing and packet scheduling • FIFO/drop-tail, RED, CBQ, WRR, DRR, SFQ • Topology: nodes, links Failures: link errors/failures • Emulation: interface to a live network

  24. TCP Animation

  25. SRM Animation

  26. Benefits • Common simulation environment • simulations expressed in scripting language • separate visualization tool • topology and “scenario” generators • modular structure is extensible; sources provided • Unique Features • Rich Protocol Set • “Session” abstraction • provides scaling simulations by a factor of 4 • Visualization and Emulation capabilities • separate Network Animator (nam) tool • low-level interface to system’s protocols

  27. The NS Architecture • Simulator is a Object-Tcl “shell” • Split Objects • fine-grain, easily composed • objects exist both in C++ and Tcl Context • library handles object consistency

  28. Work in Progress • Adaptive Web Caching (LBNL, UCLA) • Nam Improvements (USC, ISI) • Simulator Scaling (USC, ISI) • Simulator Addressing Hierarchy (USC, ISI) • Protocol Robustness (USC, ISI) • Emulation (LBNL, UCB) • Quality of Service (Xerox PARC) • Router-Based Congestion Control (LBNL) • Topology and “Scenario” Generation

  29. Router-Based Congestion Control • Two main classes of traffic on Internet: • TCP (reduces sending rate in face of loss) • UDP (application decides when and how much to send) • Internet stability due in large part to TCP’s congestion response • Danger with growing use of UDP-based applications • UDP will “steal” bandwidth from TCP • currently no incentives to prevent this behavior

  30. Encouraging Congestion Control • Combine RED Gateway with analysis and regulation • RED (Random Early Detection) Gateways: • keep smoothed average queue size measure • when measure exceeds threshold, drop or mark packets with increasing probability • a flow’s fraction of the aggregate random packet drop rate is roughly equal to it’s fraction of the aggregate arrival rate • Select candidate “bad” flows with high drop rate

  31. “Bad” Flow Selection Criteria • Flow is not “TCP-friendly” • throughput exceeds factor times analytic model: • Flow is not responsive • does not alter arrival rate with increased packet drops • Flow is “high-bandwidth” • uses more than it’s “fair share”

  32. Flow Regulation • Need bandwidth-regulating packet scheduler • CBQ • others • Use “good” and “bad” scheduling partitions • Bad partition gets allocation below current usage • decays over time with continued offered load • flows may be reclassified as “ok” if they adapt

  33. Conclusion • Simulating the Internet is difficult • Simulation is useful, but must be used carefully • The VINT project a common simulation framework that addresses many of the issues

  34. Additional Information • Web pages: • http://www-nrg.ee.lbl.gov/ • http://www-mash.cs.berkeley.edu/ns • http://netweb.usc.edu/vint • http://www.ito.darpa.mil/Summaries97/E243_0.html • NS Users Mailing list: • majordomo@mash.cs.berkeley.edu • “subscribe ns-users”

More Related