Jellyfish: Networking Data Centers Randomly

By Ankit Singla, C. Hong, L. Popa, Brighten Godfrey. Symposium on Networked Systems Design and Implementation, 2011

617 citations recorded by the source corpus.

Industry experience indicates that the ability to incrementally expand data centers is essential. However, existing high-bandwidth network designs have rigid structure that interferes with incremental expansion. We present Jellyfish, a high-capacity network interconnect which, by adopting a random graph topology, yields itself naturally to incremental expansion. Somewhat surprisingly, Jellyfish is more cost-efficient than a fat-tree, supporting as many as 25% more servers at full capacity using the same equipment at the scale of a few thousand nodes, and this advantage improves with scale. Jellyfish also allows great flexibility in building networks with different degrees of oversubscription. However, Jellyfish's unstructured design brings new challenges in routing, physical layout, and wiring. We describe approaches to resolve these challenges, and our evaluation suggests that Jellyfish could be deployed in today's data centers.

Subfields: Computer Networks and Communications, Electrical and Electronic Engineering

View Paper: https://www.semanticscholar.org/paper/5b8bcb3d2b8e2f4111c61003abbfbb5963187870

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

In Computer Networks and Communications

In Electrical and Electronic Engineering

Citations in the corpus

Inside the Social Network's (Datacenter) Network (2015, background): “Such an assumption leads to the goal of delivering maximum bisection bandwidth [4, 23, 36], which may be overkill when demand exhibits significant locality [17].”
Finishing flows quickly with preemptive scheduling (2012, methodology): “We evaluate three scalable data center topologies: (1) Fattree [2], a structured 2-stage Clos network; (2) BCube [13], a server-centric modular network; (3) Jellyfish [18], an unstructured high-bandwidth network using random regular graphs.”
FireFly (2014, methodology): “A robust data center (DC) network must satisfy several goals: high throughput [13, 23], low equipment and management cost [13, 40], robustness to dynamic traffic patterns [14, 26, 48, 52], incremental expandability [18, 45], low cabling complexity [37], and low power and cooling costs.”
Re-architecting datacenter networks and stacks for low latency and high performance (2017, background): “In asymmetric topologies such as BCube [19] and Jellyfish [36], NDP will behave poorly because it will spray packets on different length paths that are costly to use when the network is heavily loaded.”
DRILL: Micro Load Balancing for Low-latency Data Center Networks (2017, background): “Note that this approach is not intended to handle fully arbitrary networks or alternative topologies like random graphs [65].”
Slim Fly: A Cost Effective Low-Diameter Network Topology (2014, methodology): “This would additionally improve the latency and bandwidth of such SF variants [29], [37].”
Planck (2014, background): “, Jellyfish [37], would require many fewer collectors.”
Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google's Datacenter Network (2015, background): “Recent work on alternate network topologies such as HyperX [1], Dcell [17], BCube [16] and Jellyfish [22] deliver more efficient bandwidth for uniform random communication patterns.”
Reproducible network experiments using container-based emulation (2012, methodology): “Jellyfish [41] Jellyfish, a randomly constructed network topology, can achieve good fairness using k-shortest paths routing, comparable to a Fat Tree using ECMP routing, by using MPTCP.”
Lessons from "a first-principles approach to understanding the internet's router-level topology" (2019, background): “The few times the SF approach tried to make a comeback and reclaim its relevance for physical Internet structures such as datacenter topologies [17], the attempts quickly faded because technology constraints and economic considerations still restrict intradatacenter connectivity even when that conne”