Hybrid Systems Modeling of Communication Networks

1
Hybrid Systems Modeling of Communication Networks
Hybrid Control and Switched Systems

• João P. Hespanha
• University of Californiaat 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 similar flows for
  ensemble-average
• computationally very efficient (at least for
  first order statistics)

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)
• computationally efficient

?
provide information about both average, peak, and
instantaneous resource utilization(queues,
bandwidth, etc.)
5
Summary

• Modeling 1st pass Dumbbell topology simplified
  TCP
• Modeling 2nd pass General topology, TCP and UDP
  models
• Validation
• Simulation complexity

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
single queue
routing is trivial
B is unknown to the data sources and possibly
time-varying
7
Queue dynamics
f1
f1
r1 bps
queue
f2
r2 bps
f2
rate B bps
q( t ) queue size
f3
r3 bps
f3
When åf rf exceeds B the queue fills and data
is lost (drops)
) drop (discrete event relevant for
congestion control)
8
Queue dynamics
f1
f1
r1 bps
queue
f2
r2 bps
f2
rate B bps
q( t ) queue size
f3
r3 bps
f3
transition enabling condition
Hybrid automaton representation
exporteddiscrete event
9
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
wf effectively determines the sending rate rf
round-trip time
10
Window-based rate adjustment
wf (window size) number of packets that can
remain unacknowledged for by the destination
per-packet transmission time
sending rate
total round-trip time
propagationdelay
time in queueuntil transmission
This mechanism is still not sufficient to prevent
a catastrophic collapse of the network if the
sources set the wf too large
11
TCP congestion avoidance

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

TCP congestion avoidance
additive increase
multiplicative increase
disclaimer this is a very simplified version of
TCP Reno, better models later
12
TCP congestion avoidance

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

Queuing model
TCP congestion avoidance
rf
additive increase
RTT
drop
multiplicative increase
disclaimer this is a very simplified version of
TCP Reno, better models later
13
TCP congestion avoidance

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

TCP Queuing model
additive increase
multiplicative increase
disclaimer this is a very simplified version of
TCP Reno, better models later
14
Linearization of the TCP model
Time normalization define a new time variable
t by
1 unit of t 1 round-trip time
TCP Queuing model
additive increase
multiplicative increase
In normalized time, the continuous dynamics
become linear
15
Impact-map analysis
x1
x2
T
t0
t1
t2
t3
additive increase
additive increase
additive increase
multiplicative decrease
multiplicative decrease
continuous state before the kth multiplicative
decrease
multiplicativedecrease
x1
x2
additive increase
impact map
transition surface
state space
16
Impact-map analysis
x1
x2
T
t0
t1
t2
t3
additive increase
additive increase
additive increase
multiplicative decrease
multiplicative decrease
continuous state before the kth multiplicative
decrease
Theorem. The function T is a contraction. In
particular,

• Therefore
• xk ! x1 as k !1 x1 constant
• x( t ) ! x1 ( t ) as t ! 1 x1(t) periodic limit
  cycle

17
NS-2 simulation results
flow 1
n1
s1
flow 2
n2
s2
Bottleneck link
TCP Sinks
TCP Sources
Router R2
Router R1
20Mbps/20ms
flow 7
s7
n7
500
s8
n8
flow 8
400
Window and Queue Size (packets)
300
200
100
0
0
10
20
30
40
50
time (seconds)
18
Results
t0
t1
t2
t3
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
(well known TCP-friendly formula)
average throughput
19
2nd pass general topology
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
20
Routing
determines the sequence of links followed by each
flow
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
21
Routing
determines the sequence of links followed by each
flow
Multicast
Multi-path routing
22
Queue dynamics
link bandwidth
queue size due to flow f
total queue size
the packets of each flow are assumed uniformly
distributed in the queue
Queue dynamics
23
Queue dynamics
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
24
Drops events
When?
t0
t2
t1
packet size
total in-queue rate
total out-queue rate (link bandwidth)
25
Drops events
When?
t0
t2
t1
Which flows?
(drop tail dropping)
flow that suffers drop at time tk
26
Hybrid queue model
?-queue-not-full
transition enabling condition
discrete modes
?-queue-full
exporteddiscrete event
27
Hybrid queue model
?-queue-not-full
stochastic counter
discrete modes
Random Early Dropactive queuing
?-queue-full
28
Network dynamic Congestion control
routing
in-queue rates
sendingrates
out-queuerates
queue dynamics
end2end congestion control
TCP/UDP
drops
29
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
30
Slow start
In the beginning, pure AIMD takes a long time to
reach an adequate window size

1. Until a drop occurs (or a threshold ssthf is
   reached), double wf on each RTT
2. When a drop occurs, divide wf and the threshold
   ssthf by 2

slow-start
cong.-avoid.
especially important for short-lived flows
31
Fast recovery
After a drop is detected, new data should be sent
while the dropped one is retransmitted

1. During retransmission, data is sent at a rate
   consistent with a window size of wf /2

slow-start
cong.-avoid.
fast-recovery
(consistent with TCP-SACK for multiple
consecutive drops)
32
Timeouts
Typically, drops are detected because one
acknowledgment in the sequence is missing.
source
destination
1st packet sent
?
2nd packet sent
drop
3th packet sent
4th packet sent
2nd packet received ack. sent
3th packet received ack. sent
4th packet received ack. sent
three acks received out of order
drop detected, 1st packet re-sent
When the window size becomes smaller than 4, this
mechanism fails and drops must be detected
through acknowledgement timeout.

• 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

33
Fast recovery, timeouts, drop-detection delay
TCP SACK version
34
Network dynamic Congestion control
routing
in-queue rates
RTTs
sendingrates
out-queuerates
queue dynamics
end2end congestion control
drops
see SIGMETRICS paper for on/off TCP UDP model
35
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

36
Simulation traces

• single TCP flow
• 5Mbps bottleneck throughput
• no background traffic

ns-2
hybrid model
slow-start, fast recovery, and congestion
avoidance accurately captured
37
Simulation traces

• four competing TCP flow(starting at different
  times)
• 5Mbps bottleneck throughput
• no background traffic

ns-2
hybrid model
140
120
100
80
60
cwnd and queue size (packets)
40
20
0
0
2
4
6
8
10
12
14
16
18
20
time (seconds)
the hybrid model accurately captures flow
synchronization
38
Simulation traces

• four competing TCP flow(different propagation
  delays)
• 5Mbps bottleneck throughput
• 10 UDP background traffic(exp. distributed
  on-off times)

ns-2
hybrid model
CWND size of TCP 1 (Prop0.045ms)
CWND size of TCP 1 (Prop0.045ms)
CWND size of TCP 2 (Prop0.090ms)
CWND size of TCP 2 (Prop0.090ms)
CWND size of TCP 3 (Prop0.135ms)
CWND size of TCP 3 (Prop0.135ms)
CWND size of TCP 4 (Prop0.180ms)
CWND size of TCP 4 (Prop0.180ms)
Queue size of Q1
Queue size of Q1
Queue size of Q3
Queue size of Q3
0
39
Average throughput and RTTs

• four competing TCP flow(different propagation
  delays)
• 5Mbps bottleneck throughput
• 10 UDP background traffic(exp. distributed
  on-off times)

• 45,90,135,180ms propagation delays
• drop-tail queuing
• 5Mbps bottleneck throughput
• 10 UDP on/off background traffic

Thru. 1 Thru. 2 Thru. 3 Thru. 4 RTT1 RTT2 RTT3 RTT4
ns-2 1.873 1.184 .836 .673 .0969 .141 .184 .227
hybrid model 1.824 1.091 .823 .669 .0879 .132 .180 .223
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
40
Empirical distributions
0.15
0.18
hybrid model
ns-2
0.16
0.14
0.1
0.12
0.1
probability
probability
0.08
0.05
0.06
0.04
0.02
0
0
0
10
20
30
40
50
60
70
0
10
20
30
40
50
60
70
cwnd queue size
cwnd queue size
the hybrid model captures the whole distribution
of congestion windows and queue size
41
Execution time
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)