Hybrid Systems Modeling of Communication Networks João P. Hespanha University of California at Santa Barbara Hybrid Control and Switched Systems

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.)

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 similar flows for ensemble-average computationally very efficient (at least for first order statistics)

Types of models 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  provide information about both average, peak, and “instantaneous” resource utilization (queues, bandwidth, etc.) captures fast dynamics even for a small number of flow 

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 Several flows follow the same path and compete for bandwidth in a single bottleneck link Prototypical network to study congestion control single queuerouting is trivial q( t ) ´ queue size r 1 bps r 2 bps r 3 bps rate · B bps queue f1 f1 f2 f2 f3 f3 f1 f1 f2 f2 f3 f3 B is unknown to the data sources and possibly time-varying

Queue dynamics When  f r f exceeds B the queue fills and data is lost (drops) ) drop (discrete event – relevant for congestion control) q( t ) ´ queue size r 1 bps r 2 bps r 3 bps rate · B bps queue f1 f1 f2 f2 f3 f3 f1 f1 f2 f2 f3 f3

Queue dynamics Hybrid automaton representation: q( t ) ´ queue size r 1 bps r 2 bps r 3 bps rate · B bps queue f1 f1 f2 f2 f3 f3 f1 f1 f2 f2 f3 f3 transition enabling condition exported discrete event

Window-based rate adjustment 1 st packet sent e.g., w f = 3 t 2 nd packet sent 3 rd packet sent 1 st packet received & ack. sent 2 nd packet received & ack. sent 3 rd packet received & ack. sent 1 st ack. received ) 4 th packet can be sent t source fdestination f w f effectively determines the sending rate r f : round-trip time t0t0 t1t1 t2t2 t3t3 00 11 22 w f (window size) ´ number of packets that can remain unacknowledged for by the destination

Window-based rate adjustment w f (window size) ´ number of packets that can remain unacknowledged for by the destination ´ sending rate total round-trip time propagation delay per-packet transmission time time in queue until transmission This mechanism is still not sufficient to prevent a catastrophic collapse of the network if the sources set the w f too large queue gets full longer RTT rate decreases queue gets empty negative feedback

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) disclaimer: this is a very simplified version of TCP Reno, better models later… TCP congestion avoidance additive increase multiplicative increase

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) disclaimer: this is a very simplified version of TCP Reno, better models later… Queuing modelTCP congestion avoidance drop RTT rfrf additive increase multiplicative increase

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) disclaimer: this is a very simplified version of TCP Reno, better models later… TCP + Queuing model additive increase multiplicative increase

Linearization of the TCP model TCP + Queuing model additive increase multiplicative increase Time normalization ´ define a new “time” variable  by 1 unit of  ´ 1 round-trip time In normalized time, the continuous dynamics become linear

Impact-map analysis additive increase t0t0 t1t1 t2t2 t3t3 ´ continuous state before the k th multiplicative decrease x1x1 x2x2 T state space x1x1 x2x2 impact map additive increase multiplicative decrease transition surface multiplicative decrease

Impact-map analysis Theorem. The function T is a contraction. In particular, Therefore x k ! x 1 as k !1 x 1 ´ constant x( t ) ! x 1 ( t ) as t ! 1 x 1 (t) ´ periodic limit cycle additive increase t0t0 t1t1 t2t2 t3t3 x1x1 x2x2 T multiplicative decrease ´ continuous state before the k th multiplicative decrease

NS-2 simulation results Window and Queue Size (packets) time (seconds) 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 Router R1 Router R2 TCP Sources TCP Sinks Bottleneck link 20Mbps/20ms flow 1 flow 2 flow 7 flow 8 n1n1 n2n2 n7n7 n8n8 s1s1 s2s2 s7s7 s8s8

Results Window synchronization: convergence is exponential, as fast as.5 k Steady-state formulas: average drop rate average RTT average throughput (well known TCP- friendly formula) additive increase t0t0 t1t1 t2t2 t3t3 multiplicative decrease

2nd pass – general topology network dynamics (queuing & routing) congestion control server client data acks A communication network can be viewed as the interconnection of several blocks with specific dynamics b) Queuing: in-queue rate out-queue rate queue size c) End2end cong. control server sending rate acks & drops a) Routing: in-node rate out-node rates

end2end sending rate of flow f Routing in-queue rate of flow f n f upstream out-queue rate of flow f Conservation of flows: determines the sequence of links followed by each flow n ’ n' n' indexes and ’ determined by routing tables

Routing MulticastMulti-path routing n ’ n' n' n'' ” n 1 ’ n' n' 2 determines the sequence of links followed by each flow

Queue dynamics   in-queue rates out-queue rates … drop rates Queue dynamics: 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 queue not empty/full queue full queue empty same in and out- queue rates out-queue rates proportional to fraction of packets in the queue no drops drops proportional to fraction in- queue rates   in-queue rates out-queue rates … drop rates

Drops events t0t0 t2t2 t1t1 total in-queue rate packet size total out-queue rate (link bandwidth)   in-queue rates out-queue rates … drop rates When?

Drops events Which flows? t0t0 t2t2 t1t1 flow that suffers drop at time t k (drop tail dropping) When?   in-queue rates out-queue rates … drop rates

Hybrid queue model -queue-not-full -queue-full transition enabling condition exported discrete event discrete modes

Hybrid queue model Random Early Drop active queuing stochastic counter -queue-not-full -queue-full discrete modes

Network dynamic & Congestion control routing queue dynamics sending rates drops out-queue rates in-queue rates end2end congestion control TCP/UDP

Additive Increase/Multiplicative Decrease congestion- avoidance TCP-Reno is based on AIMD but uses other discrete modes to improve performance set of links transversed by flow f propagation delays 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) imported discrete event

Slow start 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 cong.-avoid. slow-start especially important for short-lived flows… In the beginning, pure AIMD takes a long time to reach an adequate window size

Fast recovery 5.During retransmission, data is sent at a rate consistent with a window size of w f /2 After a drop is detected, new data should be sent while the dropped one is retransmitted (consistent with TCP-SACK for multiple consecutive drops) cong.-avoid. fast-recovery slow-start

3 th packet received & ack. sent 1 st packet sent 2 nd packet sent 4 th packet sent Timeouts 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 Typically, drops are detected because one acknowledgment in the sequence is missing. 2 nd packet received & ack. sent 4 th packet received & ack. sent sourcedestination three acks received out of order drop 3 th packet sent drop detected, 1 st packet re-sent When the window size becomes smaller than 4, this mechanism fails and drops must be detected through acknowledgement timeout. 

Fast recovery, timeouts, drop-detection delay… TCP SACK version

Network dynamic & Congestion control routing queue dynamics sending rates drops out-queue rates in-queue rates end2end congestion control RTTs see SIGMETRICS paper for on/off TCP & UDP model

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 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 Y-topology dumbbell

Simulation traces single TCP flow 5Mbps bottleneck throughput no background traffic ns cwnd and queue size (packets) time (seconds) cwnd of TCP 1 queue size cwnd and queue size (packets) time (seconds) cwnd of TCP 1 queue size hybrid model slow-start, fast recovery, and congestion avoidance accurately captured

Simulation traces four competing TCP flow (starting at different times) 5Mbps bottleneck throughput no background traffic the hybrid model accurately captures flow synchronization cwnd and queue size (packets) time (seconds) cwnd size of TCP 2 cwnd size of TCP 3 cwnd size of TCP 4 cwnd size of TCP 1 Queue size of Q1 Queue size of Q cwnd and queue size (packets) time (seconds) cwnd size of TCP 2 cwnd size of TCP 3 cwnd size of TCP 4 cwnd size of TCP 1 Queue size of Q1 Queue size of Q2 ns-2 hybrid model

Simulation traces 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 cwnd and queue size (packets) time (seconds) 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 cwnd and queue size (packets) time (seconds) ns-2 hybrid model four competing TCP flow (different propagation delays) 5Mbps bottleneck throughput 10% UDP background traffic (exp. distributed on-off times)

Average throughput and RTTs Thru. 1Thru. 2Thru. 3Thru. 4RTT1RTT2RTT3RTT4 ns hybrid model relative error2.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 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)

Empirical distributions hybrid modelns-2 the hybrid model captures the whole distribution of congestion windows and queue size probability cwnd & queue size probability CWND of TCP1 CWND of TCP2 CWND of TCP3 CWND of TCP4 Queue 3 CWND of TCP1 CWND of TCP2 CWND of TCP3 CWND of TCP4 Queue 3 cwnd & queue size

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