Realistic and Responsive Network Traffic Generation

1. Realistic and Responsive Network Traffic Generation Kashi Venkatesh Vishwanath Amin Vahdat University of California, San Diego

2. Motivation Background traffic source Background traffic sink ZCP Evaluation Home user Webserver Did we model the right background traffic? For 2006, as well as 2010? Does web traffic affect background traffic?

3. Traffic Generation Goals • Realism • Application mix, application characteristics • Average bytes and packet arrival rates • Burstiness of traffic at various timescales • Responsiveness • Competing application can alter background traffic • Ability to project into alternate scenarios • Doubling access link capacity • Changing popularity from HTTP to P2P

4. Why Another Traffic Generator? Existing traffic generators • Aggregate traffic into a single class • Limits ability to vary application mix • Ignore effect of wide-area links on flows • Limits ability to project to alternate scenarios • Cannot reproduce burstiness in traffic • Competing applications could be sensitive to burstiness No Realistic and Responsive Traffic Generator

5. Contributions Swing Realistic and responsive traffic generator • Reproduce observed burstiness in traffic • Identify and examine critical components • Users • Applications • Network • Ability to project traffic into alternate scenarios • Change application mix, user behavior, network characteristics Details to follow

6. Rest of the Talk • Traffic Generation • Traffic Validation • Responsiveness • Is traffic burstiness important? • What is next?

7. What Does Traffic Depend On? Complex interaction at various layers • Users • Periods of activity • Application popularity etc. • Applications • HTTP, SMTP • Request/Response behavior • Network • Packet losses • Latency etc. Capture and model the interaction between layers from perspective of a single link

8. Generate Swing traffic Program hosts (running real OS, TCP stack) to communicate using the structural model Extract parameters for users, network, and applications Model dumb-bell topology Model target scenario current/alternate Methodology Overview Swing trace Start with a given trace

9. Modeling Traffic Passive TCP trace measurements Applications Network Users Link capacity Link latency Link loss rate #sessions, intersession Traffic SESSION: #RRE, interRRE CDFs for model parameters complete Next: generate traffic using the CDFs Classification Request-Response Exchange (RRE): #conn,interconn HTTP SMTP P2P NNTP (IP,Port) REQ/RSP sizes numpairs, thinktime TCP SEQ, ACK, timestamps

10. 10mbps, 10ms, 2% loss Hosts Record traffic Sessions RRE Connections Traffic Generation Network Emulator RSP 1000 RSP 5000 REQ 500 REQ 100 Wait 100ms Physical machines 100 mbps, 10ms, 1% loss rate Swing traffic/trace HTTP SMTP P2P NNTP REQ/RSP, Numpairs, thinktime

11. Results Compare Swing trace to original trace • Realism • Coarse-grained behavior e.g., throughput • Modeled parameters e.g., response size • Burstiness of traffic • Responsiveness • What-if scenarios Is burstiness important?

12. Target Traces Mawi 18Mbps CAR ~18Mbps HTTP, SMTP, NAPSTER, NNTP CAIDA OC48 ~200Mbps HTTP, KAZAA, NNTP For this talk, AUCK Auck OC3c ATM ~ 5.5 Mbps HTTP, SQUID, SMTP Photo courtesy university of texas library

13. Experimental Setup • 10 minute Auck trace • 2300 July 24, 2001 • 11 Linux + 1 FreeBSD machines • Multiplexing 1000 virtual hosts • HTTP, SQUID, and TCPOTHER • Top host – 4% of traffic • Top 100 hosts – 60% of traffic • Top 1000 hosts – 98% of traffic

14. Results Compare Swing trace to original trace • Realism • Coarse-grained behavior e.g., throughput • Modeled parameters e.g., response size • Burstiness of traffic • Responsiveness • What-if scenarios Is burstiness important?

15. Validation: Burstiness • Coarse-grained behavior insufficient • How do traffic demands peak? At different timescales? • Various techniques: • Index of dispersion of counts/intervals • Power spectral density • Wavelet-based Multi-Resolution Analysis (MRA)

16. Energy Plot Example More bursty 1ms 256ms Coarser timescale

17. Importance of Network Modeling More bursty Users Application Network Capacity Latency Loss rates Coarser timescale

18. Importance of Network Modeling More bursty Users Application Network Capacity Latency Loss rates Coarser timescale

19. Importance of Network Modeling More bursty Users Application Network Capacity Latency Loss rates Coarser timescale

20. Importance of Network Modeling More bursty Users Application Network Capacity Latency Loss rates Important to model network (capacity, latency, loss rates) Coarser timescale

21. Results Compare Swing trace to original trace • Realism • Coarse-grained behavior e.g., throughput • Modeled parameters e.g., response size • Burstiness of traffic • Responsiveness • What-if scenarios Is burstiness important?

22. Results Compare Swing trace to original trace • Realism • Coarse-grained behavior e.g., throughput • Modeled parameters e.g., response size • Burstiness of traffic • Responsiveness • What-if scenarios Is burstiness important?

23. Bittorrent: Sensitivity to Bursty Background Traffic Does burstiness matter? • Two kinds of background traffic • Both ~ 5.5mbps • Differ in burstiness • 100 bittorrent nodes • 46MB file download • 10mbps, 50ms access links

24. Bittorrent: Sensitivity to Bursty Background Traffic • Two kinds of background traffic • Both ~ 5.5mbps • Differ in burstiness • 100 bittorrent nodes • 46MB file download • 10mbps, 50ms access links Background traffic matters Burstiness of background traffic matters

25. Future Work • Improve model • Improve accuracy of model parameter predictions • Single model for all applications • Causality of network events • Reasons for impact of background traffic on end-to-end application behavior • Application sensitivity to specific levels of burstiness • Generalize to larger topologies

26. Contributions Realistic and Responsive Traffic Generation • Reproduce burstiness (sub-RTT) for live traffic • Extract and reproduce essential properties • Users, Applications and Network • Impact of burstiness on competing applications

27. Questions? • More information and code release (soon) • http://www.cs.ucsd.edu/~kvishwanath

28. Extra slides from here on

29. Limitations • Symmetry of routes • Parameters of our model • Network characteristics • Extract all prevailing wide area conditions using a single packet trace • Responsiveness of UDP traffic

30. Bidirectional traces

31. Sensitivity to interconn, interRRE

32. Responsiveness to latency and response size Latency double RSPDouble

33. Validation

34. UDP • Currently support two simple models • Bulk transfer • Constant bit rate transfer • For more complex, adaptive UDP protocols • Need to model application’s adaptability

35. Related work • Harpoon, SURGE • All applications in a single class, no network • Tmix • Replay of tcp connections • RAMP • Simulation based, only for HTTP and FTP • Tcplib • Ability to generate traffic but not to populate model

36. Importance of burstiness • At large timescales (mins-hours) • LRD • Self-similarity • Buffer size requirement of LRD traffic • At small timescales (ms-secs) • Loss rate at buffers for bursty traffic • Need to generate bursty traffic to understand its importance!

37. Changing application mix Baseline comparison from an earlier graph

38. Changing application mix • Increase SQUID traffic by 20 times • What should overall energy plot look like? SQUID is different from overall AUCK

39. Changing application mix • Increase SQUID traffic by 20 times • What should overall energy plot look like? Can project traffic demands to alternate scenarios

40. Validate Responsiveness? • Cannot, by definition • But … • Think baby steps, not giant leaps • Better than what you can do today

41. Fixed CDFs for trace duration? • Yes at the moment • Distributions stationary for a few minutes • Dynamically change in future • Changes to link bandwidth • Shift is application popularity

42. Generic Parameterization • Study lots of traces • Classify shape of CDF based on link-class • Curve-fitting/Analytical distributions • Use existing results from literature to mix and match