TimedConsistent16x9.pdf

Timed Consistent Network Updates

Tal Mizrahi, Efi Saat, Yoram Moses

Technion – Israel Institute of Technology

Outline

•

Background

•

Using time for consistent updates

•

Worst-case update duration

•

An inconsistency metric

•

Conclusion

Imagine… what if

Time

was on our side

Controller

Synchronized

clocks

A protocol allowing the controller to

schedule

network updates

Stop imagining:

Time

is

on our side

4 Timed Consistent Network Updates

Controller

Synchronized

clocks

A protocol allowing the controller to

schedule

network updates

Precision Time Protocol (PTP)

[

IEEE 1588

‘08]

Scheduled Bundles [

Time4

‘15]

Outline

•

Background

•

Using time for consistent updates

•

Worst-case update duration

•

An inconsistency metric

•

Conclusion

Example: Ordered Path Update

0

S

S

S

S

S2 S1

S3 S4

S2 S1

S3 S4

S2 S1

S3 S4

S2 S1

S3 S4

1

2

3

0. The ‘before’ configuration.

1. Controller updates S

.

2. Controller updates S

.

3. Controller updates S

.

Sequential update approaches:

[Dionysus ‘14]

[zUpdate ‘13]

[Vanbever et al. ‘11]

[Francois et al. ’07]

S

S

S

S

after

before

wait…

wait…

X

Simultaneous Update?

En-route packets run into a ‘black hole’.

Not consistent!

7 Timed Consistent Network Updates

S2 S1

S3 S4

S2 S1

S3 S4

S2 S1

S3 S4

S2 S1

S3 S4

Timed

Ordered Path Update

-

The controller sends timed update messages to S

1

, S

2

, S

3

.

-

Scheduled updates occur at times T

1

, T

2

, T

3

.

T

1

T

2

T

3

Controller does not need to wait between steps!

8 Timed Consistent Network Updates

S2 S1

S3 S4

S2 S1

S3 S4

S2 S1

S3 S4

S2 S1

Example: Two-phase Update

S

S

S

S

•

Two-phase update [Reitblatt et al. ’12].

•

S

2

attaches version tags to packets.

•

‘

before

’ / ‘

after

’.

•

Indicate distribution tree.

•

Guarantees

per-packet consistency

.

Multicast tree update

S

S

S

S

after

before

Two-phase Updates

0

S2 S1

S3 S4

S2 S1

S3 S4

S2 S1

S3 S4

S2 S1

S3 S4

1

2

3

0. The ‘

before

’ configuration.

1. Controller sends ‘

after

’ configuration to S

(subject to ‘

after

’ version tag).

2. Controller updates S

to:

- use ‘

after

’ configuration.

- send ‘

after

’ version tag.

3. Controller removes the ‘

before

’ configuration from S

(garbage collection).

wait…

wait…

X

Timed Two-phase Updates

-

The controller sends timed update messages to S

1

, S

2

.

-

Scheduled updates occur at T

1

, T

2

, T

3

.

T

1

T

2

T

3

11 Timed Consistent Network Updates

S2 S1

S3 S4

S2 S1

S3 S4

S2 S1

S3 S4

S2 S1

Outline

•

Background

•

Using time for consistent updates

•

Worst-case update duration

•

An inconsistency metric

•

Conclusion

Update Duration

S2 S1

S3 S4

S2 S1

S3 S4

S2 S1

S3 S4

T

1

T

2

T

3

Update Duration = T

3

-T

1

During the update duration S

1

stores both the ‘before’

and ‘after’ configurations.

Short update duration

Excess memory used for short time.

More updates per second.

Scalability.

X

Worst-case Update Duration

Lemma: the worst-case update duration of a two-phase

untimed

update procedure with a garbage collection phase is:

(𝑁

1

+𝑁

2

+ 𝑁

𝐺

− 3) ∙ ∆ + max⁡(∆, 𝐷

𝑐

) + max⁡(∆, 𝐷

𝑐

+ 𝐷

𝑛

) + 𝐷

𝑐

Lemma: the worst-case update duration of a two-phase

timed

update procedure with a garbage collection phase is:

𝐷

𝑛

+ 3 ∙ 𝛿

Notations

Dn – network delay.

Dc– controller-to-switch delay.

Δ – controller inter-message delay.

δ – scheduling error.

Nj – no. of switches updated in phase j.

NG1 – no. of switches updated in the garbage

collection phase.

Proportional to the number of switches.

Independent of the number of switches.

Scalable!

X

How

accurately

can updates be scheduled?

T

time

T

scheduling error (δ)

Clock error

typical:

PTP < 1 μsec

NTP < 1 msec

Flow installation

latency variation

Scheduled time

Actual time

Installation Latency Variation

•

Untimed updates: high latency installation variation.

•

Timed updates: installation latency has lower variation.

–

Predictable.

–

Resources can be provisioned.

–

Real-time programming practices.

–

[

TimeFlip

’15] using timestamp-based TCAM lookups: δ < 1 μsec.

T

time

T

scheduling error (δ)

16 Timed Consistent Network Updates

Lemma: if the

scheduling error

is lower than the

installation

Evaluation Method

•

DeterLab testbed.

•

50 nodes (Linux machines).

•

Software OpenFlow switches (OFSoftSwitch).

–

With Scheduled Bundle support.

–

Dpctl as the controller.

•

Clock synchronization using [ReversePTP ‘14].

Leaf-spine topology

3 Provider network topologies

(

http://topology-zoo.org

)

Worst-case Update Duration

Proportional to the

number of switches.

X

Independent of the

number of switches.

Timed updates are

scalable!

Outline

•

Background

•

Using time for consistent updates

•

Worst-case update duration

•

An inconsistency metric

•

Conclusion

Long-tailed Latency

S2 S1

S3 S4

S2 S1

S3 S4

S2 S1

S3 S4

1

2

3

Installation latency

Installation latency

+

network latency

•

Latencies are typically long-tailed / unbounded.

•

Worst-case latency is unbounded



wait forever?

•

No! Wait

enough time

for

near

consistency.

Long tail

X

The Inconsistency Tradeoff

inconsistency

update

duration

•

Wait

enough time

for

near

consistency.

•

How long is

enough time

? How do we quantify

near

?

An Inconsistency Metric

f – test flow: a set of identical packets at constant rate.

U – update.

𝐼 𝑓, 𝑈 = ⁡

𝑛(𝑓, 𝑈)

𝑅(𝑓)

Inconsistency [sec]

No. of inconsistent

packets.

Rate [pkts/sec]

X

Time as a Consistency Knob

Consistency

Inconsistency < 1 ms

Inconsistency = 25 ms

T

-T

Inconsistency < 0.1 ms

Outline

•

Background

•

Using time for consistent updates

•

Worst-case update duration

•

An inconsistency metric

•

Conclusion

Conclusions

Latencies are

long-tailed

Inconsistency is

inevitable

We defined an

Inconsistency

metric

Time: a knob for tuning

consistency

Timed updates

scale

better

Time

is

on our side!

Timed updates

are

predictable

Worst-case analysis

of

Update Duration

Timed vs. untimed

consistent updates

Timed updates:

send-and-forget

References

27 Timed Consistent Network Updates

[1] T. Mizrahi, E. Saat, Y. Moses, "Timed Consistent Network Updates", ACM SIGCOMM Symposium on SDN Research (SOSR), 2015. (http://tx.technion.ac.il/~dew/TimedConsistentSOSR.pdf)

[2] T. Mizrahi, O. Rottenstreich, Y. Moses, "TimeFlip: Scheduling Network Updates with Timestamp-based TCAM Ranges", IEEE INFOCOM, 2015. (http://tx.technion.ac.il/~dew/TimeFlipINFOCOM.pdf)

[3] T. Mizrahi, Y. Moses, "Time-based Updates in Software Defined Networks", the second workshop on hot topics in software defined networks (HotSDN), 2013. (http://tx.technion.ac.il/~dew/TimeSDN.pdf)

[4] T. Mizrahi, Y. Moses, "Time4: Time for SDN", arXiv preprint arXiv:1505.03421, 2015. (http://tx.technion.ac.il/~dew/Time4TR.pdf)

[5] Open Networking Foundation, OpenFlow switch specification, Version 1.5.0, 2015.

(https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.5.0.noipr.pdf) [6] Open Networking Foundation, OpenFlow extensions 1.3.x package 2, 2015.

(https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-extensions-1.3.x-pack2-noipr.zip) [7] X. Jin, H. H. Liu, R. Gandhi, S. Kandula, R. Mahajan, J. Rexford, R. Wattenhofer, and M. Zhang, “Dionysus: Dynamic scheduling of network updates,” ACM

SIGCOMM, 2014.

[8] H. H. Liu, X. Wu, M. Zhang, L. Yuan, R. Wattenhofer, and D. Maltz, “zUpdate: updating data center networks with zero loss,” ACM SIGCOMM, 2013.

[9] L. Vanbever, S. Vissicchio, C. Pelsser, P. Francois, and O. Bonaventure, “Seamless network-wide igp migrations,” ACM SIGCOMM Computer Communication Review, 2011.

[10] P. Francois and O. Bonaventure, “Avoiding transient loops during the convergence of link-state routing protocols,” IEEE/ACM Transactions on Networking, 2007.