Hybrid Control and Switched Systems. Lecture #17 Hybrid Systems Modeling of Communication Networks

Transcription

1 Hybrid Control and Switched Systems Lecture #17 Hybrid Systems Modeling of Communication Networks João P. Hespanha University of California at Santa Barbara 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.)

2 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 similar flows for ensemble-average computationally very efficient (at least for first order statistics) 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 Types of models captures fast dynamics even for a small number of flow provide information about both average, peak, and instantaneous resource utilization (queues, bandwidth, etc.) 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) computationally efficient

3 Summary Modeling 1 st pass: Dumbbell topology & simplified TCP Modeling 2 nd pass: General topology, TCP and UDP models Validation Simulation complexity 1st pass Dumbbell topology f 1 r 1 bps queue f 1 f 2 r 2 bps rate B bps f 2 f 3 r 3 bps q( t ) queue size f 3 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 B is unknown to the data sources and possibly time-varying

4 Queue dynamics f 1 r 1 bps queue f 1 f 2 r 2 bps rate B bps f 2 f 3 r 3 bps q( t ) queue size f 3 When f r f exceeds B the queue fills and data is lost (drops) drop (discrete event relevant for congestion control) Queue dynamics f 1 r 1 bps queue f 1 f 2 r 2 bps rate B bps f 2 f 3 r 3 bps Hybrid automaton representation: q( t ) queue size transition enabling condition f 3 exported discrete event

5 w f (window size) Window-based rate adjustment number of packets that can remain unacknowledged for by the destination e.g., w f = 3 source f destination f t 0 1 st packet sent 2 nd packet sent t 1 3 rd packet sent t 2 τ 0 1 st packet received & ack. sent τ 1 2 nd packet received & ack. sent 1 st ack. received t 3 τ 2 4 th packet can be sent 3 rd packet received & ack. sent w f effectively determines the sending rate r f : t t round-trip time Window-based rate adjustment w f (window size) number of packets that can remain unacknowledged for by the destination sending rate per-packet transmission time total round-trip time propagation delay time in queue until transmission queue gets full longer RTT rate decreases queue gets empty negative feedback This mechanism is still not sufficient to prevent a catastrophic collapse of the network if the sources set the w f too large

6 TCP congestion avoidance 1. While there are no drops, increase w f by 1 on each RTT (additive increase) 2. When a drop occurs, divide w f by 2 (multiplicative decrease) (congestion controller constantly probes the network for more bandwidth) TCP congestion avoidance additive increase multiplicative increase disclaimer: this is a very simplified version of TCP Reno, better models later TCP congestion avoidance 1. While there are no drops, increase w f by 1 on each RTT (additive increase) 2. When a drop occurs, divide w f by 2 (multiplicative decrease) (congestion controller constantly probes the network for more bandwidth) Queuing model TCP congestion avoidance r f additive increase RTT drop multiplicative increase disclaimer: this is a very simplified version of TCP Reno, better models later

7 TCP congestion avoidance 1. While there are no drops, increase w f by 1 on each RTT (additive increase) 2. When a drop occurs, divide w f by 2 (multiplicative decrease) (congestion controller constantly probes the network for more bandwidth) TCP + Queuing model additive increase multiplicative increase disclaimer: this is a very simplified version of TCP Reno, better models later Linearization of the TCP model Time normalization define a new time variable τ by 1 unit of τ 1 round-trip time TCP + Queuing model additive increase multiplicative increase In normalized time, the continuous dynamics become linear

8 Switching-by-switching analysis x 1 T x 2 t 0 t 1 t 2 t 3 additive increase additive increase additive increase multiplicative decrease multiplicative decrease continuous state before the k th multiplicative decrease multiplicative decrease x 1 x 2 transition surface additive increase state space impact map Switching-by-switching analysis x 1 T x 2 t 0 t 1 t 2 t 3 additive increase additive increase additive increase multiplicative decrease multiplicative decrease continuous state before the k th multiplicative decrease Theorem. The function T is a contraction. In particular, Therefore x k x as k x( t ) x ( t ) as t x constant x (t) periodic limit cycle

9 NS-2 simulation results flow 1 n 1 s 1 Window and Queue Size (packets) flow 2 TCP Sources flow 7 flow 8 n 2 n 7 n 8 Router R1 Bottleneck link Router R2 20Mbps/20ms s 2 s 7 s 8 TCP Sinks window size w 1 window size w 2 window size w 3 window size w 4 window size w 5 window size w 6 window size w 7 window size w 8 queue size q time (seconds) Results t 0 t 1 t 2 t 3 additive increase additive increase additive increase multiplicative decrease multiplicative decrease Window synchronization: convergence is exponential, as fast as.5 k Steady-state formulas: average drop rate average RTT average throughput (well known TCPfriendly formula)

10 2nd pass general topology A communication network can be viewed as the interconnection of several blocks with specific dynamics network dynamics (queuing & routing) server data a) Routing: in-node rate out-node rates acks b) Queuing: client out-queue rate queue size in-queue rate congestion control c) End2end cong. control acks & drops server sending rate Routing determines the sequence of links followed by each flow f n l n' l n l Conservation of flows: end2end sending rate of flow f in-queue rate of flow f upstream out-queue rate of flow f indexes l and l determined by routing tables

11 Routing determines the sequence of links followed by each flow Multicast Multi-path routing n' l n l 1 n' l n l l l 2 n'' Queue dynamics in-queue rates l out-queue rates M drop rates M link bandwidth total queue size queue size due to flow f the packets of each flow are assumed uniformly distributed in the queue Queue dynamics:

12 Queue dynamics in-queue rates l out-queue rates M no drops drop rates queue empty M same in and outqueue rates queue not empty/full drops proportional to fraction inqueue rates queue full out-queue rates proportional to fraction of packets in the queue Drops events in-queue rates l out-queue rates When? M drop rates M t 0 t 1 t 2 total in-queue rate total out-queue rate (link bandwidth) packet size

13 Drops events in-queue rates l out-queue rates When? M drop rates M t 0 t 1 t 2 Which flows? flow that suffers drop at time t k (drop tail dropping) Hybrid queue model l-queue-not-full transition enabling condition discrete modes l-queue-full exported discrete event

14 Hybrid queue model l-queue-not-full stochastic counter discrete modes l-queue-full Random Early Drop active queuing Network dynamic & Congestion control routing in-queue rates queue dynamics out-queue rates sending rates end2end congestion control drops TCP/UDP

15 Additive Increase/Multiplicative Decrease 1. While there are no drops, increase w f by 1 on each RTT (additive increase) 2. When a drop occurs, divide w f by 2 (multiplicative decrease) (congestion controller constantly probe the network for more bandwidth) congestionavoidance imported discrete event propagation delays set of links transversed by flow f TCP-Reno is based on AIMD but uses other discrete modes to improve performance Slow start In the beginning, pure AIMD takes a long time to reach an adequate window size 3. Until a drop occurs (or a threshold ssth f is reached), double w f on each RTT 4. When a drop occurs, divide w f and the threshold ssth f by 2 slow-start cong.-avoid. especially important for short-lived flows

16 Fast recovery After a drop is detected, new data should be sent while the dropped one is retransmitted 5. During retransmission, data is sent at a rate consistent with a window size of w f /2 slow-start cong.-avoid. fast-recovery (consistent with TCP-SACK for multiple consecutive drops) 1 st packet sent 2 nd packet sent 3 th packet sent 4 th packet sent Timeouts Typically, drops are detected because one acknowledgment in the sequence is missing. source destination drop three acks received out of order drop detected, 1 st packet re-sent 2 nd packet received & ack. sent 3 th packet received & ack. 4sent th packet received & ack. sent When the window size becomes smaller than 4, this mechanism fails and drops must be detected through acknowledgement timeout. 6. When a drop is detected through timeout: a. the slow-start threshold ssth f is set equal to half the window size, b. the window size is reduced to one, c. the controller transitions to slow-start

17 Fast recovery, timeouts, drop-detection delay TCP SACK version Network dynamic & Congestion control routing in-queue rates out-queue rates sending rates RTTs queue dynamics end2end congestion control drops see SIGMETRICS paper for on/off TCP & UDP model

18 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 dumbbell Y-topology 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 Simulation traces single TCP flow 5Mbps bottleneck throughput no background traffic cwnd and queue size (packets) hybrid model cwnd of TCP 1 queue size time (seconds) cwnd and queue size (packets) ns-2 cwnd of TCP 1 queue size time (seconds) slow-start, fast recovery, and congestion avoidance accurately captured

19 Simulation traces four competing TCP flow (starting at different times) 5Mbps bottleneck throughput no background traffic cwnd and queue size (packets) hybrid model cwnd size of TCP 1 cwnd size of TCP 2 cwnd size of TCP 3 cwnd size of TCP 4 Queue size of Q1 Queue size of Q time (seconds) cwnd and queue size (packets) ns-2 cwnd size of TCP 1 cwnd size of TCP 2 cwnd size of TCP 3 cwnd size of TCP 4 Queue size of Q1 Queue size of Q time (seconds) the hybrid model accurately captures flow synchronization Simulation traces four competing TCP flow (different propagation delays) 5Mbps bottleneck throughput 10% UDP background traffic (exp. distributed on-off times) cwnd and queue size (packets) hybrid model CWND size of TCP 1 (Prop=0.045ms) CWND size of TCP 2 (Prop=0.090ms) CWND size of TCP 3 (Prop=0.135ms) CWND size of TCP 4 (Prop=0.180ms) Queue size of Q1 Queue size of Q time (seconds) cwnd and queue size (packets) ns-2 CWND size of TCP 1 (Prop=0.045ms) CWND size of TCP 2 (Prop=0.090ms) CWND size of TCP 3 (Prop=0.135ms) CWND size of TCP 4 (Prop=0.180ms) Queue size of Q1 Queue size of Q time (seconds)

20 Average throughput and RTTs 45,90,135,180ms propagation delays drop-tail queuing 5Mbps bottleneck throughput 10% UDP on/off background traffic four competing TCP flow (different propagation delays) 5Mbps bottleneck throughput 10% UDP background traffic (exp. distributed on-off times) ns-2 hybrid model Thru Thru Thru Thru RTT RTT RTT RTT relative error 2.6% 7.9% 1.5%.7% 9.3% 5.9% 3.6% 2.1% the hybrid model accurately captures TCP unfairness for different propagation delays Empirical distributions probability hybrid model CWND of TCP1 CWND of TCP2 CWND of TCP3 CWND of TCP4 Queue cwnd & queue size probability ns-2 CWND of TCP1 CWND of TCP2 CWND of TCP3 CWND of TCP4 Queue cwnd & queue size the hybrid model captures the whole distribution of congestion windows and queue size

21 execution time for 10min of simulation time [sec] flow 3 flows 5Mbps Execution time 50Mbps 500Mbps ns-2 hybrid model bottleneck bandwidth [Mbps] number of flows ns-2 complexity approximately scales with (# packets) hybrid simulator complexity approximately scales with per-flow throughput hybrid models are particularly suitable for large, highbandwidth simulations (satellite, fiber optics, backbone)