1. Stochastic Modeling of Packet Delay in OpenFlow SDNs
Dr. Muhammad Usman Ilyas
Post-doc + PhD + MS (Michigan State U), MS (LUMS), BE (NUST)
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

2. Team Members Uzzam Javed MS Student SEECS-NUST, Pakistan Azeem Iqbal

3. Center of NUST campus

4. School of Electrical Engineering & Computer Science SEECS

5. School of Electrical Engineering & Computer Science SEECS

6. nust.edu.pk

7. seecs.nust.edu.pk

8. andash.seecs.nust.edu.pk

9. Ongoing Research projects at ANDASH Lab
Networking and Security
Packet delay model in OpenFlow SDNs
OpenStack fault resilience to network errors
Microsoft Research – Azure 4 research .

10. Ongoing Research projects at ANDASH Lab
Networking and Security
Packet delay model in OpenFlow SDNs
OpenStack fault resilience to network errors
Microsoft Research – Azure 4 research
Anomaly detection in OpenStack
PLUMgrid Inc., Sunnyvale, CA
Link de-anonymization in Ims (Tor network)
Cloud-mobile Applications
Mobile crowdsensing to map road and traffic conditions
Activity recognition and tracking by smartphones
HEC funding
MAC protocol for vehicular networks (SKKU, Suwon, S. Korea)
Social media / networks
Word cloud segmentation based on sub-topics

11. Network Planes Data Plane
Forward traffic according to the logic implemented at the control plane.

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

13. Network Planes Management Plane
Used to manage and configure network devices.
Control Plane
Control Plane
Control Plane
Control Plane
Control Plane

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

15. Software Defined Networking
Software Defined Networking (SDN) is an paradigm that decouples control plane from data plane.
Provides a control plane abstraction for the whole network (AS).
SDN Application
SDN Application
SDN Application
SDN Controller

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

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

18. Separation of Control Plane across H/W Comp.
Install table entry, send packet
SDN Controller
0C->p3
Most features
go here
Control Plane CPU
Table miss, send to controller
This gets smaller, turns into controller to switch chip translator
dst
port 0E 5
dst
port 0E 5 0A 1
dst
port 0E 5 0A 1 0C 3
Packet / Network Processor
0A->0C
0A->0E
0A->0E

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

20. OpenFlow Messages Controller-to-Switch
Asynchronous (Event driven, sent from switch to controller)
Symmetric (Sent by switch or controller)
Azizi, Mounir, Redouane Benaini, and Mouad Ben Mamoun. "The Programmable Cloud Network: Delay Measurement Application." Signal-Image Technology and Internet-Based Systems (SITIS), 2014 Tenth International Conference on. IEEE, 2014.

21. OpenFlow Switch Entry
The data path of an OpenFlow Switch presents a clean flow table abstraction; each flow table entry contains a set of packet fields to match, and an action (such as send-out-port, modify-field, or drop). 

22. Objective of the Project
To develop a stochastic model for delay of switches in OpenFlow enabled networks.
Develop reasonable models to understand internet traffic characteristics in OpenFlow enabled networks.
Stochastic model will be based on measurement and simulation on different platforms.

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

24. 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 self- similar(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.

25. 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 conference on Applications, technologies, architectures, and protocols for computer communication. ACM, 2012.

26. Traffic at different time scales
Packets/Time Unit
Ethernet Traffic
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.

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

28. 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 CONTROLLER- SWITCH INTERACTION IN OPENFLOW BASED SDNS.”
A more accurate model using queueing theory but evaluated using simulations.

29. Measurements Controlled traffic generation using traffic generator.
Delay measurements will include the following components:
Clock synchronization ensured using NTP
Processing delay on a each switch.
Queuing delay on each switch.
Transmission delay on each switch.
Link propagation delay.
Controlled, repeatable traffic makes it easier to conduct cause-and-effect performance analysis.

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

31. Platform 1 - Mininet SDN emulator
Controller C0
SDN emulator
To study the delay in OpenFlow SDN switches in an SDN emulator.
OpenFlow Switch S1 H1 H2
Virtual Hosts
Mininet Virtual Machine

32. 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 2
Host 1

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

34. Platform 4-
Risdianto, Aris Cahyadi, and JongWon Kim. "Prototyping Media Distribution Experiments over TEIN SDN-enabled Testbed." Proceedings of the Asia-Pacific Advanced Network 38 (2014)

35. Platform 4-
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.

36. Some Initial Results for Single Switch
Three platforms were used to analyze the round trip time delay.
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.

37. Single Router Delay

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

39. Mininet
Bin size in Matlab was set to

40. Mininet Traffic was generated on a single switch.
Entries on the switch were pre-loaded before the flows were generated.

41. Mininet
Bin size in Matlab was set to

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

43. Laboratory Setup

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

45. Laboratory Setup

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

47. GENI Testbed

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

49. GENI Testbed

50. End-to-end Delays

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

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

53. Mininet

54. Mininet Traffic was generated on two switches.
The entries on the switch were proactively added before the flows were generated.

55. Mininet

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

57. Laboratory Setup

58. Laboratory Setup
Traffic was generated through two MikroTik RouterBoard 750GL switches.
The entries on the switch were proactively added before the flows were generated.

59. Laboratory Setup

60. Thank You