QuicSDN: Transitioning from TCP to QUIC for Southbound Communication in SDNs

TL;DR

The paper tackles the transport-layer overhead inflicted by TCP/TLS in SDN southbound communication. It introduces quicSDN, a QUIC-based architecture with a switch-side quic-client and a controller-side quic-server that multiplexes messages from multiple agents over a single connection, accelerating connection establishment and migration. Through analytical modeling and an implemented prototype that integrates with OVS and the RYU controller, it demonstrates lower overhead and shorter message-delivery delays than tcpSDN under varying RTTs and loss conditions. The work showcases QUIC’s streaming and handshake advantages as a practical path to more scalable, responsive SDN deployments and outlines directions for broader adoption and further optimizations.

Abstract

In Software-Defined Networks (SDNs), the control plane and data plane communicate for various purposes, such as applying configurations and collecting statistical data. While various methods have been proposed to reduce the overhead and enhance the scalability of SDNs, the impact of the transport layer protocol used for southbound communication has not been investigated. Existing SDNs rely on TCP (and TLS) to enforce reliability and security. In this paper, we show that the use of TCP imposes a considerable overhead on southbound communication, identify the causes of this overhead, and demonstrate how replacing TCP with QUIC can enhance the performance of this communication. We introduce the quicSDN architecture, enabling southbound communication in SDNs via the QUIC protocol. We present a reference architecture based on the standard, most widely used protocols by the SDN community and show how the controller and switch are revamped to facilitate this transition. We compare, both analytically and empirically, the performance of quicSDN versus the traditional SDN architecture and confirm the superior performance of quicSDN.

Figures (11)

• Figure 1: tcpSDN (a) and quicSDN (b) architectures. Compared to the tcpSDN architecture where an individual connection is required for each pair of agents (processes) running on a switch and the controller, quicSDN establishes one connection between each switch and the controller.
• Figure 2: Each column shows the transmission overhead and acknowledgement overhead of TCP and QUIC in various scenarios. The first row shows transmission overhead and the second row shows acknowledgment overhead. $\lambda$ is rate of message generation by each agent. $\vert\mathbf{A}\vert$ is the number of agents. $\bar{m}$ is average message size. These results confirm the considerably lower packet exchange overhead of QUIC versus TCP.
• Figure 3: The effect of blocking on message delivery delay to application layer. In this scenario, the delivery of Message $k+1$ is at least $RTT + RTT/2$ slower when using TCP, compared to QUIC.
• Figure 4: Connection reestablishment delay between switches and controllers in (a) tcpSDN and (b) quicSDN. quicSDN facilities dynamic assignment of switches to controllers with a shorter delay and lower overhead.
• Figure 5: The architecture of a switch in quicSDN. The figure highlights the modifications to and how packets are processed by the quic-client component.