Peter Perešíni EPFL Research Track Session Part 3 ONS2015: http://bit.ly/ons2015sd ONS Inspire! Webinars: http://bit.ly/oiw-sd Watch the talk (video) on ONS Content Archives: http://bit.ly/ons-archives-sd

3. ESPRES:
Easy Scheduling and
Prioritization for SDN
Peter Perešíni @ EPFL
Maciej Kuzniar @ EPFL, Marco Canini @ UCLouvain,
Dejan Kostić @ IMDEA Networks

4. Big Networks = Big Updates
Topology changes
Traffic Engineering
Policy changes
2
Network updates touch many flows

5. 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

6. 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

7. Challenges
5
2
3
54
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

8. ESPRES Design
Two key ideas:
Manage switch message queue
Schedule rule installations carefully
6

9. Managing Switch Message Queue
Switch message queue In-ESPRES “queue”
● Short
● Fixed order
● Arbitrary long
● Flexible ordering
7

10. Managing Switch Message Queue
When switch message queue has room
1. Determine ready operations
2. Send according to the scheduler
8

11. Scheduling from 10,000 feet
Main highlights:
1. Group operations per flow
2. Order flows
9

12. 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

13. TimeTime
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

14. 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

15. 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

16. 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

17. Backup slides

18. 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

19. 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)

20. 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%

21. Dependencies
sw 1 sw 2 sw 3 h 2h 1
Fwd:
h2
Single flow update touches
many switches
Inter-switch dependencies
(e.g. core before ingress)
Fwd:
sw 3
Fwd:
sw 2