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

Hybrid Systems Modeling of Communication Networks

João P. Hespanha

University of Californiaat 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 dynamicseven for a small number of flow

Summary

• Modeling 1st pass: Dumbbell topology & simplified TCP

• Modeling 2nd 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

r1 bps

r2 bps

r3 bps

rate · B bps

queue

f1

f2

f3

f1

f2

f3

B is unknown to the data sources and possibly time-varying

Queue dynamics

When f rf exceeds B the queue fills and data is lost (drops)

) drop (discrete event – relevant for congestion control)


r1 bps

r2 bps

r3 bps

rate · B bps

queue

f1

f2

f3

f1

f2

f3

Queue dynamics

Hybrid automaton representation:


r1 bps

r2 bps

r3 bps

rate · B bps

queue

f1

f2

f3

f1

f2

f3

transition enabling condition

exporteddiscrete event

Window-based rate adjustment

1st packet sent

e.g., wf = 3

t

2nd packet sent3rd packet sent 1st packet received & ack. sent

2nd packet received & ack. sent3rd packet received & ack. sent1st ack. received )

4th packet can be sent

t

source f destination f

wf effectively determines the sending rate rf :

round-trip time

t0

t1

t2

t3

0

1

2

wf (window size) ´ number of packets that can remain unacknowledged for by the destination

Window-based rate adjustment

wf (window size) ´ number of packets that can remain unacknowledged for by the destination

´ sending rate

totalround-trip

time propagationdelay

per-packettransmission time

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

queuegets full

longerRTT

ratedecreases

queuegets empty

negative feedback

TCP congestion avoidance

1. While there are no drops, increase wf by 1 on each RTT (additive increase)

2. When a drop occurs, divide wf 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…


additiveincrease

multiplicative increase






Queuing model TCP congestion avoidance

drop

RTT

rfadditiveincrease







TCP + Queuing model

additiveincrease


Linearization of the TCP model

TCP + Queuing model

additiveincrease


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

t0 t1 t2 t3

´ continuous state before the kth multiplicative decrease

x1 x2T

state space

x1

x2

impact map

additive increase additive increase

additive increase

multiplicative decrease multiplicative decrease

transition surface

multiplicativedecrease

Impact-map analysis

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

additive increase

t0 t1 t2 t3

x1 x2T



´ continuous state before the kth multiplicative decrease

NS-2 simulation results

0

100

200

300

400

500

0 10 20 30 40 50

Win

dow

and

Que

ue S

ize

(pac

kets

)

time (seconds)

window size w1window size w2window size w3window size w4window size w5window size w6window size w7window size w8queue size q

Router R1

Router R2

TCP Sources TCP SinksBottleneck link

20Mbps/20ms

flow 1

flow 2

flow 7

flow 8

n1

n2

n7

n8

s1

s2

s7

s8

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

t0 t1 t2 t3



2nd pass – general topology

network dynamics (queuing & routing)

congestion control

server

client

data

acks

A communication network can be viewed as theinterconnection of several blocks with specific dynamics

b) Queuing:

in-queuerate

out-queuerate queue size

c) End2end cong. control

serversending

rateacks

& drops

a) Routing:

in-noderate

out-noderates

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'

indexes and ’ determined by routing tables

Routing

Multicast Multi-path routing

n’

n'

n''

”

n1’

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


…drop rates

Drops events

t0 t2t1

total in-queue ratepacket size

total out-queue rate(link bandwidth)


…drop rates

When?

Drops events

Which flows?

t0 t2t1

flow that suffers drop at time tk

(drop tail dropping)

When?


…drop rates

Hybrid queue model

-queue-not-full

-queue-full

transition enabling condition

exporteddiscrete event

discrete modes

Hybrid queue model

Random Early Dropactive queuing

stochastic counter-queue-not-full

-queue-full

discrete modes

Network dynamic & Congestion control

routing

queue dynamics

sendingrates

drops

out-queuerates

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



(congestion controller constantly probe the network for more bandwidth)

importeddiscrete event

Slow start

3. Until a drop occurs (or a threshold ssthf is reached), double wf on each RTT4. When a drop occurs, divide wf and the threshold ssthf 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 wf /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

3th packet received & ack. sent

1st packet sent2nd packet sent

4th packet sent

Timeouts

6. When a drop is detected through timeout:a. the slow-start threshold ssthf 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.

2nd packet received & ack. sent

4th packet received & ack. sent

source destination

three acks received out of order

drop3th packet sent

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.

Fast recovery, timeouts, drop-detection delay…

TCP SACKversion

Network dynamic & Congestion control

routing

queue dynamics

sendingrates

drops

out-queuerates

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-topologydumbbell

Simulation traces

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

ns-2

0

140

120

100

80

60

40

20

0 2 4 6 8 10 12 14 16 18 20

cwnd

and

que

ue s

ize

(pac

kets

)

time (seconds)

cwnd of TCP 1queue size

0

140

120

100

80

60

40

20

0 2 4 6 8 10 12 14 16 18 20

cwnd

and

que

ue s

ize

(pac

kets

)

time (seconds)

cwnd of TCP 1queue 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

0

140

120

100

80

60

40

20

0 2 4 6 8 10 12 14

16 18 20

cwnd

and

que

ue s

ize

(pac

kets

)

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

0

140

120

100

80

60

40

20

0 2 4 6 8 10 12 14 16 18 20

cwnd

and

que

ue s

ize

(pac

kets

)

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-2hybrid model

Simulation traces

CWND size of TCP 1 (Prop=0.045ms)




Queue size of Q1

Queue size of Q3

0

140

120

100

80

60

40

20

0 2 4 6 8 10 12 14 16 18 20

cwnd

and

que

ue s

ize

(pac

kets

)

time (seconds)





Queue size of Q1

Queue size of Q3

0

140

120

100

80

60

40

20

0 2 4 6 8 10 12 14 16 18 20

cwnd

and

que

ue s

ize

(pac

kets

)

time (seconds)

ns-2hybrid 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. 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

• 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 model ns-2

the hybrid model captures the whole distribution of congestion windows and queue size

0 10 20 30 40 50 60 700

0.05

0.1

0.15

prob

abil

ity

0 10 20 30 40 50 60 700

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

cwnd & queue sizepr

obab

ilit

y

CWND of TCP1CWND of TCP2CWND of TCP3CWND of TCP4Queue 3

CWND of TCP1CWND of TCP2CWND of TCP3CWND of TCP4Queue 3

cwnd & queue size

Execution time

0.1

1

10

100

1000

10000

1 10 100 1000

bottleneck bandwidth [Mbps]

execution tim

e for

10m

in

of sim

ula

tion tim

e

[sec]

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)

Documents

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