Transcript Stochastic Modeling of Delay in OpenFlow Switches v2x

Stochastic Modeling of Packet
Delay in OpenFlow SDNs
Dr. Muhammad Usman Ilyas
Post-doc + PhD + MS (Michigan State U), MS (LUMS), BE (NUST)
[email protected], [email protected]
Applied Network & Data Science Research (AN-DASH) Lab
School of Electrical Engineering and Computer Science (SEECS)
National University of Science and Technology (NUST)
Islamabad, Pakistan
1
Team Members
Uzzam Javed
MS Student
SEECS-NUST, Pakistan
Azeem Iqbal
MS Student
SEECS-NUST, Pakistan
2
Center of NUST campus
3
School of Electrical Engineering & Computer Science
SEECS
4
School of Electrical Engineering & Computer Science
SEECS
5
nust.edu.pk
6
seecs.nust.edu.pk
7
andash.seecs.nust.edu.pk
8
Ongoing Research projects at ANDASH Lab
Networking and Security
1. Packet delay model in OpenFlow SDNs (OF@TEIN)
2. OpenStack fault resilience to network errors
 Microsoft Research – Azure 4 research
.
9
Ongoing Research projects at ANDASH Lab
Networking and Security
1. Packet delay model in OpenFlow SDNs (OF@TEIN)
2. OpenStack fault resilience to network errors
 Microsoft Research – Azure 4 research
3.
Anomaly detection in OpenStack
 PLUMgrid Inc., Sunnyvale, CA
4.
Link de-anonymization in Ims (Tor network)
Cloud-mobile Applications
1. Mobile crowdsensing to map road and traffic conditions
 Microsoft Research – Azure 4 research
 http://craters.azurewebsites.net
2.
Activity recognition and tracking by smartphones
 HEC funding
3.
MAC protocol for vehicular networks (SKKU, Suwon, S. Korea)
Social media / networks
1. Word cloud segmentation based on sub-topics
10
Network Planes
 Data Plane
 Forward traffic according to the logic implemented at the control plane.
11
Network Planes
 Control Plane
 Control plane is the brain of the network, contains logic for forwarding traffic.
 Control plane of each switch learns structure of network by communicating
with peer planes in connected switches.
Control
Plane
Control
Plane
Control
Plane
Control
Plane
Control
Plane
12
Network Planes
 Management Plane
 Used to manage and configure network devices.
Control
Plane
Control
Plane
Control
Plane
Control
Plane
Control
Plane
13
Implementation in Traditional Networks
 In traditional networks all three planes reside within the firmware of
switches and routers.
 Makes the management of large networks difficult.
14
OpenFlow
 Software Defined Networking (SDN) is an paradigm that decouples
control plane from data plane.
 Provides a control plane abstraction for the whole network (AS).
Net
Apps
Net
Apps
Net
Apps
Northbound API
Network Controller
OpenFlow protocol
Secure Channel
Secure Channel
Secure Channel
Flow Table Pipeline
Flow Table Pipeline
Flow Table Pipeline
Data Plane
Data Plane
Data Plane
16
OpenFlow
 Virtually separated planes interact through different APIs (interfaces).
 OpenFlow is an interface to communicate between the control plane
and the data plane promoted by Open Networking Foundation (ONF).
Net
Apps
Net
Apps
Net
Apps
Northbound API
Network Controller
OpenFlow protocol
Secure Channel
Secure Channel
Secure Channel
Flow Table Pipeline
Flow Table Pipeline
Flow Table Pipeline
Data Plane
Data Plane
Data Plane
17
Separation of Control Plane across H/W Comp.
Install table
entry, send
packet
SDN
Controller
Most features
go here
This gets smaller,
turns into
controller to
switch chip
translator
Control
Plane CPU
Packet /
Network
Processor
0C->p3
Table miss,
send to
controller
dst
port
0E
5
0A
1
0C
3
0A->0C
0A->0E
http://colindixon.com/wp-content/uploads/2014/05/odl-meetup.pdf
18
Advantages of SDN
 Enables innovation by providing freedom from vendor lock-in.
 Improves network visibility by providing a global view.
Traffic steering.
Security enforcement.
 Makes network management simple
 Reduce operational cost of network.
 Simpler switches.
19
OpenFlow Switch Entry
http://www.slideshare.net/Cameroon45/ppt-4515906
21
Research Objectives
 Analyzing the performance of OpenFlow SDN.
 Model
A) packet processing delay of a single OpenFlow SDN router
B) end-to-end path delay in OpenFlow SDNs.
 Assess the accuracy of delay modeling in mininet.
23
Prior State-of-the-art

Limitation of Queuing Theory approach:
 Assumes Poisson arrival process for packets and
exponential distribution for traffic.
 In reality Ethernet traffic has been found to be selfsimilar(fractal) in nature.
 Cannot be accurately modeled with Poisson process.
 Leland, Will E., et al. "On the self-similar nature of Ethernet traffic
(extended version)." Networking, IEEE/ACM Transactions on 2.1
(1994): 1-15.
24
Prior State-of-the-art
 Some works used simulations to verify the derived model.
 Interaction of multiple switches were not considered.
 Limitation of Network Calculus approach used:
 A relatively new alternative to classical queueing theory.
 It has two branches Deterministic Network Calculus (DNC) and Stochastic
Network Calculus (SNC).
 DNC only provides worst-case bounds on performance metrics. The
models build using Network Calculus used DNC, whose result are far
from practical use.
Ref: Ciucu, Florin, and Jens Schmitt. "Perspectives on network calculus:
no free lunch, but still good value." Proceedings of the ACM SIGCOMM
2012 conference on Applications, technologies, architectures, and
protocols for computer communication. ACM, 2012.
25
Prior State-of-the-art
 Jarschel, Michael, et al. "Modeling and performance
evaluation of an openflow architecture." Proceedings of the
23rd international teletraffic congress. International
Teletraffic Congress, 2011.
 Proposed a basic model for forwarding speed and blocking
probability for an OpenFlow switch and a controller using queueing
theory.
 Azodolmolky, Siamak, et al. "An analytical model for
software defined networking: A network calculus-based
approach." Global Communications Conference
(GLOBECOM), 2013 IEEE. IEEE, 2013
 Delay and queue length boundaries are modeled using Network
Calculus.
27
Prior State-of-the-art
 Bozakov, Zdravko, and Amr Rizk. "Taming SDN controllers in
Heterogeneous hardware environments." Software Defined
Networks (EWSDN), 2013 Second European Workshop on.
IEEE, 2013.
 A simple model for control message processing using Network
Calculus.
 Chilwan, Ameen, et al. "ON MODELING CONTROLLERSWITCH INTERACTION IN OPENFLOW BASED SDNS.”
 A more accurate model using queueing theory but evaluated using
simulations.
28
Measurements
 Controlled traffic generation using traffic generator.
 Delay measurements will include the following components:
 Clock synchronization ensured using NTP
1.
2.
3.
4.
Processing delay on a each switch.
Queuing delay on each switch.
Transmission delay on each switch.
Link propagation delay.
29
Evaluation Parameters
Following possible measurement scenarios will be considered:
 Based on traffic:
Packet size
Traffic distribution
Rate
TCP/UDP
Variable switching load
 OpenFlow Parameters:
Single field matching
Multiple field matching
Matching on a range of IP's/Port numbers
Changing the number of actions
Hard time out/ Soft time out
Comparison between reactive and proactive forwarding.
30
Platform 1 - Mininet
C0
Controller
 SDN emulator
 To study the delay in OpenFlow
SDN switches in an SDN
emulator.
OpenFlow
Switch
H1
S1
H2
Virtual Hosts
Mininet Virtual Machine
31
Platform 2 – Laboratory setup
 Experimentation on lab scale testbed of OpenFlow SDN switches.
 Enabling OpenFlow on a Mikrotik RouterBoard 750GL router, for
experimentation.
Controller
OpenFlow
switches
Mikrotik RouterBoard 750GL
switches
Host 1
Host 2
32
Platform 3 – GENI Testbed
 An Internet scale network testbed infrastructure, spanning across the
US.
 Experimentation on widely distributed resources.
 To explore behavior of OpenFlow switches at scale.
http://groups.geni.net/geni/wiki/GeniNewcomersWelcome
33
Platform 4- OF@TEIN
Risdianto, Aris Cahyadi, and JongWon Kim. "Prototyping Media Distribution
Experiments over OF@ TEIN SDN-enabled Testbed." Proceedings of the Asia-Pacific
Advanced Network 38 (2014)
34
Platform 4- OF@TEIN
 OF@TEIN is a an OpenFlow enabled testbed spread over seven
countries.
 Project was launched in July 2012, through Korean Government
funding.
 Deployed on TEIN4 (Trans-Eurasia Information Network 4).
 Managed by
 Consortium of Korean universities
 International collaboration sites
 Led by Gwangju Institute of Science & Technology (GIST), S. Korea.
35
Some Initial Results for Single Switch
 Three platforms were used to analyze the round trip time delay.
 OF@TEIN results pending due to ongoing migration to OpenStack.
 Using Distributed Internet Traffic Generator (D-ITG) for all platforms.
 1,000,000 packets were generated with a constant rate of 10,000
pkt/s from one host to another.
 Size of packet was kept constant to 1,500 bytes.
 TCP protocol was used.
 All platforms were using Open vSwitch (OVS) and OpenFlow 1.0
enabled switches.
 Each platform was tested for reactive and proactive forwarding
scenario.
36
Single Router Delay
37
Mininet
 Traffic was generated on a single switch with external controller
(POX).
 Timeout for switch’s flow table entry was set to 1 second.
 OpenFlow switch was invoked as L2 learning switch through
controller.
38
Mininet
39
Mininet
 Traffic was generated on a single switch.
 Entries on the switch were pre-loaded before the flows were
generated.
40
Mininet
41
Laboratory Setup
 Traffic was generated on a single switch, MikroTik RouterBoard
750GL.
 Controller (POX) was running in one system, which invoked OpenFlow
switch to act as a L2 learning switch.
 Timeout for flow table entry was set to 1 second.
42
Laboratory Setup
43
Laboratory Setup
 Traffic was generated on a single switch, MikroTik RouterBoard
750GL.
 The entries on the switch were proactively added before the flows
were generated.
44
Laboratory Setup
45
GENI Testbed
 Traffic was generated on a single switch on GENI testbed.
 Controller (POX) was running in Utah, while switch and hosts were
located in California.
 Timeout for switch’s flow table entry was set to 1 second.
 OpenFlow switch was invoked to act as L2 learning switch.
46
GENI Testbed
47
GENI Testbed
 Traffic was generated on a single switch on GENI testbed.
 The switch and hosts were all located in California.
 The entries on the switch were proactively added before the flows
were generated.
48
GENI Testbed
49
End-to-end Delays
50
Some Initial Results for End-to-End
measurements
 Three platforms were used to analyze the round trip time delay.
 1,000,000 packets were generated with a constant rate of 10,000
pkt/s from one host to another.
 Size of packet was kept constant to 1,500 bytes.
 TCP protocol was used.
 All platforms were using Open vSwitch (OVS) enabled switches.
51
Mininet
 Traffic was generated on two switches with external controller(POX).
 Timeout for switch’s flow table entry was set to 1 second.
 OpenFlow switch was invoked as L2 learning switch through
controller.
52
Mininet
53
Mininet
 Traffic was generated on two switches.
 The entries on the switch were proactively added before the flows
were generated.
54
Mininet
55
Laboratory Setup
 Traffic was generated through two MikroTik RouterBoard 750GL
switches.
 Controller (POX) was running in one system, which invoked OpenFlow
switches to act as a L2 learning switch.
 Timeout for switch’s flow table entry was set to 1 second.
56
Laboratory Setup
57
Laboratory Setup
 Traffic was generated through two MikroTik RouterBoard 750GL
switches.
 The entries on the switch were proactively added before the flows
were generated.
58
Laboratory Setup
59
Thank You
60