On the Cost of Tunnel Endpoint Processing in Overlay Virtual Networks

Weerasinghe, Jagath; Audigier, François

doi:10.1109/ucc.2014.123

Cited by 8 publications

(6 citation statements)

References 5 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…First, many researchers propose to reduce unnecessary work to improve the performance. Systems can offload CPU-intensive work, such as checksum computing, onto hardwares [12,14,18,71] or bypass inefficient parts inside kernel [22,71] to improve the container network processing. As a concrete example, advanced offloading techniques, e.g., Mellanox ASAP2 [19], allow for the offloading of virtual switches and packet transformation entirely to the NIC hardware.…”

Section: Container Network Accelerationmentioning

confidence: 99%

Parallelizing packet processing in container overlay networks

Lei

Munikar

Suo

et al. 2021

Proceedings of the Sixteenth European Conference on Computer Systems

View full text Add to dashboard Cite

Container networking, which provides connectivity among containers on multiple hosts, is crucial to building and scaling container-based microservices. While overlay networks are widely adopted in production systems, they cause significant performance degradation in both throughput and latency compared to physical networks. This paper seeks to understand the bottlenecks of in-kernel networking when running container overlay networks. Through profiling and code analysis, we find that a prolonged data path, due to packet transformation in overlay networks, is the culprit of performance loss. Furthermore, existing scaling techniques in the Linux network stack are ineffective for parallelizing the prolonged data path of a single network flow.We propose Falcon, a fast and balanced container networking approach to scale the packet processing pipeline in overlay networks. Falcon pipelines software interrupts associated with different network devices of a single flow on multiple cores, thereby preventing execution serialization of excessive software interrupts from overloading a single core. Falcon further supports multiple network flows by effectively multiplexing and balancing software interrupts of different flows among available cores. We have developed a prototype of Falcon in Linux. Our evaluation with both micro-benchmarks and real-world applications demonstrates the effectiveness of Falcon, with significantly improved performance (by 300% for web serving) and reduced tail latency (by 53% for data caching).

show abstract

Section: Container Network Accelerationmentioning

confidence: 99%

Parallelizing packet processing in container overlay networks

Lei

Munikar

Suo

et al. 2021

Proceedings of the Sixteenth European Conference on Computer Systems

View full text Add to dashboard Cite

show abstract

“…Adding and removing encapsulation headers increases overhead, may decrease application goodput, and may increase end-to-end latency, depending on whether the hardware supports tunnelling. Specialised hardware may be needed to support line rate forwarding of tunnel traffic [14][15][16]. Encapsulation and de-encapsulation performed in software provide flexibility but consume CPU resources, which can be used to host more VMs [14,15].…”

Section: Packet Forwarding In Dcnetmentioning

confidence: 99%

“…Specialised hardware may be needed to support line rate forwarding of tunnel traffic [14][15][16]. Encapsulation and de-encapsulation performed in software provide flexibility but consume CPU resources, which can be used to host more VMs [14,15]. Instead of encapsulation, DCnet uses address rewriting in which the ToR switch replaces the destination UID-MAC address in each outgoing packet with the current location address (RMAC) of the destination.…”

Section: Packet Forwarding In Dcnetmentioning

confidence: 99%

“…Also, tenant VMs can freely migrate to physical servers in a data centre by changing the tunnel endpoint from source server to destination server. A disadvantage of using tunnelling protocols is that if performed in software (in the virtual switch), tunnelling incurs CPU overhead, increases latency, and the added overhead in packets decreases application goodput [14][15][16]. To overcome the CPU overhead, [14,16] propose equipping physical servers with specialised hardware such as NICs that support tunnelling or FPGAs.…”

Section: Related Workmentioning

confidence: 99%

“…Some of the existing solutions that can be used to support live VM migration in a data centre use standard tunnelling protocols such as VXLAN [12], NVGRE [13], or custom tunnelling protocols. Tunnelling can be implemented in software; however, such a scheme incurs an overhead in terms of latency, CPU utilisation, and throughput [14][15][16]. To save CPU resources for VMs and containers and to improve the latency due to encapsulation and de-encapsulation operations, specialised hardware may be used [14,16].…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

DCnet: a data centre network architecture that supports live VM migration

Comer

Karandikar

2019

IET Networks

View full text Add to dashboard Cite

Cloud computing and storage have become an integral part of online Internet services. Over the past decade, enterprises have steadily moved their applications and storage to the cloud paradigm. Server virtualisation enables cloud providers to utilise computational resources efficiently by employing virtual machines (VMs) and containers. As more enterprise applications are hosted by VMs in the cloud, a significant amount of network communication occurs among servers within a data centre, increasing so-called 'east-west communication'. In addition to scaling to accommodate more east-west traffic, future data centre networks must support efficient VM migration, which is used to optimise power consumption. This article proposes a new data centre network architecture called DCnet. DCnet changes addressing and routing at layers 2 and 3 completely to increase throughput and support live VM migration throughout an organisation, including across multiple data centres owned by an organisation that spans large geographic areas. DCnet retains compatibility with existing hardware by using the same frame format as standard protocols, specifically Ethernet and Internet protocol (IP). Furthermore, DCnet does not require any changes to applications and host operating systems or libraries. In addition to presenting the architecture, the article describes a test bed used to assess DCnet and reports experimental measurements.

show abstract