Simulating Large Networks using Fluid Flow Model Yong Liu Joint work with Francesco LoPresti, Vishal Misra Don Towsley, Yu Gu
Outline Fluid Flow Model ODE solving Methods Account for Topology Computation Savings Model Adjustments Integration with Packet Level Simulators Open Issues
network TCP runs at the “edge” Routers within network drop/mark packets when buffers fill up Fluid Model of a Network of AQM Routers Supporting TCP Flows
TCP Congestion Control: window algorithm Window: can send W packets at a time increase window by one per RTT if no loss decrease window by half on detection of loss
TCP Congestion Control: window algorithm Window: can send W packets increase window by one per RTT if no loss decrease window by half on detection of loss sender receiver W
TCP Congestion Control: window algorithm Window: can send W packets increase window by one per RTT if no loss decrease window by half on detection of loss sender receiver W
Active Queue Management:RED RED: Random Early Detect proposed in 1993 Proactively mark/drop packets in a router queue probabilistically to –Prevent onset of congestion by reacting early –Remove synchronization between flows
The RED Mechanism RED: Marking/dropping based on average queue length x (t) (EWMA algorithm used for averaging) t min t max p max 1 2t max Marking probability p Average queue length x t -> - q (t) - x (t) x (t): smoothed, time averaged q (t)
Modeling RED: A Single Congested Router TCP flow i, prop. delay A i AQM router C, p One bottlenecked AQM router –service capacity {C (packets/sec) } –queue length q(t) – drop prob. p(t) N TCP flows –window sizes W i (t) –round trip time R i (t) = A i +q (t)/C –throughputs B i (t) = W i (t)/R i (t)
System of Differential Equations Window Size: All quantities are average values. Timeouts and slow start ignored Additive increase Loss arrival rate Mult. decrease Queue length: Outgoing traffic Incoming traffic
System of Differential Equations (cont.) Average queue length: Where = averaging parameter of RED(w q ) = sampling interval ~ 1/C Loss probability: Where is obtained from the marking profile p x
Stepping back: Where are we? N+2 coupled equations solved numerically W=Window size, R = RTT, q = queue length, p = marking probability
Fluid Flow Model for a Network with Multiple Bottle-necks Scalable with link bandwidth and flow population within each class Network of M RED queues, K TCP classes, flows in class k
ODE Solving Methods Matlab ODE Solver Suit Error control, automatically adjusted step-size Cannot handle delayed differential equations Lack of flexibility of programming Computational Inefficiency Fixed Stepsize Runge-Kutta Method FFM: Time stepped numerical fluid model solver in C
Computation Cost: Matlab vs. FFM 80 TCP Classes x 20 RED Queues, Random Routing Matrix Matlab: 1572 seconds FFM: 5 seconds
Accuracy: FFM vs. NS Single Bottle Neck Network, 2 TCP Classes, Flows Per Class: 60 40 20
Account for Topology Fact: TCP sending rate will be reshaped in each queue it traverses C C Q1 Q2 Packet Loss Probability (I)Packet Loss Probability (II)
Account for Topology Keep track of each TCP class’s arrival rate and departure rate at each queue:
Account for Topology FFFM: Finer Fluid Flow Model Packet Loss Probability (I)Packet Loss Probability (II)
Refined Fluid Model Solver
Model Adjustment 1 In ns, actual packet drop/mark prob. is not equal to loss probability calculated from RED formula. Given a RED calculation value p, RED tries to make the interval between two drops/marks uniformly distributed in [1/p, 2/p] when “wait” option is on and [1, 1/p] when “wait” is off. Actual loss prob. is 2p/3 if “wait” on; 2p if “wait” off
Model Adjustment 1 With wait: Without wait:
Model Adjustment 2 NS won’t drop packet if the queue is empty Adjustment:
Other Adjustments TCP Newreno and SACK only backoff once for multiple losses within one window. Adjustment 1: Adjustment 2: At a given time, only TCP flows without packet loss will increase their congestion window.
{1,2} {1} {1,2,3} NS vs. FFFM
NS vs. FFFM (cont.) 3 TCP Classes, 8 RED Queues Scale bandwidth and flow population with k=1, 10, 50. Link Bandwidth: (black) 100M*k, (red) 10M*k Flows within each class: 40*k Class1 Class2 Class3
TCP Average Sending Rate, K=1 ClassNS Mean NS Std. FFF M Abs. Err Class1Class2 Class3
Queue Length, K=1 QueueNS MeanNS Std.FFFMAbs. Err Bottle-neck1 Bottle-neck2
TCP Average Sending Rate, K=10 ClassNS Mean NS Std. FFF M Abs. Err Class1 Class2 Class3
Queue Length, K=10 QueueNS MeanNS Std.FFFMAbs. Err Bottle-neck1Bottle-neck2
TCP Average Sending Rate, K=50 ClassNS Mean NS Std. FFF M Abs. Err Class1Class2 Class3
Queue Length, K=50 QueueNS MeanNS Std.FFFMAbs. Err Bottle-neck1 Bottle-neck2
TCP Average Sending Rate, K=100 ClassNS Mean NS Std. FFF M Abs. Err Class1Class2 Class3
Queue Length, K=100 QueueNS MeanNS Std.FFFMAbs. Err Bottle-neck1Bottle-neck2
Computation Savings
Net 0 Net 1 Net Net 3 Topology of a Large IP Network
Computation Cost
Integration with Packet Level Simulators Fluid flow model can provide delay and loss information for packets passing fluid network segments. If traffic from packet segments is negligible to fluid segment, fluid model can be solved independently. Simulated by FFFM Packet Level
Integration into NS FFFM has been integrated into NS by constructing Fluid Link and Fluid Network objects. Access Ns node Access Ns node Fluid Network Segment Fluid Network Topology of Hybrid NS Simulation Packet Network Segment
Hybrid NS Simulation Link Bandwidth: (black) 100M, (red) 15M 3 Background TCP Classes, 40 Flows per Class 3 Foreground TCP Sessions Class1 Session3 Session1 Class3 Class2 Session2 Fluid Network Segment Packet Level Nodes
Background TCP Average Window Size Class1 Class2Class3 hybrid packet
Foreground TCP Sample Path Session1 Session3 Session2
Bottle-neck Queue Evolution Bottle-neck1 Bottle-neck2 Simulation time: Hybrid: 8.4s, Packet: 29.7s CPU: 800MHz, Memory: 256M
Open Issues Time-out, Slow Start Finite duration flows, unresponsive flows High interaction between packet network segments and fluid network segments Limitations of mean value fluid model Verify results for large networks