Problems
The limited capabilities of the switches renders the implementation of unorthodox routing and forwarding mechanisms as a hard task in OpenFlow => the goal is to inspect the possibilities of slightly smartening up the OpenFlow switches.
Case studies
Add new features (matching mechanism, extra action) to flow tables
- Using Bloom filter for stateless multicast
- Greedy routing => performed at switch rather than at controller
- Network coding
An Openflow-Based Engergy-Efficient Data Center Approach
Problem
IaaS providers suffer from the inherent heterogeneity of systems and applications from different customers => different load + traffic patterns has to be handled
Solutions
- Overprovision to sustain a constant service quality => only applied with huge budget and a lot of resources
- Smart resource management => ECDC = machine information + network devices + environment data
Plug-n-Serve: Load-Balancing Web Traffic using OpenFlow
Problems
In data center or a dedicated web-hosting service, the HTTP servers are connected by a regular, over-provisioned network; the load-balancer usually does not consider the network state when load-balancing across servers => this way is not true for unstructured network (enterprise, campus) => traffic affects to performance of load-balancing and increase the response time of HTTP request
Solutions - Plug-n-Serve
Load-balances over arbitrary unstructured networks and minimize the average response time by considering the congestion of network and the load on the network + server.
Solutions - Plug-n-Serve
Load-balances over arbitrary unstructured networks and minimize the average response time by considering the congestion of network and the load on the network + server.
- It determines the current state of the network and the servers, including the network topology, network congestion, and load on the servers.
- It choose the appropriate server to direct requests to, and controls the path taken by packets in the network, so as to minimize the response time
OpenFlow-Based Server Load Balancing Gone Wild
Problem
The switch in SDN network is used for load balancing and overloaded by a huge number of forwarding rules if each rule is installed for each connection.
Plug-n-Serve approach intercepts first packet of each connection and use network topology + load to determine the target replica before forwarding the traffic => many rules (as said above), delay (since involving the controller for each connection). This approach is called "reactive"
Solutions
Use wildcard rule to direct requests for larger groups of clients instead of each client/connection.
- Based on the share of requests among replicas (called weight), the author proposed an partition algorithm to divide client traffic efficiently.
- Building a IP-prefix tree with the height is log of sum of replica weight
- Assign leaf nodes to replicas based on the proportion of its weight.
- Reduce the number of rules by using a wildcard form (for example: we can use 01* instead of two leaf nodes 010* and 011* to create a corresponding rule for a replica)
- How to handle when we need to move a traffic from a replica to another => note: exisitng connection should complete at original replica => two ways:
- Controller inspects the incoming packet, if it is a non-SYN packet, then it will keep being sent to old replica. If not, the controller will install a rule to forward the packet (and the ones belong to same connection) to new replica
- Controller installs high-priority rules to switch to forward traffic to old replica, and low-priority ones to forward to new replica. After soft deadline with no any traffic, that high-priority rule at switch is deleted.
The author also consider the non-uniform traffic as well as the case in which network is composed of multiple switches rather than two (one for gateway receiving client traffic and the other for load balancing)
SDN-based Application-Aware Networking on the Example of YouTube Video
Streaming
Problem
Northbound API enables the application information exchange between applications and network plan => determine how different kinds of information (such as per-flow parameter, app's signature, app quality parameter) can support a more effective network management in an SDN-enabled network
Solution
Conduct 6 experiments: pure, with interfering traffic, round-robin path selection (controller has no external, information, just automatically change switch ports sequentially for incoming packets), DPI experiments (network information) and Application-aware path selection (application state).
SDN-based Application-Aware Networking on the Example of YouTube Video
Streaming
Problem
Northbound API enables the application information exchange between applications and network plan => determine how different kinds of information (such as per-flow parameter, app's signature, app quality parameter) can support a more effective network management in an SDN-enabled network
Solution
Conduct 6 experiments: pure, with interfering traffic, round-robin path selection (controller has no external, information, just automatically change switch ports sequentially for incoming packets), DPI experiments (network information) and Application-aware path selection (application state).