Efficient traffic splitting on commodity switches

Abstract

Traffic often needs to be split over multiple equivalent backend servers, links, paths, or middleboxes. For example, in a load-balancing system, switches distribute requests of online services to backend servers. Hash-based approaches like Equal-Cost Multi-Path (ECMP) have low accuracy due to hash collision and incur significant churn during update. In a Software-Defined Network (SDN) the accuracy of traffic splits can be improved by crafting a set of wildcard rules for switches that better match the actual traffic distribution. The drawback of existing SDN-based traffic-splitting solutions is poor scalability as they generate too many rules for small rule-tables on switches. In this paper, we propose Niagara, an SDN-based traffic-splitting scheme that achieves accurate traffic splits while being extremely efficient in the use of rule-table space available on commodity switches. Niagara uses an incremental update strategy to minimize the traffic churn given an update. Experiments demonstrate that Niagara (1) achieves nearly optimal accuracy using only 1.2% − 37% of the rule space of the current state-of-art, (2) scales to tens of thousands of services with the constrained rule-table capacity and (3) offers nearly minimum churn.

OFLoad: An OpenFlow-Based Dynamic Load Balancing Strategy for Datacenter Networks

“…Niagara [27] SDN-based traffic splitting solution basic campus network and symmetric and asymmetric datacenter topologies synthetic VIP traffic and real datacenter traces For symmetric topologies Niagara performs better than ECMP but offers similar performance to MicroTE. Niagara incurs > 20% imbalance for 15% time frames.…”

“…However, splitting the flows at the switch for load balancing could result in instability and low throughput as well as out of order packet delivery. Niagara [27] is another traffic-splitting solution for commodity switches which offers similar performance to MicroTe [28]. A promising distributed congestion-aware load balancing solution is proposed in [29], [30] and referred to as Expeditus.…”

“…Compared to OFLoad, other load balancing solutions like LABERIO [24], FlowBender [25], Presto [26], Niagara [27], or Expeditus [30] they either do not look into differentiating between the mice and elephant flows or they try to move the load balancing functionality at the network edge limiting the global view of the controller. Breaking the flows into sub-flows is another option adopted by some of the solutions.…”

HNLB: Utilizing Hardware Matching Capabilities of NICs for Offloading Stateful Load Balancers

“…Conversely, there are works that use Software Defined Networking (SDN) to provide load balancing service [17], [18], [19]. In these approaches, the load of service instances and network are being monitor by monitoring entity(es).…”

ENDEAVOUR: A Scalable SDN Architecture For Real-World IXPs

“…Instead of employing the "black-box" optional capabilities of commercial legacy switches, such as hash-based forwarding, we capitalize on the features available in any OFenabled switch. In particular, we compute the outgoing port according to the least significant bits in the IP source and destination addresses as also proposed in [24]. This mechanism provides a main advantage: while a black-box solution cannot be easily upgraded if not suitable anymore, this simple load balancing technique can be adapted on-demand.…”