ESPRES:

Easy Scheduling and

Prioritization for SDN

Peter Perešíni @ EPFL Maciej Kuzniar @ EPFL, Marco Canini @ UCLouvain,

Dejan Kostić @ IMDEA Networks

Big Networks = Big Updates

Topology changes

Traffic Engineering

Policy changes

2

Network updates touch many flows

Meanwhile:

Control plane is not fast enough

Big Updates Take Time

Big updates (many rule changes)

+

Slow rule installation speed

=

Updates take a long time

3

Our Work - ESPRES

• Transparent layer between ctrl and switches

• Goal = optimize big update installation

o Complete installing majority of flows sooner

o Decrease mid-update switch rule overhead

o Minimize flow disruption times

4

Challenges

5

2

3

5 4

Switch message queue

1

Flow update requires all

its rules to complete

1.

Dependencies might

hold rule installation

2.

Cannot reorder

message queue

3.

Switches have different

rule installation speeds

Ingress rule depends on

core being installed

ingress

ESPRES Design

Two key ideas:

Manage switch message queue

Schedule rule installations carefully

6

Managing Switch Message Queue

Switch message queue In-ESPRES “queue”

● Short

● Fixed order

● Arbitrary long

● Flexible ordering

7

Managing Switch Message Queue

When switch message queue has room

1. Determine ready operations

2. Send according to the scheduler

8

Scheduling from 10,000 feet

Main highlights:

1. Group operations per flow

2. Order flows

9

Grouping Rule Installations

Arbitrary rule installation Grouping rules by flows

Switch 1:

Switch 2:

Flow completion

determined by last op

Group related operations and schedule

them in parallel

10

Time Time

Time Time

Ordering Flows

4 + 5

avg=4.5

1 + 5

avg=3

11

Schedule 1: Schedule 2:

Finish times:

Ordering makes a difference

Different goals ⇒ different ordering

• Finishing flows sooner ⇒ Shorter updates first

• Reduce rule overhead ⇒ Updates removing rules

first

Evaluation

• ESPRES prototype in Python

• Use Mininet to emulate network

o Patch Reference Switch implementation ---

Throttle to 40 updates/sec [1]

[1] Danny Yuxing Huang, Kenneth Yocum, and Alex C. Snoeren.

High-Fidelity Switch Models for Software-Defined Network Emulation.

In HotSDN 2013.

12

1000 new flows; 18 switches (IBM backbone topo)

Finishing Majority of Flows Sooner

We reduce completion time

for ½ of flows by ≥40%

ESPRES near optimal

schedule (ILP)

13

ESPRES Summary

• Big updates + slow rule installations need

update installation strategy

• ESPRES based on two ideas

o Managing switch message queue

o Scheduling rule installation

Schedule, you should!

14

Backup slides

Is next switch generation fine?

PICA8

• circa 1000 flows/sec

• “4000 flows not enough for some clients”

• announced P-3297

o 8000 flows

o if performance similar to previous models:

➢ at least 8-10s to install full flow table

Is next switch generation fine?

• Big flow churn may still require scheduling

Work in progress

• Stream of big network updates

o some are high-priority (failure recovery)

Evaluation: Lowering Rule Overhead

FatTree (20 switches), update 370 flows,

use consistent update (2-phase commit)

Method Max per-switch rule overhead

Naive 76%

Incremental Consistent Updates [1] 16.5% (for 4 rounds)

ESPRES/overhead 10.2%

Dependencies

sw 1 sw 2 sw 3 h 2 h 1

Fwd:

h2

Single flow update touches

many switches

Inter-switch dependencies

(e.g. core before ingress)

Fwd:

sw 3

Fwd:

sw 2