performance driven abstraction and optimization for sdn
TRANSCRIPT
JIVE Performance Driven Abstraction and
Optimization for SDN ONS 2014 Research Track
Aggelos Lazaris (USC), Daniel Tahara (Yale),
Xin Huang (CYAN), Li Erran Li (Bell Labs), Andreas Voellmy
(Yale), Y. Richard Yang (Yale), Minlan Yu (USC)
Motivation
• SDN objectives
o simpler and easier programming of networks
o reduce controller-switch dependency
➢ rely on a single switch model
• does not resolve the diversity of
switch implementations, capabilities, and
behaviors
o e.g. TCAM size, TCAM management
Motivation
SW
TCAM TCAM TCAM Full
low throughput
Vendor A Vendor B
Insertion of the same sequence of rules results in low throughput in
the first switch, and rule rejection in the second switch
TCAM Full
flow k
rule installation
x rule rejection
Motivation
SW
TCAM TCAM Full
low throughput
Vendor A
Insertion of the same sequence of rules results in low throughput in
the first switch, and high throughput in the second switch
flow k
rule installation
SW
TCAM TCAM Full
high throughput
Vendor C
flow k
rule installation
FIFO Traffic Dependent
Switch Diversity
• Diversity in flow tables types and table
sizes
o software tables, hardware tables (TCAM), or both
o various TCAM sizes
369 - ~10K rules
table size might vary depending on the matching
fields • L2/L3, L2+L3
Switch Diversity
• Diversity in flow installation behaviors, and
data plane delay using different flow tables
o 3 (or 2) tier delay observed
fast path • packets matching rules in the TCAM
slow path (in some switches) • packets matching rules in the software table
control path • packets matching no rules
Switch Diversity
• Diversity in controller-switch channel
performance
o delay to update rules << delay to install new rules
o delay to install rules in descending priority order >>
delay to install rules in ascending priority order
up to 6 times smaller
JIVE
• Objectives o reveal switch capabilities
o introduce abstractions to unify switch diversity
o API
• Design o infer JIVE patterns
o optimization, scheduling
JIVE Patterns
• JIVE pattern is a sequence of flow_mod
commands, and a corresponding data
traffic pattern o infer patterns
infer flow table size
infer cache algorithms
JIVE Abstractions
• Unify switch diversity o abstract 2-layer architecture
different flow table sizes
different installation behaviors
• expose JIVE functionality to the
application through an API
e.g. setup latency, bandwidth
JIVE Optimization
• Scheduling & Routing
o compute and set up a path for each request
o expression Rewriting
rewrite the flow rules such that we minimize
the installation time • e.g. ascending priority, topological ordering
potentially introduce additional paths where a
dummy flow entry is installed and later
modified • can lead to a shorter path
JIVE Architecture
JIVE Evaluation
Installation time of
1K Classbench
rules
Up to 12X
improvement
Summary
• JIVE
o abstractions
unify switch diversity
API
o optimization using expression rewriting and
scheduling
• Future directions o better understanding the features of the various
hardware switches (e.g. multiple tables, etc.)
Supporting Slides
JIVE
• Components
o JIVE Score and Pattern Database
JIVE pattern: sequence of OpenFlow
flow_mod commands and a corresponding
data traffic pattern
o Probing Engine
o Switch Inference Engine
o Network Scheduler
o JIVE API
Switch Architecture
• Different vendor
implementations at
the proprietary layer
can affect switch
performance o both at control and
data plane
OF Switch Software Stack Architecture
Switch Diversity
• Diversity in o flow tables and table sizes
Switch
User space SW Tables TCAM/Kernel Tables
L2/L3 L2+L3 L2/L3 L2+L3
OVS unlimited unlimited unlimited unlimited
Switch 1 unlimited unlimited 4K 2K
Switch 2 None None 2560 2560
Switch 3 None None 767 369
Switch Diversity
• Diversity in o flow installation behaviors
o delay using different flow tables
Switch Diversity
• Diversity in o controller-switch channel performance
Openflow Limitations • Newer versions of OpenFlow allow
switches to report certain capabilities
but reports can be inaccurate
• Max flow entries is approximate
o depends on the matching fields
IPv4 vs. IPv6
• Important properties are not reported
SW flow table ?
caching policy ?