Jo ã o P. Hespanha University of Calif. Santa Barbara

1. A Hybrid Systems Modeling Frameworkfor Fast and Accurate Simulation ofData Communication Networks Stephan Bohacek University ofDelaware Junsoo Lee University ofSouthern California Katia Obraczka University of Calif.Santa Cruz João P. Hespanha University of Calif.Santa Barbara

2. Motivation • Why model network traffic? • to validate designs through simulation (scalability, performance) • to analyze and design protocols (throughput, fairness, security, etc.) • to tune network parameters (queue sizes, bandwidths, etc.)

3. Types of models • Packet-level modeling • tracks individual data packets, as they travel across the network • ignores the data content of individual packets • sub-millisecond time accuracy • computationally very intensive • Fluid-based modeling • tracks time/ensemble-average packet rates across the network • does not explicitly model individual events (acknowledgments, drops, queues becoming empty, etc.) • time accuracy of a few seconds for time-average • only suitable to model many flows for ensemble-average • computationally very efficient

4. Types of models captures fast dynamicseven for a small number of flow  • Hybrid modeling • keeps track of packet rates for each flow averaged over small time scales • explicitly models some discrete events (drops, queues becoming empty, etc.) • time accuracy of a few milliseconds (round-trip time)  provide information about both average, peak, and “instantaneous” resource utilization(queues, bandwidth, etc.)

5. Talk outline • Modeling 1st pass: Dumbbell topology & simplified TCP • Modeling 2nd pass: General topology & full TCP model • Validation • Simulation complexity • Conclusions and future work

6. 1st pass – Dumbbell topology f1 f1 r1 bps queue f2 r2 bps f2 rate ·B bps q(t) ´ queue size f3 r3 bps f3 Several flows follow the same path and compete for bandwidth in a single bottleneck link Prototypical network to study congestion control routing is trivial single queue

7. 1st pass – Dumbbell topology f1 f1 r1 bps queue f2 r2 bps f2 rate ·B bps q(t) ´ queue size f3 r3 bps f3 Queue dynamics: When åf rf exceeds B the queue fills and data is lost (drops) )drop(discrete event – relevant for congestion control)

8. Window-based rate adjustment wf (window size) ´ number of packets that can remain unacknowledged for by the destination source f destination f e.g., wf = 3 t0 1st packet sent t1 2nd packet sent t2 t0 3rd packet sent 1st packet received & ack. sent t1 2nd packet received & ack. sent t2 t3 1st ack. received )4th packet can be sent 3rd packet received & ack. sent t t time in queueuntil transmission wf effectively determines the sending rate rf : round-trip time propagation delay

9. TCP Reno congestion control • While there are no drops, increase wf by 1 on each RTT (additive increase) • When a drop occurs, divide wf by 2 (multiplicative decrease) • (congestion controller constantly probes the network for more bandwidth) Reno controllers Queuing model rf RTT drop disclaimer: this is a very simplified version of Reno…

10. Hybrid system model for TCP transition enabling condition additive-increase (drop) state reset

11. 2nd pass – general topology server data in-noderate out-noderates acks out-queuerate in-queuerate queue size client acks & drops sendingrate server A communication network can be viewed as theinterconnection of several blocks with specific dynamics network dynamics (queuing & routing) a) Routing: b) Queuing: c) End2end cong. control congestion control

12. 2nd pass – general topology f1 n4 n1 3 1 n3 n6 5 f2 f2 4 2 n5 n2 f1 N := { n1, n2, … } ´ set of nodes L := { 1, 2, … } ´ set of links B´ bandwidth of link  2 L T´ prop. delay of link  2 L F := { f1, f2, … } ´ set of end2end flows

13. Routing f  ’  n n n' determines the sequence of links followed by each flow Conservation of flows: sending rate of flowf in-queue rate of flowf upstream out-queue rate of flow f

14. Routing ’ ’  1 n n n' n' ” 2 n'' determines the sequence of links followed by each flow Multicast Multi-path routing

15. Queue dynamics  in-queue rates out-queue rates drop rates M M … Queue dynamics: queue size due to flowf total queue size the packets of each flow are assumed uniformly distributed in the queue

16. Queue dynamics  in-queue rates out-queue rates drop rates M M … same in and out-queue rates queue empty no drops queue not empty/full queue full out-queue rates proportional to fraction of packets in the queue drops proportional to fraction in-queue rates

17. Hybrid queue model -queue-not-full transition enabling condition discrete modes exporteddiscrete event -queue-full disclaimer: see paper for model considering drop bursts…

18. Hybrid queue model -queue-not-full stochastic counter discrete modes Random Early Dropactive queuing -queue-full disclaimer: see paper for model considering drop bursts…

19. Network dynamic & Congestion control routing in-queue rates sendingrates out-queuerates queue dynamics congestion control TCP/UDP drops

20. Additive Increase/Multiplicative Decrease • While there are no drops, increase wf by 1 on each RTT (additive increase) • When a drop occurs, divide wf by 2 (multiplicative decrease) • (congestion controller constantly probe the network for more bandwidth) importeddiscrete event propagation delays congestion-avoidance set of links transversed by flow f TCP-Reno is based on AIMD but uses other discrete modes to improve performance

21. Slow start • Until a drop occurs (or a threshold ssthf is reached), double wf on each RTT • When a drop occurs, divide wf and the threshold ssthf by 2 slow-start cong.-avoid.

22. Fast recovery, timeouts, drop-detection delay… • During retransmission, data is sent at a rate consistent with a window size of wf /2 • When a drop is detected through timeout: • the slow-start threshold ssthf is set equal to half the window size, • the window size is reduced to one, • the controller transitions to slow-start

23. Network dynamic & Congestion control routing in-queue rates RTTs sendingrates out-queuerates queue dynamics congestion control drops see paper for on/off UDP model

24. Validation methodology • Compared simulation results from • ns-2 packet-level simulator • hybrid models implemented in Modelica • Plots in the following slides refer to two test topologies Y-topology dumbbell • 10ms propagation delay • drop-tail queuing • 5-500Mbps bottleneck throughput • 0-10% UDP on/off background traffic • 45,90,135,180ms propagation delays • drop-tail queuing • 5-500Mbps bottleneck throughput • 0-10% UDP on/off background traffic

25. Simulation traces • single TCP flow • 5Mbps bottleneck throughput • no background traffic hybrid model ns-2

26. Simulation traces • four competing TCP flow • 5Mbps bottleneck throughput • no background traffic hybrid model ns-2 the hybrid model accurately captures flow synchronization

27. Simulation traces • four competing TCP flow • 5Mbps bottleneck throughput • 10% UDP background traffic(exponentially distributedon-off times) hybrid model ns-2

28. Average throughput and RTTs • four competing TCP flow • 5Mbps bottleneck throughput • 10% UDP background traffic(exponentially distributedon-off times) • 45,90,135,180ms propagation delays • drop-tail queuing • 5Mbps bottleneck throughput • 10% UDP on/off background traffic the hybrid model accurately captures TCP unfairness for different propagation delays

29. Empirical distributions hybrid model ns-2 the hybrid model captures the whole distribution of congestion windows and queue size

30. Execution time 1 flow 3 flows 500Mbps ns-2 50Mbps hybrid model 5Mbps number of flows • ns-2 complexity approximately scales with • hybrid simulator complexity approximately scales with (# packets) per-flow throughput hybrid models are particularly suitable for large, high-bandwidth simulations (satellite, fiber optics, backbone)

31. Conclusions • Hybrid systems provide a promising approach to model network traffic: • retain the low-dimensionality of continuous approximations to traffic flow • are sufficiently expressive to represent event-based control mechanisms with high accuracy, even at small time-scales • the complexity scales inversely with throughput and RTT, making them especially useful to simulate for high-bandwidth networks • they are also amenable to formal analysis… • Areas of future work: • Construct models for other forms of congestion control, queuing policies, drop models (e.g., wireless), etc. • Development of a freeware simulator • Further validation using more complex topologies • Extension of these techniques to other levels of abstraction to scale up to very large networks (e.g., abstract drops but keep discrete event such as changes in routing)

32. END

33. Drops events  in-queue rates out-queue rates drop rates M M … t0 t1 t2 packet size total in-queue rate total out-queue rate (link bandwidth)

34. Drops events  in-queue rates out-queue rates drop rates M M … When? t0 t1 t2 Which flows? the packets of each flow are assumed uniformly distributed in the queue flow that suffers drop at time tk