Performance Driven Abstraction and Optimization for SDN

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

End of Presentation

Thank You!

Email: [email protected]

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 ?