Latency in Software Defined Networks

He, Keqiang; Khalid, Junaid; Das, Sourav; Gember-Jacobson, Aaron; Prakash, Chaithan; Li, Li Erran; Thottan, Marina

doi:10.1145/2745844.2745880

Cited by 21 publications

(7 citation statements)

References 4 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…He et al [8] have proposed to reduce a delay by redirecting unmatched packets to a proxy. However, using a proxy in SDN may suffer from network congestion if several switches connect to the same proxy.…”

Section: Related Workmentioning

confidence: 99%

“…Several solutions ([7]- [11]) have also been proposed to reduce the delay of the control traffic. However, some solutions support only a specific communication between the control and data planes (in-band or out-of-band control networks) [8], [9]. Some solution [7] has proposed an initial design to fix this problem, but with a rather high overhead for traffic tagging.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Priority-based Scheduling Policy for OpenFlow Control Plane

2019

KSII TIIS

View full text Add to dashboard Cite

Software Defined Networking (SDN) is a new network paradigm, allowing administrators to manage networks through central controllers by separating control plane from data plane. So, one or more controllers must locate outside switches. However, this separation may cause delay problems between controllers and switches. In this paper, we therefore propose a Priority-based Scheduling policy for OpenFlow (PSO) to reduce the delay of some significant traffic. Our PSO is based on packet prioritization mechanisms in both OpenFlow switches and controllers. In addition, we have prototyped and experimented on PSO using a network simulator (ns-3). From the experimental results, PSO has demonstrated low delay for targeted traffic in the out-of-brand control network. The targeted traffic can acquire forwarding rules with lower delay under network congestion in control links (with normalized load > 0.8), comparing to traditional OpenFlow. Furthermore, PSO is helpful in the in-band control network to prioritize OpenFlow messages over data packets.

show abstract

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Priority-based Scheduling Policy for OpenFlow Control Plane

2019

KSII TIIS

View full text Add to dashboard Cite

show abstract

“…While the correctness problems discussed in §3 can be avoided via preserving strong consistency instead of weak causal consistency, doing so comes at a great data plane performance cost. Figure 5(a) shows the aggregate bandwidth overhead imposed by SC on the controller, already a bottleneck in SDNs [12,24,27,37,54], for the IDS example of §3.1. In addition to bandwidth overhead, this practice imposes added latency to flows.…”

Section: Data Plane Performance Impactmentioning

confidence: 99%

“…For the short-lived replication caused by migrations of middleboxes or virtual networks, OpenNF, LIME, and Split/Merge strive to retain strong consistency (SC) by heavy-weight operations 7 such as dropping packets or redirecting them to the controller [17,20,52]. In COCONUT, the dataplane continues processing packets during the update, i.e., packets are not buffered (unlike [17,52]), not redirected to the controller (unlike [17,20,39]) which is already a scalability bottleneck in SDNs [12,24,27,37,54], and not dropped (unlike [20,52]).…”

Section: Related Workmentioning

confidence: 99%

Coconut

Ghorbani

Godfrey

2017

Proceedings of the Twelfth European Conference on Computer Systems

View full text Add to dashboard Cite

A key use of software-defined networking is to enable scaleout of network data plane elements. Naively scaling networking elements, however, can cause incorrect behavior. For example, we show that an IDS system which operates correctly as a single network element can erroneously and permanently block hosts when it is replicated. In this paper, we provide a system, COCONUT, for seamless scale-out of network forwarding elements; that is, an SDN application programmer can program to what functionally appears to be a single forwarding element, but which may be replicated behind the scenes. To do this, we identify the key property for seamless scale out, weak causality, and guarantee it through a practical and scalable implementation of vector clocks in the data plane. We prove that COCONUT enables seamless scale out of networking elements, i.e., the user-perceived behavior of any COCONUT element implemented with a distributed set of concurrent replicas is provably indistinguishable from its singleton implementation. Finally, we build a prototype of COCONUT and experimentally demonstrate its correct behavior. We also show that its abstraction enables a more efficient implementation of seamless scale-out compared to a naive baseline.

show abstract

“…In this paper, we present Mercury, a framework, for providing strict performance guarantees for control plane actions by intelligently partitioning and managing TCAM. Mercury builds on the observations that control plane actions are expensive when a flow table contains a large number of en-tries [23,18,22] .…”

Section: Introductionmentioning

confidence: 99%

The Case for Making Tight Control Plane Latency Guarantees in SDN Switches

Chen

Benson

2017

Proceedings of the Symposium on SDN Research

View full text Add to dashboard Cite

SDN controllers demand tight performance guarantees over the control plane actions performed by SDN switches. For example, traffic engineering techniques that frequently reconfigure the network require guarantees on the speed of gathering data from the network and the speed of reconfiguring the network. Yet, modern switches provide no guarantees for these control plane actions, e.g., inserting rules or gathering statistics. In fact, initial experiments demonstrate that unpredictability in control plane actions, specifically rule insertion, can inflate application completion times by a factor of 4X! In this paper, we present Mercury, a framework that offers a novel method for efficiently and practically managing switch TCAM to enable strict performance guarantees. Specifically, Mercury builds on the fundamental properties of TCAMs and provides guarantees by trading-off a nominal amount of TCAM space for assured performance. Our preliminary evaluations show that with less than 10% overheads, Mercury provides guarantees of 10ms insertion time and improves application performance by a factor 2X to 5X.

show abstract

Latency in Software Defined Networks

Cited by 21 publications

References 4 publications

Priority-based Scheduling Policy for OpenFlow Control Plane

Priority-based Scheduling Policy for OpenFlow Control Plane

Coconut

The Case for Making Tight Control Plane Latency Guarantees in SDN Switches

Contact Info

Product

Resources

About