Presentation at CloudCom'14
Abstract: Bandwidth and latency are two major factors that contribute the most to network application performance. Between each pair of switches in a network, there may be multiple paths connecting them. Each path has different properties because of multiple factors. Traditional shortest-path routing does not take this knowledge into consideration and may result in sub-optimal performance of applications and underutilization of network.We proposed a concept of “bandwidth and latency aware routing”. The idea is that we could improve overall performance of the network by separating application into bandwidth-oriented and latency-oriented application and allocate different route for each type of application accordingly. We also proposed a design of this network system implemented using OpenFlow. Routes are calculated from monitored information using Dijkstra algorithm and its variation. To support our design, we show a use case in which our design performs better than traditional routing as well as evaluation results.
How to Add Existing Field in One2Many Tree View in Odoo 17
Application-Oriented Bandwidth and Latency Aware Routing with OpenFlow Network
1. Application-Oriented Bandwidth
and Latency Aware Routing with
OpenFlow Network
PONGSAKORN U-CHUPALA, KOHEI ICHIKAWA, HAJIMU IIDA,
NAWAWIT KESSARAPHONG, PUTCHONG UTHAYOPAS,
SUSUMU DATE, HIROTAKE ABE, HIROAKI YAMANAKA AND
EIJI KAWAI
EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 112/22/2014
2. Agenda
1. Introduction
2. Approach
3. Design
4. Evaluation
5. Conclusion and Future Work
EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 212/22/2014
3. Applications
EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 4
Remote Desktop
Web Server
VoIP
Video Streaming
GameSocial Network
Secure Shell
12/22/2014
6. Objective
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 7
Align applications’ diverse requirements with
different properties of each path in the network
and route accordingly to improve application
performance and network utilization
7. Agenda
1. Introduction
2. Approach
3. Design
4. Evaluation
5. Conclusion and Future Work
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 9
8. Categorizing Network Application
BANDWIDTH-ORIENTED
File Transfer
Computation of Big Data
Video/Audio Streaming
LATENCY-ORIENTED
VoIP
Game
Remote Desktop
Secure Shell
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 11
9. Network Dynamicity
Link Status Dynamicity
◦ Cable type and condition
◦ Congestion
◦ Traffic engineering policies
Path Status Dynamicity
◦ Link status dynamicity is
propagated and multiplied
Direct Network Measurement
◦ Calculating available resources by
usage accounting is not accurate
◦ Direct measurement yields more
accurate result
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 13
Bandwidth?
Latency?
10. Bandwidth and Latency Aware Routing
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 14
Monitor by
direct measurement
11. Agenda
1. Introduction
2. Approach
3. Design
4. Evaluation
5. Conclusion and Future Work
EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 1512/22/2014
13. 1. OpenFlow Network
OpenFlow allows us to control
route specifically for each
application
Centralize programmable
controller allows us to aggregate
information into a single location
and reroute any connection as
needed
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 17
OpenFlow Switch
OpenFlow Controller
14. 2. Bandwidth and Latency Monitor
Overlord* provides near-real-time available bandwidth and current
latency information of each link
Monitored information is forwarded to OpenFlow controller through
REST API
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 18
* N. Kessaraphong, P. Uthayopas, and K. Ichikawa, “Building a Network Performance Benchmarking System Using Monitoring as a
Service Infrastructure,” in The 18th International Computer Science and Engineering Conference, 2014, pp. 2–5.
15. 3. BW/LAT Supported Application
Each application register its preference to BW/LAT controller through
REST API
Preference information includes
◦ Flow Identifier: source IP:port, destination IP:port
◦ Preference: MIN_HOP, MAX_BW, MIN_LAT
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 19
Flow Identifier
(src_ip, src_port, dst_ip, dst_port)
Preference
(MIN_HOP / MAX_BW / MIN_LAT)
(10.0.0.1, 1234, 10.0.0.2, 80) MIN_HOP
(10.0.0.1, *, 10.0.0.2, 80) MAX_BW
(10.0.0.2, 80, 10.0.0.1, *) MAX_BW
(10.0.0.1, *, 10.0.0.2, *) MIN_LAT
(*, *, *, *) MIN_HOP
16. 4. BW/LAT Aware Controller
Central to the design of BW/LAT aware network
Take
◦ Available bandwidth of each link
◦ Current latency of each link
◦ Application preferences
Pre-calculate possible routes for each pair of switches
Allocate route for each application accordingly
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 20
17. Route Pre-calculation
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 21
Minimum latency path and minimum hop count path is calculated with Dijkstra Algorithm
Maximum bandwidth path is calculated with a slightly modified version of Dijkstra Algorithm
18. Route Selection
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 25
BW/LAT
Controller
Flow Preference Table
(src, *, dst, *) | BW
BW
LAT
HOP
19. Agenda
1. Introduction
2. Approach
3. Design
4. Evaluation
5. Conclusion and Future Work
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 26
20. Experiments with
Virtual Environment
Measure average all-pair bandwidth and latency
Repeat the experiment for 100 times
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 28
Reduce bandwidth and add latency
for congestion simulation
21. Average All-pair Bandwidth
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 30
118.0616333
85.7680214
95.48433667 93.0250646
0
20
40
60
80
100
120
140
All links at 100 Mbps 5 links are selected at random and got
limited to 40 Mbps (repeated for 100
iterations)
Bandwidth(Mbps)
Traditional Routing Bandwidth and Latency Aware Routing
22. Average All-pair Latency
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 31
0.362566667
10.946468
0.2311
1.146959
0
2
4
6
8
10
12
14
16
18
All links at full speed 5 links are selected at random and got
10 ms latency added (repeated for 100
iterations)
Latency(ms)
Traditional Routing Bandwidth and Latency Aware Routing
23. Conclusion and Future Work
Bandwidth and Latency Aware Routing
◦ Aligning application requirements with network properties using OpenFlow
◦ Bandwidth-oriented and latency-oriented application
◦ Direct network measurement
◦ Route each flow individually according to flow preference
12/22/2014 EMERGING ISSUES IN CLOUD WORKSHOP | CLOUDCOM 2014 33
Evaluation
◦ Experiments with Virtual
Environment
1. Bandwidth Experiment
2. Latency Experiment
Future Work
◦ Experiment with Real-World
OpenFlow Network
◦ PRAGMA-ENT (DONE)
◦ More precise monitoring
◦ BW/LAT Orientation Classification
◦ Improve Implementation
Performance
Nowadays, it is clear that the internet plays a very important part in our society.
Behind it is a reliable
However, it is becoming increasingly difficult for traditional network to keep up with requirements of modern applications
In a cloud infrastructure, at a time, there usually are various kind of application running concurrently.
On the networking side of the infra, there are various properties/metrics that define network performance
Each application react differently to different aspect of network
Affinity between applications and network properties
Sensitive
Improve
- These are 2 major factors that have most impact to network and application performance
These are 2 major factors that have most impact to network and application performance
Bandwidth-oriented application is a category of application that achieves higher performance when more bandwidth is available.
Latency-oriented application is a category of application that performs better over low latency network.
The smallest unit, a link between a pair of switches
There a many factors that could impact link property
In a modern network, with technology such as tunnel an overlay network, this link can be virtual
You don’t even know if link is physically connected or not
Multiple links form into a path, dynamicity multiply
Monitoring network property in real-time is difficult
The smallest unit, a link between a pair of switches
There a many factors that could impact link property
In a modern network, with technology such as tunnel an overlay network, this link can be virtual
You don’t even know if link is physically connected or not
Multiple links form into a path, dynamicity multiply
Monitoring network property in real-time is difficult
Status of a network is monitored
Applications are route according to current network property
----- Meeting Notes (12/18/14 09:24) -----
Concept
----- Meeting Notes (12/18/14 09:24) -----
Notice that everything is communicated throught API
----- Meeting Notes (12/18/14 02:11) -----
single entity
Use Overlord for its direct measurement technique
App register pref
pref include connection and orientation
Install
Take all information
Route accordingly
Maximin path
(Upper left) Example? Link Status?
- Also, for non-negative edge network, Dijkstra is the proven appropriate technique
For each flow
- Congestion simulation by randomly select 5 links
----- Meeting Notes (12/18/14 09:24) -----
Mesh network consists of 6 OVS
----- Meeting Notes (12/18/14 09:24) -----
L2 Switching with STP