FatPaths: Routing in Supercomputers and Data Centers when Shortest Paths Fall Short

TL;DR

FatPaths is a robust routing architecture that leverages diverse path options and a redesigned transport layer to significantly improve performance in supercomputers and data centers using low-diameter topologies.

Contribution

It introduces a generic routing architecture that exploits path diversity and a purified transport layer to enhance performance of low-diameter topologies.

Findings

Achieves 15% higher throughput compared to Clos networks.

Reduces latency by a factor of two.

Enables low-diameter topologies to outperform traditional designs.

Abstract

We introduce FatPaths: a simple, generic, and robust routing architecture that enables state-of-the-art low-diameter topologies such as Slim Fly to achieve unprecedented performance. FatPaths targets Ethernet stacks in both HPC supercomputers as well as cloud data centers and clusters. FatPaths exposes and exploits the rich ("fat") diversity of both minimal and non-minimal paths for high-performance multi-pathing. Moreover, FatPaths uses a redesigned "purified" transport layer that removes virtually all TCP performance issues (e.g., the slow start), and incorporates flowlet switching, a technique used to prevent packet reordering in TCP networks, to enable very simple and effective load balancing. Our design enables recent low-diameter topologies to outperform powerful Clos designs, achieving 15% higher net throughput at 2x lower latency for comparable cost. FatPaths will significantly accelerate Ethernet clusters that form more than 50% of the Top500 list and it may become a standard routing scheme for modern topologies.

Figures

Tables

Table 1. TABLE I : Support for path diversity in routing schemes . “Stack Layer” indicates the location of each routing scheme in the TCP/IP stack. SP , NP : support for arbitrary shortest and non-minimal paths, respectively. SM : A given scheme simultaneously enables minimal and non-minimal paths. MP : support for multi-pathing (between two hosts). DP : support for disjoint paths. ALB : support for adaptive load balancing . AT : compatible with an arbitrary topology . \faThumbsOUp , \faThumbsUp , \faThumbsDown : A given scheme, respectively, offers a given feature, offers it in a limited way (e.g., Monsoon  [ 27 ] uses multi-pathing (ECMP) only between border and access routers), and does not offer it. R A given feature is offered only for resilience ( not performance). S Minimal or non-minimal paths are offered only within one or more spanning trees that do not necessarily cover all physical paths.

Routing Scheme (Name, Abbreviation, Reference)	Stack Layer	Supported path diversity aspect
		SP	NP	SM	MP	DP	ALB	AT
(1) SIMPLE ROUTING PROTOCOLS (often used as building blocks):
Valiant load balancing (VLB) [17]	L2–L3	\faThumbsDown	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsOUp
Simple Spanning Tree (ST) [18]	L2	\faThumbsDownS	\faThumbsDownS	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsOUp
Simple routing, e.g., OSPF [19, 20, 21, 22]	L2, L3	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsOUp
UGAL [23]	L2–L3	\faThumbsOUp	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsOUp	\faThumbsOUp
ECMP [11], OMP [24], Pkt. Spraying [25]	L2, L3	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsOUp
(2) ROUTING ARCHITECTURES:
DCell [26]	L2–L3	\faThumbsDown	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsDown
Monsoon [27]	L2, L3	\faThumbsUp	\faThumbsUp	\faThumbsDown	\faThumbsUp	\faThumbsDown	\faThumbsDown	\faThumbsDown
PortLand [9]	L2	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsDown
DRILL [28], LocalFlow [29], DRB [30]	L2	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsOUp	\faThumbsDown	\faThumbsOUp	\faThumbsDown
VL2 [31]	L3	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsOUp	\faThumbsDown	\faThumbsUp	\faThumbsDown
Architecture by Al-Fares et al. [32]	L2–L3	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsOUp	\faThumbsOUp	\faThumbsOUp	\faThumbsDown
BCube [33]	L2–L3	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsOUp	\faThumbsOUp	\faThumbsDown	\faThumbsDown
SEATTLE [34], others∗ [35, 36, 37, 38]	L2	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsOUp
VIRO [39]	L2–L3	\faThumbsDownS	\faThumbsDownS	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsOUp
Ethernet on Air [40]	L2	\faThumbsDownS	\faThumbsDownS	\faThumbsDown	\faThumbsUpR	\faThumbsDown	\faThumbsDown	\faThumbsOUp
PAST [41]	L2	\faThumbsUpS	\faThumbsUpS	\faThumbsDown	\faThumbsDown	\faThumbsOUp	\faThumbsDown	\faThumbsOUp
MLAG, MC-LAG, others [42]	L2	\faThumbsUp	\faThumbsUp	\faThumbsDown	\faThumbsUpR	\faThumbsDown	\faThumbsDown	\faThumbsOUp
MOOSE [43]	L2	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsUp	\faThumbsDown	\faThumbsDown	\faThumbsOUp
MPA [44]	L3	\faThumbsOUp	\faThumbsOUp	\faThumbsDown	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsOUp
AMP [45]	L3	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsOUp	\faThumbsDown	\faThumbsOUp	\faThumbsOUp
MSTP [46], GOE [47], Viking [48]	L2	\faThumbsDownS	\faThumbsDownS	\faThumbsDown	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsOUp
SPB [49], TRILL [50], Shadow MACs [51]	L2	\faThumbsOUp	\faThumbsDownR	\faThumbsDown	\faThumbsOUp	\faThumbsDown	\faThumbsDown	\faThumbsOUp
SPAIN [52]	L2	\faThumbsUpS	\faThumbsUpS	\faThumbsUpS	\faThumbsOUp	\faThumbsOUp	\faThumbsDown	\faThumbsOUp
(3) Schemes for exposing/encoding paths (can be combined with FatPaths):
XPath [53]	L3	\faThumbsOUp	\faThumbsUp	\faThumbsUp	\faThumbsOUp	\faThumbsOUp	\faThumbsUp	\faThumbsOUp
Source routing for flexible DC fabric [54]	L3	\faThumbsOUp	\faThumbsUpR	\faThumbsUpR	\faThumbsDown	\faThumbsDown	\faThumbsDown	\faThumbsUp${}^{\text{†}}$
(3) FatPaths [This work]	L2–L3	\faThumbsOUp	\faThumbsOUp	\faThumbsOUp	\faThumbsOUp	\faThumbsOUp	\faThumbsOUp	\faThumbsOUp

Table 2. TABLE II : The most important symbols used in this work.

Network structure	$V,E$	Sets of vertices/edges (routers/links, $V=\{0,\dots ,N_r-1\}$).
	$N$	The number of endpoints in the network.
	$N_r$	The number of routers in the network ($N_r=\left|V\right|$).
	$p$	The number of endpoints attached to a router.
	$k^{\prime }$	The number of channels from a router to other routers.
	$k$	Router radix ($k=k^{\prime }+p$).
	$D,d$	Network diameter and the average path length.
Diversity of paths (§ IV)	$x\in V$	Different routers used in § IV ($x\in \{s,t,a,b,c,d\}$).
	$X\subset V$	Different router sets used in § IV ($X\in \{A,B\}$).
	$c_l(A,B)$	Count of (at most $l$-hop) disjoint paths between router sets $A$, $B$.
	$c_{\text{min}}(s,t),l_{\text{min}}(s,t)$	Diversity and lenghts of minimal paths between routers $s$ and $t$.
	$l_{\text{min}}(s,t)$	Lengths of minimal paths between routers $s$ and $t$.
	$I_{ac,bd}$	Path interference between pairs of routers $a,b$ and $c,d$.
Layers (§ V)	$n$	The total number of layers in FatPaths routing.
	${\sigma }_i$	A layer, defined by its forwarding function, $i\in \{1,\dots ,n\}$.
	$\rho$	Fraction of edges used in routing.

Table 3. TABLE III : Used topologies.

Topology	Structure remarks	$D$	Variant	Deployed?
Slim Fly (SF) [55]	Consists of groups	2	MMS	unknown
Dragonfly (DF) [23]	Consists of groups	3	“balanced”	PERCS [60], Cascade [61]
HyperX (HX, HX3) [56]	Consists of groups	3	“regular” (cube)	unknown
Xpander (XP) [4]	Consists of metanodes	$\le$3	randomized	unknown
Jellyfish (JF) [10]	Random network	$\le$3	“homogeneous”	unknown
Fat tree (FT) [58]	Endpoints form pods	4	3 router layers	Many systems

Table 4. Figure 7 : Distribution of the number of non-minimal edge-disjoint paths with up to l 𝑙 l hops ( c l ​ ( A , B ) subscript 𝑐 𝑙 𝐴 𝐵 c_{l}(A,B) ) between random router pairs ( N ≈ 10 , 000 𝑁 10 000 N\approx 10,000 ).

Topology parameters
	$d^{\prime }$	$D$	$k^{\prime }$	$N_r$	$N$
clique	2	1	100	101	10100
SF	3	2	29	722	10108
XP	3	3	32	1056	16896
HX	3	3	30	1331	13310
DF	4	3	23	2064	16512
FT3	4	4	18	1620	11664
Default topology variant
	$d^{\prime }$	CDP (mean)	CDP (1% tail)	PI (mean)	PI (99.9% tail)
clique	2	100%	100%	2%	2%
SF	3	89%	10%	26%	79%
XP	3	49%	34%	20%	41%
HX	3	25%	10%	9%	67%
DF	4	25%	13%	8%	74%
FT3	4	100%	100%	0	0
Equivalent Jellyfish
	$d^{\prime }$	CDP (mean)	CDP (1% tail)	PI (mean)	PI (99.9% tail)
SF-JF	3	56%	38%	23%	45%
XP-JF	3	51%	34%	21%	41%
HX-JF	3	50%	23%	17%	37%
DF-JF	4	87%	78%	13%	26%
FT3-JF	4	96%	90%	5%	14%

Table 5. TABLE V : The considered topologies. “Input” means input parameters used to derive other network parameters.

	Topology	Hierarchy	Flexibility	Input	$N_r$	$N$	$k^{\prime }$	$p$	$D$	Remarks	Deployed?
deterministic	Slim Fly [55]	group hierarchical	fixed	$q$	$2q^2$	$p{N}_r$		$\lceil \frac{k^{\prime }}{2}\rceil$	2	“MMS” variant [55, 186]	unknown
	Dragonfly [23]	group hierarchical	fixed	$p$	$4p^3+2p$	$p{N}_r$	$3p-1$	$p$	3	“balanced” variant [23] (§3.1)	PERCS [60], Cascade [61]
	HyperX [56]	semi-hierarchical	fixed	$S$	$S^2$	$p{N}_r$	$2\left(S-1\right)$	$\lceil \frac{k^{\prime }}{2}\rceil$	2	“regular” variant, 2x-oversubscribed, forms a Flattened Butterfly [57]	unknown
	HyperX [56]	semi-hierarchical	fixed	$S$	$S^3$	$p{N}_r$	$3\left(S-1\right)$	$\lceil \frac{k^{\prime }}{3}\rceil$	3	“regular” variant, 2x-oversubscribed, forms a cube	unknown
	Fat tree [58]	semi-hierarchical	fixed	$k$	$5\lfloor \frac{k^2}{4}\rfloor$	$p\lfloor \frac{k^2}{2}\rfloor$	$\frac{k}{2}$	$\lceil \frac{k}{2}\rceil$	4	2-stage variant (3 router layers)	Many installations
	Complete (clique)	flat	fixed	$k^{\prime }$	$k^{\prime }+1$	$p{N}_r$	$k^{\prime }$	$k^{\prime }$	1	$D=1$ HyperX, 2x-oversubscribed	crossbar routers
rand.	Jellyfish [10]	flat	flexible	$k^{\prime }$, $N_r$, $p$	$N_r$	$p{N}_r$	$k^{\prime }$	$p$	n/a	“homogeneous” variant [10]	unknown
	Xpander [4]	flat	semi-flexible	$\ell$	$\ell \left(k^{\prime }+1\right)$	$p{N}_r$	$\ell$	$\lceil \frac{k^{\prime }}{2}\rceil$	n/a	Restricted to $\ell =k^{\prime }$, $D\approx 2$, $p=\lceil \frac{k^{\prime }}{2}\rceil$	unknown

Equations

$$h(A)$$

$$h^l(A)$$

$$l_{\text{min}}(s,t)$$

$$c_{\text{min}}(s,t)$$

$$I_{ac,bd}^l=c_l(\{a,c\},\{b\})+c_l(\{a,c\},\{d\})-c_l(\{a,c\},\{b,d\})$$

$$\sum _{i=1}^k{f}_{iuv}\le c(u,v),u,v\in V$$

$$\sum _{v\in V}{f}_{iuv}-\sum _{v\in V}{f}_{ivu}=0,i=1,\dots ,k,u\in V\setminus \{s_i,t_i\}$$

$$\sum _{v\in V}{f}_{i{s}_{i}v}-\sum _{v\in V}{f}_{iv{s}_i}=T(s_i,t_i),i=1,\dots ,k$$

$$f_{iuv}\ge 0,u,v\in V,i=1,\dots ,k$$

$$-\sum _{v\in V}\sum _{l=1,\dots n}{f}_{i{s}_{i}vl}\cdot {\delta }_{v,{\sigma }_l(s_i,t_i)}+T(s_i,t_i)\cdot \mathcal{T}\le 0,i=1,2,\dots ,k$$

$$\sum _{i=1,\dots k}\sum _{l=1,\dots n}{f}_{iuvl}\cdot {\delta }_{v,{\sigma }_l(u,t_i)}\le c(u,v),\forall (u,v)\in E$$

$$\sum _{v\in V}{f}_{iuvl}\cdot {\delta }_{v,{\sigma }_l(u,t_i)}-\sum _{v\in V}{f}_{ivul}\cdot {\delta }_{u,{\sigma }_l(v,t_i)}=0,i=1,\dots ,k,l=1,\dots ,n,\forall u\in V\setminus \{s_i,t_i\}$$

$$\sum _{v\in V}\sum _{l=1,\dots n}{f}_{i{s}_{i}vl}\cdot {\delta }_{v,{\sigma }_l(s_i,t_i)}\le {\mathcal{T}}_{upperbound}\cdot T(s_i,t_i),i=1,\dots ,k$$

$$\sum _{v\in V}\sum _{l=1,\dots n}{f}_{iv{s}_{i}l}\cdot {\delta }_{s_i,{\sigma }_l(v,t_i)}=0,i=1,\dots ,k$$

$$(A^p\cdot A^q{)}_{i,j}=\sum _k{A}_{i,k}^p\cdot A_{k,j}^q.$$

$$K_{i,j}=\{\begin{array}{ll}x\in \mathbb{F}\text{u.a.r.}& \text{iff}(i,j)\in E\\ 0& \text{else}.\end{array}$$

$$K_{(i,k),(k,j)}^{\prime }=\{\begin{array}{ll}x\in \mathbb{F}\text{u.a.r.}& \text{iff}(i,k)\in E\wedge (k,j)\in E\\ 0& \text{else}.\end{array}$$

$$F=FK+P_s.$$

$$F=-P_s(\mathbb{I}-K{)}^{-1}.$$

$$F_0$$

$$F_l$$

$$c_{st}=\mathrm{rank}(P_s\underset{\text{l times, precomputed}}{\underbrace{(((K+\mathbb{I})\cdot K+\mathbb{I})\cdot \dots )}}{Q}_t).$$

Full text

**This is the full version of a paper published at

ACM/IEEE Supercomputing’20 under the same title**

I Introduction

Ethernet continues to be important in the HPC landscape. While the most powerful Top500 systems use vendor-specific or Infiniband (IB) interconnects, more than half of the Top500 (cf. the Nov. 2019 issue) machines [2] are based on Ethernet, see Figure 1 (the left plot). For example, Mellanox connects 156 Ethernet systems (25 GiB and faster), which is 20% more than in Nov. 2018. The Green500 list is similar [3]. The importance of Ethernet is increased by the “convergence of HPC and Big Data”, with cloud providers and data center operators aggressively aiming for high-bandwidth and low-latency fabric [4, 1, 5]. An example is the growing popularity of RDMA over Converged Ethernet (RoCE) [6] that facilitates deploying Remote Direct Memory Access (RDMA) [7] applications and protocols – traditionally associated with HPC and IB interconnects – on top of Ethernet.

Yet, Ethernet systems are scarce in the highest 100 positions of Top500. For example, in November 2019, only six such systems were among the highest 100. Ethernet systems are also less efficient than Infiniband, custom, OmniPath, and proprietary systems, see Figure 1 (on the right). This is also the case for systems with similar sizes, injection bandwidth, and topologies, indicating overheads caused by routing. Thus, enhancing routing in HPC Ethernet clusters would improve the overall performance of $\approx$50% of Top500 systems and accelerate cloud infrastructure, mostly based on Ethernet [8].

Clos dominates the landscape of cloud data centers and supercomputers [9, 1, 4]. Yet, many recent low-diameter topologies claim to outperform Clos in the cost-performance tradeoff. For example, Slim Fly can be \approx$$2\times more cost- and power-efficient while offering $\approx$25% lower latency. Similar numbers were reported for Jellyfish [10] and Xpander [4]. Thus, modern low-diameter networks may significantly enhance compute capabilities of Ethernet clusters.

However, to the best of our knowledge, no high-performance routing architecture has been proposed for low-diameter networks based on Ethernet stacks. The key issue here is that traditional routing schemes (e.g., Equal-Cost Multipath (ECMP) [11]) cannot be directly used in networks such as Slim Fly, because (as we will show) there is almost always only one shortest path between endpoint pairs (i.e., shortest paths fall short). Restricting traffic to these paths does not utilize such topologies’ path diversity, and it is unclear how to split traffic across non-shortest paths of unequal lengths.

To answer this, we propose FatPaths, the first high-performance, simple, and robust routing architecture for low-diameter networks, to accelerate both HPC systems and cloud infrastructure that use Ethernet. FatPaths uses our key research outcome: although low-diameter networks fall short of shortest paths, they have enough “almost” shortest paths. This insight comes from our in-depth analysis of path diversity in five low-diameter topologies (contribution #1). Then, in our key design outcome, we show how to encode this rich diversity of non-minimal paths in low-diameter networks in commodity hardware (HW) using a novel routing approach called layered routing (contribution #2). Here, we divide network links into subsets called layers. One layer contains at least one “almost” shortest path between any two endpoints. Non-minimal multipath routing is then enabled by using more than one layer.

For higher performance in TCP environments, FatPaths uses a high-performance transport design. We seamlessly combine layered routing with several TCP enhancements [1] (such as lossless metadata exchange – packet headers always reach their destinations, shallow buffers, and priority queues for retransmitted packets to avoid head-of-line congestion [1]) and we use flowlet switching [12], a scheme that enables very simple but powerful load balancing by sending batches of packets over multiple layers (contribution #3).

We exhaustively compare FatPaths to other routing schemes in Table I (contribution #4). FatPaths is the only scheme that simultaneously (1) enables multi-pathing using both (2) shortest and (3) non-shortest paths, (4) explicitly considers disjoint paths, (5) offers adaptive load balancing, and (6) is applicable across topologies. Table I focuses on path diversity, because, as topologies lower their diameter and reduce link count, path diversity – key to high-performance routing – becomes a scarce resource demanding careful examination.

We discuss integration of FatPaths not only with Ethernet and TCP, but also with Data Center TCP (DCTCP) [13] and Multipath TCP (MPTCP) [14]. Next, we discuss how FatPaths could enhance Infiniband [15] and sketch implementing RDMA [7] (iWARP [16], RoCE [6]) on top of FatPaths.

We conduct extensive, large-scale packet-level simulations (contribution #5), and a comprehensive theoretical analysis (contribution #6). We simulate topologies with up to $\approx$1 million endpoints. We motivate FatPaths in Figure 2. Slim Fly and Xpander equipped with FatPaths ensure $\approx$15% higher throughput and $\approx$2$\times$ lower latency than similar-cost fat trees.

We stress that FatPaths outperforms the bleeding-edge Clos proposals based on per-packet load balancing (these schemes account for packet-reordering) and novel transport mechanisms, that achieve $3$-$4\times$ smaller tail flow111In performance analyses, we use the term “flow”, which is equivalent to a “message”. completion time (FCT) than Clos based on ECMP [1, 28]. Consequently, our work illustrates that low-diameter networks can continue to claim an improvement in the cost-performance tradeoff against the new, superior Clos baselines (contribution #7).

Towards the above goals, we contribute:

• •

A high-performance, simple, and robust routing architecture, FatPaths, that enables modern low-diameter topologies such as Slim Fly to achieve unprecedented performance.

• •

A novel routing approach called layered routing that is a key ingredient of FatPaths and facilitates using diversity of non-minimal paths in modern low-diameter networks.

• •

The first detailed analysis of path diversity in five modern low-diameter network topologies, and the identification of the diversity of non-minimal paths as a key resource for their high performance.

• •

A novel path diversity metric, Path Interference, that captures bandwidth loss between specific pairs of routers.

• •

A comprehensive analysis of existing routing schemes in terms of their support for path diversity.

• •

A theoretical analysis showing FatPaths’ advantages.

• •

Extensive, large-scale packet-level simulations (up to $\approx$one million endpoints) to demonstrate the advantages of low-diameter network topologies equipped with FatPaths over very recent Clos designs, achieving 15% higher net throughput at 2$\times$ lower latency for comparable cost.

II Notation, Background, Concepts

We first outline basic concepts; Table II shows the notation.

II-A Network Model

We model an interconnection network as an undirected graph $G=(V,E)$; $V$ and $E$ are sets of routers222We abstract away HW details and use a term “router” for L2 switches and L3 routers. ($|V|=N_{r}$) and full-duplex inter-router physical links. Endpoints are not modeled explicitly. There are $N$ endpoints, $p$ endpoints are attached to each router (concentration) and $k^{\prime}$ channels from each router to other routers (network radix). The total router radix is $k=p+k^{\prime}$. The diameter is $D$ while the average path length is $d$.

II-B Topologies and Fair Topology Setup

We consider all recent low-diameter networks: Slim Fly (SF) [55] (a variant with $D=2$), Dragonfly (DF) [23] (the “balanced” variant with $D=3$), Jellyfish (JF) [10] (with $D=3$), Xpander (XP) [4] (with $D\leq 3$), HyperX (Hamming graph) (HX) [56] that generalizes Flattened Butterflies (FBF) [57] with $D=3$. We also use established three-stage fat trees (FT3) [58] that are a variant of Clos [59]. Note that we do not detail the considered topologies. This is because our design does not rely on any specifics of these networks (i.e., FatPaths can be used in any topology, but from performance perspective, it is most beneficial for low-diameter networks). The considered topologies are illustrated in Table III.

We use four size classes: small ($N\approx 1,000$), medium ($N\approx 10,000$), large ($N\approx 100,000$), and huge ($N\approx 1,000,000$). We set $p=\frac{k^{\prime}}{d}$ (in Section VII we show that, assuming random uniform traffic, $p=\frac{k^{\prime}}{d}$ maximizes throughput while minimizing congestion and network cost). Third, we select network radix $k^{\prime}$ and router count $N_{r}$ so that, for a fixed $N$, the compared topologies use similar amounts of hardware for similar construction costs.

Jellyfish – unlike other topologies – is “fully flexible”: There is a JF instance for each combination of $N_{r}$ and $k^{\prime}$. Thus, to fully test JF, for each other network X, we use an equivalent JF (denoted as X-JF) with identical $N_{r},k^{\prime}$.

II-C Traffic Patterns

We analyze recent works [55, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73] to select traffic patterns that represent important HPC and datacenter workloads. Denote a set of endpoint IDs $\{1,...,N\}$ as $V_{e}$. Formally, a traffic pattern is a mapping from source endpoint IDs $s\in V_{e}$ to destination endpoints $t(s)\in V_{e}$. First, we select random uniform ($t(s)\in V_{e}\text{\ u.a.r.,}$) and random permutation ($t(s)$ $=\pi_{N}(s)$, where $\pi_{N}$ is a permutation selected  u.a.r.,) that represent irregular workloads such as graph computations, sparse linear algebra solvers, and adaptive mesh refinement methods [74]. Second, we pick off-diagonals ($t(s)=(s+c)\mod N$, for fixed $c$) and shuffle ($t(s)=\operatorname{rotl}_{i}(s)\mod N$, where the bitwise left rotation on $i$ bits is denoted as $\operatorname{rotl}_{i}$ and $2^{i}<N<2^{i+1}$). They represent collective operations such as MPI-all-to-all or MPI-all-gather [55, 74]. We also use stencils, realistic traffic patterns common in HPC. We model 2D stencils as four off-diagonals at fixed offsets $c\in\{\pm 1,$ $\pm 1,\pm 42,$ $\pm 42\}$. For large simulations ($N>10,000$) we also use offsets $c\in\{\pm 1,$ $\pm 1,\pm 1337,$ $\pm 1337\}$ to reduce counts of communicating endpoint pairs that sit on the same switches. Finally, we use adversarial and worst-case traffic patterns. In the former, we use a skewed off-diagonal with large offsets (we make sure that it has many colliding paths). For the latter, we use a pattern (detailed in § VI) that maximizes stress on the interconnect individually for each topology.

III FatPaths Architecture: Overview

We show FatPaths’ architecture in Figure 3. The key part, layered routing, is summarized here and detailed in Section V. For higher performance, FatPaths uses simple and robust flowlet load balancing, “purified” high-performance transport, and randomized workload mapping. Combined, they effectively use the “fat” diversity of minimal and non-minimal paths.

III-A Layered Routing ❶

To encode minimal and non-minimal paths with commodity HW, FatPaths divides all links into (not necessarily disjoint) subsets called layers333In FatPaths, a “layer” is formally a subset of links. We use the term “layer” as our concept is similar to “virtual layers” known from works on deadlock-freedom [75]. Routing within each layer uses shortest paths; these paths are usually not shortest when considering all network links. Different layers encode different paths between each endpoint pair. This enables taking advantage of the diversity of non-minimal paths in low-diameter topologies. The number of layers is minimized to reduce hardware resources needed to deploy layers. Layers can easily be implemented with commodity schemes, e.g., VLANs or a simple partitioning of the address space.

III-B Simple and Effective Load Balancing ❷

For simple but robust load balancing, we use flowlet switching [76, 12], a technique traditionally used to alleviate packet reordering in TCP. A flowlet is a sequence of packets within one flow, separated from other flowlets by sufficient time gaps, which prevents packet reordering at the receiver. Flowlet switching can also provide a very simple load balancing: a router simply picks a random path for each flowlet, without any probing for congestion [5]. This scheme was used for Clos networks [5]. Such load balancing is powerful because flowlets are elastic: their size changes automatically based on conditions in the network. On high-latency and low-bandwidth paths, flowlets are usually smaller in size because time gaps large enough to separate two flowlets are more frequent. Contrarily, low-latency and high-bandwidth paths host longer flowlets as such time gaps appear less often. Now, we propose to use flowlets in low-diameter networks, to load balance FatPaths. We combine flowlets with layered routing: flowlets are sent using different layers. The key observation is that elasticity of flowlets automatically ensures that such load balancing considers both static and dynamic network properties (e.g., longer vs. shorter paths as well as more vs. less congestion). Consider a pair of communicating routers. As we show in § IV, virtually all router pairs in a low-diameter network are connected with exactly one shortest part but multiple non-minimal paths, possibly of different lengths. A shortest path often experiences smallest congestion while longer paths are more likely to be congested. Here, flowlet elasticity ensures that larger flowlets are sent over shorter and less congested paths. Shorter flowlets are then transmitted over longer and usually more congested paths.

III-C Purified Transport ❸

The FatPaths transport layer is inspired by the NDP [1] Clos design, in that it removes virtually all TCP/Ethernet performance issues. First, if router queues fill up, only packet payload is dropped; headers with all the metadata are preserved and the receiver has full information on the congestion in the network and can pull the data from the sender at a rate dictated by the evolving network conditions. Specifically, the receiver can request to change a layer, if packets transmitted over this layer arrive without payload, indicating congestion. Second, routers can prioritize (1) headers of packets that lost payload, and (2) retransmitted packets. Thus, congested flows finish quickly and head-of-line-blocking is reduced. Third, senders transmit the first RTT at line rate (no probing for available bandwidth). Finally, router queues are shallow. The resulting transport layer has low latency and high throughput, it meets demands of various traffic patterns, and it can be implemented with existing network technology.

III-D Randomized Workload Mapping ❹

We optionally assign communicating endpoints to routers randomly. This is often done in HPC. We stress that this scheme is even more beneficial in FatPaths due to the low diameter of targeted networks. Specifically, we place communicating endpoints at routers chosen u.a.r., to distribute load more evenly over the network. The motivation is as follows. First, in future large-scale data centers and supercomputers, locality cannot be effectively utilized: Paths of 0–1 hops asymptotically disappear as $N$ grows (in the random uniform traffic). Moreover, one often cannot rely on locality due to schedulers or virtualization. For example, Cray machines often host processes from one job in different machine parts to increase utilization [77]. Furthermore, many workloads, such as distributed graph processing, have little or no locality [78]. Finally, the low diameter of used topologies, especially $D=2$, mostly eliminates the need for locality-aware software. We predict that this will be a future trend as reducing cost and power consumption with simultaneous increase in scale is inherently associated with reducing diameter [55]. Still, to cover applications tuned for locality, we show that FatPaths also ensures speedups of non-randomized workloads.

IV Path Diversity in Low-Diameter Topologies

FatPaths enables using the diversity of paths in low-diameter topologies for high-performance routing. To develop FatPaths, we first need to understand the “nature” of path diversity that FatPaths benefits from. For this, we first show that low-diameter topologies exhibit congestion due to conflicting flows even in mild traffic scenarios, and we derive the minimum number of disjoint paths that eliminate flow conflicts (§ IV-A). We then formalize the “path diversity” notion (§ IV-B) to show that all low-diameter topologies have few shortest but enough non-minimal paths to accommodate flow collisions, an important type of flow conflicts (§ IV-C). To the best of our knowledge, we provide the most extensive analysis of path diversity in low-diameter networks (considering the number of path diversity metrics and topologies), cf. Related Work.

The key motivation for this analysis is that modern low-diameter topologies have good expansion properties [79, 4]. Intuitively, such a (sparse) network should not offer much path diversity. We illustrate that, contrarily to this intuition, modern low-diameter topologies do indeed offer path diversity that is enough to ensure high performance of specified traffic patterns without congestion, when considering non-minimal paths. Finally, our goal is to also provide deeper understanding of how to analyze path diversity.

IV-A How Much Path Diversity Do We Need?

FatPaths uses path diversity to avoid congestion due to conflicting flows, i.e., flows that share at least one inter-router link. Such conflicts depend on both how communicating endpoints are mapped to routers and the topology details. Consider two communicating pairs of endpoints. The generated flows conflict when their paths collide (flows use an identical path) or overlap (flows share some links), see Figure 5. Collisions are caused by workload mapping, when communicating endpoint pairs occupy the same router pairs (i.e., sources and destinations are attached to the same router pair). Thus, collisions only depend on concentration $p$ and the number of routers $N_{r}$. Contrarily, overlaps depend on topology details (i.e., connections between routers). Thus, overlaps capture how well a topology can sustain a given workload.

To understand how much path diversity is needed to alleviate flow conflicts, we analyze the impact of topology properties ($D$, $p$, $N$) and a traffic pattern on the number of colliding paths, see Figure 5. We consider five traffic patterns: a random permutation, a randomly-mapped off-diagonal, a randomly mapped shuffle, four random permutations in parallel, and a randomly mapped 4-point stencil composed of four off-diagonals. The last two patterns are 4$\times$ oversubscribed and thus expected to generate even more collisions. For $D>1$, the number of collisions is at most three in most cases, especially when lowering $D$ (while increasing $p$). Importantly, this holds for the adversarial 4$\times$ oversubscribed patterns that stress the interconnect. For $D=1$, at least nine collisions occur for more than 1% of router pairs, even in mild traffic patterns. While we do not consider $D=1$ in practical applications, we indicate that global DF links form a complete graph, demanding high path diversity at least with respect to the global links.

Takeaway** ** We need at least three disjoint paths per router pair to handle colliding paths in considered workloads, assuming random mapping. Now, we observe that there are at least as many overlapping paths as colliding paths (as seen from a simple counting argument: for each pair of colliding flows $x$ and $y$, any other flow in the network may potentially overlap with $x$ and $y$). Thus, the same holds for overlaps.

IV-B How Should We Measure Path Diversity?

To analyze if low-diameter topologies provide at least three disjoint paths per router pair, we need to first formalize the notion of “disjoint paths” and ”path diversity” in general. For example, we must be able to distinguish between partially or fully disjoint paths that may have different lengths. Thus, we first define the count of disjoint paths (CDP), minimal and non-minimal, between routers (§ IV-B1). These measures address path collisions. Moreover, to analyze path overlaps, we define two further measures: path interference (PI, § IV-B2) and total network load (TNL, § IV-B3). Intuitively, they can be seen as tools for estimating path overlap using local and global topology properties, respectively. We summarize each measure and we provide all formal details for reproducibility; these details can be omitted by readers only interested in intuition. We use several measures because any single measure that we tested cannot fully capture the rich concept of path diversity.

IV-B1 Count of Disjoint Paths (CDP)

We define the count of disjoint paths (CDP) between router sets $A,B\subseteq V$ at length $l$ as the smallest number $c_{l}(A,B)$ of edges that must be removed so that no path of length at most $l$ exists from any router in $A$ to any router in $B$. To compute $c_{l}(A,B)$, first define the $l$-step neighborhood $h^{l}(A)$ of a router set $A$ as “a set of routers at $l$ hops away from $A$”:

[TABLE]

Now, the condition that no path of length at most $l$ exists between any router in $A$ to any router in $B$ is $h^{l}(A)\cap B=\emptyset$. To derive the values of $c_{l}(A,B)$, we use a variant of the Ford-Fulkerson algorithm [80] (with various pruning heuristics) that removes edges in paths between designated routers in $A$ and $B$ (at various distances $l$) and verifies whether $h^{l}(A)\cap B=\emptyset$. We are most often interested in pairs of designated routers $s$ and $t$, and we use $A=\{s\},B=\{t\}$.

Minimal paths are vital in congestion reduction as they use fewest resources for each flow. We derive the distribution of minimal path lengths $l_{\text{min}}$ and counts $c_{\text{min}}$. Intuitively, $l_{\text{min}}$ describes (statistically) distances between any router pairs while $c_{\text{min}}$ provides their respective diversities. We have:

[TABLE]

Note that the diameter $D$ equals $\max_{s,t}\ l_{\text{min}}(s,t)$.

To analyze non-minimal paths, we reuse the count of disjoint paths CDP $c_{l}(A,B)$ of random router pairs $s\in A,t\in B$, but with path lengths $l$ larger than $l_{\text{min}}(s,t)$ ($l>l_{\text{min}}(s,t)$). Here, we are interested in distributions of counts of non-minimal paths for fixed non-minimal distances $l$.

IV-B2 Path Interference (PI)

With Path Interference (PI), we want to quantify path overlaps. This is challenging because overlaps depend on the details of the structure of each topology as well as on workload mappings. Thus, a PI definition must be local in that it should consider all router pairs that may possibly communicate. Consider two router pairs $a,b$ and $c,d$ where $a$ communicates with $b$ and $c$ communicates with $d$. Now, paths between these two pairs interfere if their total count of disjoint paths (at a given distance $l$), $c_{l}(\{a,c\},\{b,d\})$, is lower than the sum of individual counts of disjoint paths (at $l$): $c_{l}(\{a\},\{b\})+c_{l}(\{c\},\{d\})$. We denote path interference with $I^{l}_{ac,bd}$ and define it as

[TABLE]

Path interference captures and quantifies the fact that, if $a$ and $b$ communicate and $c$ and $d$ communicate and the flows between these two pairs use paths that are not fully disjoint (due to, e.g., not ideal routing), then the available bandwidth between any of these two pairs of routers is reduced.

IV-B3 Total Network Load (TNL)

TNL is a simple upper bound on the number of flows that a network can maintain without congestion (i.e., without flow conflicts). There are $k^{\prime}N_{r}$ links in a topology. Now, a flow occupying a path of length $l$ “consumes” $l$ links. Thus, with the average path length of $d$, TNL is defined as $\frac{k^{\prime}N_{r}}{d}$, because $\#flows\leq\frac{k^{\prime}N_{r}}{d}$. Thus, TNL constitutes the maximum supply of path diversity offered by a specific topology.

Takeaway** ** We suggest to use several measures to analyze the rich nature of path diversity, e.g., the count of minimal and non-minimal paths (for collisions), and path interference as well as the total network load (for overlaps).

IV-C Do We Have Enough Path Diversity?

We now use our measures for path diversity analysis.

IV-C1 Analysis of Minimal Paths

Selected results for minimal paths are in Figure 6. In DF and SF, most routers are connected with one minimal path. In XP, more than 30% of routers are connected with one minimal path. Only in HX, most router pairs have two minimal paths. In JF, the results are more leveled out, but pairs of routers with one shortest part in-between still form large fractions. FT3 and HX show the highest diversity, with very few unique minimal paths, while the matching JFs have lower diversities. The results match the structure of each topology (e.g., one can distinguish intra- and inter-pod paths in FT3).

Takeaway** ** In all the considered low-diameter topologies, shortest paths fall short: at least a large fraction of router pairs are connected with only one shortest path.

IV-C2 Analysis of Non-Minimal Paths

Based on the collision multiplicity found in § IV-A, we aim to obtain at least three disjoint paths per router pair. For non-minimal paths, we first summarize the results in Table IV. We report counts of disjoint paths as fractions of router radix $k^{\prime}$ to make these counts radix-invariant. For example, the mean CDP of 89% in SF means that 89% of router links host disjoint paths. In general, all deterministic topologies provide higher disjoint path diversity than their corresponding JFs, but there are specific router pairs with lower diversity that lead to undesired tail behavior. JFs have more predictable tail behavior due to the Gaussian distribution of $c_{l}(A,B)$. A closer analysis of this distribution (Figure 7) reveals details about each topology. For example, for HX, router pairs can clearly be separated into classes sharing zero, one, or two coordinate values, corresponding to the HX array structure. Another example is SF, where lower $c_{l}(A,B)$ are related to pairs connected with an edge while higher $c_{l}(A,B)$ in DF are related to pairs in the same group or pairs connected with specific sequences of local and global links.

Takeaway** ** Considered topologies provide three disjoint “almost”-minimal (one hop longer) paths per router pair.

Note that $d$ depends on used routing and may be larger or smaller than $D$: with minimal routing, $d\leq D$. With non-minimal routing, it can be larger: Valiant’s algorithm doubles $d$ compared to minimal routing. This cannot always be avoided (e.g., it affects cliques). While $D=1$ promises a high possible $p$, this configuration leads to a high number of path collisions which need to be handled using length 2 paths. Those increase $d$, which in turn requires $p$ to be reduced to avoid congestion, according to the TNL argument. Yet, for randomized workloads and $D\geq 2$, as we showed in § IV-A, the total amount of path collisions is low, which means non-minimal routing is feasible without decreasing $p$.

IV-C3 Analysis of Path Interference

Next, we sample router pairs u.a.r. and derive full path interference distributions; they all follow the Gaussian distribution. Selected results are in Figure 8 (we omit XP and XP-JF; both are nearly identical to SF-JF) As the combination space is very large, most samples fall into a common case, where PI is small. We thus provide full data in the report and focus on the extreme tail of the distribution (we show both mean and tail), see Table IV. We use radix-invariant PI values (as for CDP) at a distance $d^{\prime}$ selected to ensure that the 99.9% tail of collisions $c_{d^{\prime}}(A,B)$ is at least $3$. Thus, we analyze PI in cases where demand from a workload outgrows the “supply of path diversity” from a network (three disjoint paths per router pair). All topologies except for DF achieve negligible PI for $d^{\prime}=4$, but the diameter-2 topologies do experience PI at $d^{\prime}=3$. SF shows the lowest PI in general, but has (few) high-interference outliers. In general, random JFs have higher average PI but less PI in tails. Deterministic topologies perform better on average, but with worse tails; randomization helps to improve tail behavior.

IV-D Final Takeaways on Path Diversity

We show a fundamental tradeoff between path length and diversity. High-diameter topologies (e.g., FT) have high path diversity, even on minimal paths. Yet, due to longer paths, they need more links for an equivalent $N$ and performance. Low-diameter topologies fall short of shortest paths, but do provide enough diversity of non-minimal paths, requiring non-minimal routing. Yet, this may reduce the cost advantage of low-diameter networks with adversarial workloads that use many non-minimal paths, consuming additional links. Workload randomization in FatPaths suffices to avoid this effect. Overall, low-diameter topologies host enough path diversity for alleviating flow conflicts. We now show how to effectively use this diversity in FatPaths.

V FatPaths: Design and Implementation

FatPaths is a high-performance, simple, and robust routing architecture that uses rich path diversity in low-diameter topologies to enhance Ethernet stacks in data centers and supercomputers. FatPaths aims to accelerate both datacenter and HPC workloads. We outlined FatPaths in § III. Here, we detail the layered routing scheme that is capable of encoding the rich diversity of both minimal and non-minimal paths, and can be implemented with commodity Ethernet hardware.

V-A Routing Model

We assume simple destination-based routing, compatible with any relevant technology, including source-based systems like NDP. To compute the output port $j\in\{1,\dots,k^{\prime}\}$ in a router $s\in V$ for a packet addressed to a router $t\in V$, and simultaneously the ID of the next-hop router $s^{\prime}\in V$, a routing function $(j,s^{\prime})=\sigma(s,t)$ is evaluated. By iteratively applying $\sigma$ with fixed $t$ we eventually reach $s^{\prime}=t$ and finish. We call the $l+1$ item sequence $(s,s^{\prime},\dots,t)$ a path of length $l$. The forwarding function $\sigma$ must be defined such that a path from any $s$ to any $t$ is loop-free. For layered routing in FatPaths, we use routing functions $\sigma_{1},\dots,\sigma_{n}$, where each router uses function $\sigma_{i}$ for a packet with a layer tag $i$ attached. The layer tags are chosen on the endpoint by the adaptivity algorithm.

V-B Layered Routing in FatPaths

We use $n$ routing functions $\sigma_{1},\dots,\sigma_{n}$ for $n$ layers. Each router uses $\sigma_{i}$ for a packet with a layer tag $i$ attached. The layer tags are chosen on the endpoint by the adaptivity algorithm. We use $n$ layers associated with $n$ routing functions. Each router uses the $i$-th routing function, denoted as $\sigma_{i}$, for a packet with a layer tag $i$ attached. All layers but one accommodate a fraction of links, maintaining non-minimal paths. One layer (associated with $\sigma_{1}$) uses all links to host minimal paths. The fraction of links in one layer is controlled by $\rho\in[0;1]$. Now, the interplay between $\rho$ and $n$ is important. More layers (higher $n$) that are sparse (lower $\rho$) give more paths that are long, giving more path diversity, but also more wasted bandwidth (as paths are long). More layers that are dense reduce wasted bandwidth but also give fewer disjoint paths. Still, this may be enough as we need three paths per router pair. One ideally needs more dense layers or fewer sparse layers. Thus, an important part of deploying FatPaths is selecting the best $\rho$ and $n$ for a given network. Assuming enough minimal path diversity, we can obtain different routes even with the same layer. Thus, we try to pick different next-hop choices for each layer if there is enough minimal-path diversity in the layer. We evaluate different fractions of links per layer to find a good compromise, which can entail $\rho=1$ for all layers if there is high minimal-path diversity in the topology. To facilitate implementation of FatPaths, the project repository contains layer configurations ($\rho,n$) that ensure high-performance routing for used topologies. We analyze performance of different $\rho$ and $n$ in § VI and § VII.

V-B1 Interplay of Parameters: Discussion

The layers are intentionally not disjoint. Specifically, we use minimum routing within the layers. Thus, to obtain enough non-minimal paths, the layers need to by sparse. However, we also want to use “not too many” non-minimal paths (“just enough”), so having many edges per layer is also important.

That is why $\rho$ is an adjustable parameter (that needs to be tuned at least for a given topology and a given number of layers $n$): $\rho$ needs to be low enough to enable enough non-minimal paths at the given number of layers. Thus, with many layers, one can use higher $\rho$ and still obtain enough path diversity. The benefit is then having on average more shortest paths, and therefore less total load (TNL), cf. § IV-B3. This will be visible in Figure 12: with lower $\rho$, we get more longer paths, which can improve tail performance (thanks to better load balancing) but has a cost in average throughput (due to the higher TNL). For both very low and very high $\rho$, both tail performance and the average throughput suffer.

In practice, with the FatPaths layered routing, we obtain many non-disjoint paths across multiple layers, where many of them are minimal. The FatPaths design then leaves it up to the flowlet load balancing to decide which ones should be picked for sending the next flowlet.

V-B2 Layer Construction: Random Uniform Edge Sampling

An overview of layer construction is in Listing LABEL:lst:layers. We start with one layer with all links, maintaining shortest paths. We use $n-1$ random permutations of vertices to generate $n-1$ random layers. Each such layer is a subset $E^{\prime}\subset E$ with $\lfloor\rho\cdot|E|\rfloor$ edges sampled u.a.r.. $E^{\prime}$ may disconnect the network, but for the used values of $\rho$, this is unlikely and a small number of attempts delivers a connected network. Note that the algorithm for constructing layers is general and can be used with any topology; cf. § II-B and Section VIII.

V-B3 Layer Construction: Minimizing Path Overlap

We also use a variant in which, instead of randomized edge picking while creating paths within layers, a simple heuristic minimizes path interference. For each router pair, we pick a set of paths with minimized overlap with paths already placed in any of the layers. Most importantly, while computing paths, we prefer paths that are one hop longer than minimal ones, using the insights from the path diversity analysis (§ IV). The algorithm is depicted in Listing LABEL:lst:layersFp.

In general, the algorithm selects pairs of vertices $(u,v)\in V\times V$ with lowest priority from the priority queue $Q$ (pairs with lowest priority are assigned the smallest number of paths that have already been placed in the layers), finds the shortest directed path from $u$ to $v$ of length at least equal to $L_{min}$ (a functionality provided by ${find{\_}path}$), and adds the found path to the layer which is currently being created.

At the moment of initialization, every layer generates $\mathcal{V}$ – a set containing all pairs of vertices $(u,v)\in V\times V$. This set will be used to supervise the process of vertices selection and to keep track of the pairs that can still be sampled from $Q$. The $Q.pop()$ function returns a pair of vertices still present in $\mathcal{V}$, which has the lowest priority in $Q$ (in case of equal priorities, ties are broken randomly).

After processing a pair of vertices $(u,v)$ chosen from $Q$, and adding a valid directed path $(v_{1},v_{2},\dots v_{d})$ to a layer (such that $v_{1}=u$, $v_{d}=v$ and $d\geq L_{min}+1$), pairs of vertices $(v_{i},v_{j})$, such that $j-i<L_{min}$, may be deleted from $\mathcal{V}$, as even if an additional path from $v_{i}$ to $v_{j}$ of length at least $L_{min}$ will be added, there will still exist a shorter path between these vertices (the one contained by the path $(v_{1},v_{2},\dots v_{d})$). Thus, the new path will not be used to forward the traffic between these two vertices in this layer.

Similarly, if the layer already includes a path $(v_{1},v_{2},\dots v_{d})$, then adding an edge between any two not directly connected vertices $v_{1},\dots v_{d}$, will force the traffic from $v_{1}$ to $v_{d}$ to be forwarded using such a shorter path, using the added edge. This may not necessarily introduce a decline of overall achievable throughput. However, it impedes the process of tracking pairs of vertices, that have already various paths between them provided. In order to avoid this, we exclude all edges $(v_{i},v_{j})$, such that $|i-j|>1$. This is achieved through the definition and usage of $incidence_{G}$ variable representing the incidence matrix of the graph $G$.

As the ${find\_path}$ function takes the given permutation $\pi$ into consideration, while searching for the path (the function considers only these edges $(v_{i},v_{j})\in E$, for which $\pi(v_{i})<\pi(v_{j})$), there is no need to verify whether adding the path to the graph will create any cycle. Additionally, the edges are being processed by the $find\_path$ function in the order given by the $W$ matrix, to use the least exploited (so far) edges.

In order to enhance the efficiency of generating each of the layers a constant $M$ has been introduced, which helps to limit the number of pairs of vertices, for which paths can be added, per each layer. It also helps to distribute the paths more evenly between the layers.

V-C Populating Forwarding Entries

The $\sigma_{i}$ functions are deployed with forwarding tables. An example scheme for deriving and populating forwarding tables is illustrated in Appendix C-A. To derive these tables, we compute minimum paths between every two routers $s$, $t$ within layer $\sigma_{i}$. Then, for each router $s$, we populate the entry for $s$, $t$ in $\sigma_{i}$ with a port that corresponds to the router $s_{i}$ that is the first step on a path from $s$ to $t$. We compute all such paths and choose a random first step port, if there are multiple options. For any hypothetical network size, constructing layers is not a computational bottleneck, given the $\mathcal{O}(N^{2}\log N)$ complexity of Dijkstra’s shortest path algorithm for $N$ vertices [81].

V-D Implementation of Layers

We propose two schemes to deploy layers. First, a simple way to achieve separation is partitioning of the address space. This requires no hardware support, except for sufficiently long addresses. One inserts the layer tag anywhere in the address, the resulting forwarding tables are then simply concatenated. The software stack must support multiple addresses per interface (deployed in Linux since v2.6.12, 2005). Next, similarly to SPAIN [52] or PAST [41], one can use VLANs [82] that are a part of the L2 forwarding tuple and provide full separation. Still, the number of available VLANs is hardware limited.

V-E Implementation of Forwarding Functions

Forwarding functions can be implemented with simple lookup tables (flat Ethernet exact matching or hierarchical TCAM longest prefix matching tables). In the former, one entry maps a single input tuple to a single next hop. The latter are usually much smaller but more powerful: one entry can provide the next hop information for many input tuples.

As not all the considered topologies are hierarchical, we cannot use all the properties of longest match tables. Still, we observe that all endpoints on one router share the routes towards that router. We can thus use prefix-match tables to reduce the required number of entries from $\mathcal{O}(N)$ to $\mathcal{O}(N_{r})$. This only requires exact matching on a fixed address part. As we target low-diameter topologies, space savings due to moving from $\mathcal{O}(N)$ to $\mathcal{O}(N_{r})$ can be large. For example, an SF with $N=10,830$ has $N_{r}=722$. Such semi-hierarchical forwarding was proposed in PortLand [9] (hierarchical pseudo MAC addresses) or shadow MACs [51]. As we use a simple, static forwarding function, it can also be implemented on the endpoints themselves, using source routing [54].

V-F Adaptive Load Balancing + Transport

We now provide more details on the interplay between FatPaths’ load balancing based on LetFlow [5] and transport based on NDP [1], expanding on Section III. For portability and performance, we integrate FatPaths with LetFlow, a simple yet powerful congestion control scheme that uses the middle-ground granularity of flowlets, instead of packets or flows, in load balancing. LetFlow originally operates within routers. Instead, we select a layer for each flowlet at the endpoint. Now, NDP, that is a basis of the transport protocol in FatPaths, does not include a proper adaptivity solution (it uses oblivious per-packet load balancing). In FatPaths, we combine the endpoint-based flowlet adaptivity with NDP: The destination endpoint, which handles flow control in NDP, can request to change the layer, when it observes truncated packets signaling network congestion. This provides the necessary flowlet length elasticity that implements LetFlow adaptivity. The layer tags are chosen on the endpoint by the adaptivity algorithm.

V-G Fault-Tolerance

Fault-tolerance in FatPaths is based on preprovisioning multiple paths within different layers. For major (infrequent) topology updates, we recompute layers [52]. Otherwise, when a failure in some layer is detected, FatPaths redirects the affected flows to a different layer. Here, unlike schemes such as DRILL [83], FatPaths – by targeting low-diameter topologies – is natively resilient to the network asymmetry also caused by failures. Traffic redirection relies on flowlets [5]. As with congestion, the elasticity of flowlets automatically prevents data from using an unavailable path (i.e., the flowlet based load balancing randomly picks paths for flowlets and lets their elasticity automatically load-balance the traffic on available paths). Thus, its design is inherently asymmetric and failures that for example affect the availability of shortest paths are redirected at the endpoints by balancing flowlets.

For failure detection, we rely on established mechanisms [52, 39, 53, 5, 1].

Besides flowlet elasticity, the layered FatPaths design enables other fault-tolerance schemes. For example, FatPaths could limit each layer to be a spanning tree and use mechanisms such as Cisco’s proprietary Per-VLAN Spanning Tree (PVST) or IEEE 802.1s MST to fall back to the secondary backup ports offered by these schemes. Finally, assuming L3/IP forwarding and addressing, one could rely on resilience schemes such as VIRO’s [39].

VI Theoretical Analysis

We first conduct a theoretical analysis. The main goal is to illustrate that layered routing in FatPaths enables higher throughput than SPAIN [52], PAST [41, 53], and $k$-shortest paths [10], three recent schemes that support (1) multi-pathing and (2) disjoint paths (as identified in Table I). SPAIN uses a set of spanning trees, using greedy coloring to minimize their number; one tree is one layer. Then, paths between endpoints are mapped to the trees, maximizing path disjointness. PAST uses one spanning tree per host, aiming at distributing the trees uniformly over available physical links. Finally, $k$-shortest paths [10] spreads traffic over multiple shortest paths (if available) between endpoints. In Appendix C, we provide detailed descriptions of SPAIN, PAST, and $k$-shortest paths, and of how we integrate them in the FatPaths layered routing.

VI-A Definitions and Formulations

We now present the associated mathematical concepts. Two important notions are the maximum achievable throughput (MAT) and the multi-commodity flow (MCF) problem.

VI-A1 Multi-Commodity Flow Problem (MCF): Intuition

Assume a network with predefined (1) flow demands between source and destination endpoints, and (2) constraints on the capacities of links. Now, the problem of assigning an amount of flow to be supplied between the endpoint pairs, which is feasible in the network (i.e., the sums of flows between endpoint pairs do not exceed the capacities of respective links) is called the Multi-Commodity Flow (MCF) problem [84].

VI-A2 Maximum Achievable Throughput (MAT): Intuition

Intuitively, the maximum achievable throughput may be defined as the ratio of the flow that can be forwarded between each pair of network endpoints to the demanded amount of flow for this pair (for a given traffic pattern). In our analysis, to derive a single MAT value for all communicating endpoints (for a given traffic matrix, a given topology, and a given routing scheme), we maximize the minimum flow across all flow demands, assuming each pair of endpoints is able to send and receive flows concurrently. The derivation is done using linear programming (LP).

VI-A3 MCF Linear Programming Formulations for MAT

We now presented the MCF LP formulations, both for the general problem of maximizing throughput under general routing, and when a layered routing is assumed.

MAT is formally defined as the maximum value $\mathcal{T}$ for which there exists a feasible multi-commodity flow that routes a flow $T(s,t)\cdot\mathcal{T}$ between all router pairs $s$ and $t$, satisfying link capacity and flow conservation constraints. $T(s,t)$ specifies traffic demand; it is the amount of requested flow from $s$ to $t$ (more details about MAT and $T(s,t)$ are in [85]).

Let us denote the directed graph representing the network topology by $G=(V,E)$, where $V$ is the set of vertices (switches) and $E$ is the set of edges. Each edge $(u,v)\in E$ represents a network link with non-negative capacity $c(u,v)$.

General MCF Formulation

Given a graph $G$ defined as above, let us denote $k$ different commodities by $K_{1},K_{2},\dots,K_{k}$, where $K_{i}=(s_{i},t_{i},T(s_{i},t_{i}))$. A single commodity indicates a single flow demand between some communicating pair of endpoints. Here, $s_{i}$ is the source node of commodity $i$ while $t_{i}$ is the destination node. The variable $f_{iuv}$ defines the fraction of demanded flow of commodity $i$ from vertex $u$ to vertex $v$. $f_{i}$ is a real-valued function satisfying the flow conservation and capacity constraints, where $f_{i}\in[0,1]$. The MCF problem may be formulated as the problem of finding an assignment of all flow variables satisfying the following constraints:

Eq. (1) defines the capacity constraints. Eq. (2) defines the flow conservation on non-source and non-destination nodes. Eq. (3) defines the flow conservation at the source node. Finally, Eq. (4) defines the non-negativity constraints.

MCF Formulations for Layered Routing in FatPaths

In contrast to the original multi-commodity flow problem, whose aim was finding an assignment of all flow variables satisfying the constraint rules, the main goal of the linear program used for the purpose of our evaluation is maximizing the possible achieved throughput $\mathcal{T}$. Thus, new rules had to be defined for each of the layered routing schemes.

The following rules were defined in order to formulate the LP programs, used further to benchmark the FatPaths and SPAIN routing schemes, assuming $n$ layers and $k$ commodities. The variable $f_{iuvl}$ defines the fraction of the flow of commodity $i$, carried by a link $(u,v)$ in a layer $l$. Moreover, the $\sigma_{i}$ function represents a routing function for layer $i$. For routers $s,t\in V$, the value of function $\sigma_{i}(s,t)$ denotes the next hop router in the path from $s$ to $t$ within layer $i$. Thus, denoting the Kronecker delta by $\delta_{x,y}$, we can easily define function $\delta_{v,\sigma_{i}(u,t)}$, whose output is equal to $1$ if a certain flow $i$ to a destination node $t$ is allowed to pass through a certain link $(u,v)$ and [math] otherwise. We use $\delta_{v,\sigma_{i}(u,t)}$ to ensure that flows within specific layers remain in these layers only.

Now, the main goal of Eq. (5) and (8) is to ensure that all flows allocated for a certain commodity will exit the source node and that it will not exceed some defined upper bound $\mathcal{T}_{upperbound}$ (defined for optimization purposes). Specifically, the sum in Eq. (5), for a given commodity $i$, is equal to the sum of all traffic fractions traversing from the source node $s_{i}$ to the next hop node in any layer. The aim of Eq. (6) is to ensure that the total summed flow will not exceed the link capacity. We assume that the layers provide only a logical representation of graphs built upon existing physical network wiring. Thus, the summed flows from all layers should not exceed the capacity on the physical link (on the left side of Eq. (6), we sum all the traffic (from each commodity and in each layer) that traverses the link from node $u$ to $v$). Eq. (9) is introduced in order to avoid the flow traversing back to the source node through any of the links. On the left side of the equation, we sum all the fractions of the flow in each layer, which traverse from any node $v$ (such that source is the next hop on the path from $v$ to $t_{i}$ within this layer) to source $s_{i}$. Finally, Eq. (7) is the most important constraint to enable benchmarking of the layered routing – its main goal is to ensure that no flow leaks between the layers. Here, the first sum in the equation is equal to the total traffic, which is a fraction of commodity $i$ traffic, that traverses from $u$ to $v$ within layer $l$. The second sum is the total traffic belonging to commodity $i$, which traverses the link from $v$ to $u$ in layer $l$. These two sums have to be equal for every layer, as no traffic is allowed to leak between layers.

VI-B Analysis of Number of Layers

Both SPAIN and PAST use trees as layers, contrarily to FatPaths that allows for arbitrary connected subgraphs. This brings many drawbacks, as each SPAIN layer can use at most $N_{r}-1$ links, while the topology contains $\frac{N_{r}k^{\prime}}{2}$ links. Thus, at least $\mathcal{O}(k^{\prime})$ layers are required to cover all minimal paths, and SPAIN requires even $\mathcal{O}(N_{r})$ on many topologies. Moreover, PAST always needs $O(N)$ trees by its design. By using layers that are arbitrary (but connected) subgraphs and contain a large, constant fraction of links, FatPaths provides sufficient path diversity with a low, $O(1)$ number of layers.

VI-C Analysis of Throughput

We now derive the MAT $\mathcal{T}$. We test all considered topologies, topology sizes, traffic patterns and intensities (fraction of communicating endpoint pairs). We consider two FatPaths variants from § V-B. We use TopoBench, a throughput evaluation tool [85] that uses linear programming (LP) to derive $\mathcal{T}$. We extended TopoBench’s LP formulation of MCF to include layered routing according to our formulation from § VI-A3.

We use a recently proposed worst-case traffic pattern which maximizes stress on the network while hampering effective routing [85], see Figure 10. This pattern is generated individually for each topology; it uses maximum weighted matchings to find a pairing of endpoints that maximizes average flow path length, with both elephant and small flows. As expected, SPAIN – a scheme developed specifically for Clos – delivers more performance on fat trees. Yet, it uses up to $O(N_{r})$ layers. The layered routing that minimizes path interference generally outperforms SPAIN on other networks (we tuned SPAIN to perform as well as possible on low-diameter topologies). Finally, also as expected, our heuristic that minimizes path overlap delivers more speedup than simple random edge picking (we only plot the former for more clarity).

Tested schemes use equally many layers ($n$) to fix the amount of HW resources. Increasing $n$ accelerates all comparison targets but also increases counts of forwarding entries in routing tables. Here, SPAIN and PAST become faster on fat trees and approach FatPaths, but they use up to $O(N_{r})$ layers. FatPaths maintains its advantages for different traffic intensities. As expected, our heuristic that minimizes path overlap outperforms a simple random edge picking.

Takeaway** ** FatPaths layered routing outperforms competitive schemes in the used count of layers (and thus the amount of needed hardware resources) and achieved throughput.

VII Simulations

We now illustrate how low-diameter topologies equipped with FatPaths outperform novel high-performance fat tree designs. Various additional analyses are in Appendix D.

VII-A Methodology, Parameters, and Baselines

We first discuss parameters, methodology, and baselines.

VII-A1 Topologies and Traffic Patterns

We use all topologies specified in § II-B: SF, XP, JF, HX, DF, and FT, in their most beneficial variants (e.g., the “balanced” Dragonfly [23]). We fix the network size $N$ ($N$ varies by up to $\approx$10% as there are limited numbers of configurations of each network). SF represents a recent family of diameter-2 topologies such as Multi-Layer Full-Mesh [67] and Two-Level Orthogonal Fat-Trees [86, 17]. To achieve similar costs and $N$ we use 2$\times$ oversubscribed fat trees. Here, HyperX (HX) is a special case: It has exceedingly high-radix routers but little design flexibility. Thus, it achieves high performance, but at high cost and power consumption [57, 87]. We still evaluate it to consider most recent low-diameter networks.

We use the traffic patterns discussed in § II, in both randomized and skewed non-randomized variants.

VII-A2 Cost Model for Using Topologies of Comparable Cost

We now show how to ensure comparable construction cost of considered topologies. For this, we use the established cost models from past works [55, 23, 57]. Overall, for each “network size category” ($N\in\{\approx 1\text{k},\approx 10\text{k},\approx 100\text{k},\approx 1\text{M}\}$, cf. § II-B), we search for specific topology configurations with minimal differences in their sizes $N$. Their total cost is derived based on existing router and cable cost models based on linear functions [55, 23, 57]. parametrized with prices of modern equipment (e.g., Mellanox equipment listed on ColfaxDirect http://www.colfaxdirect.com). The models distinguish between fiber and copper cables; the former are used for longer router-router links (e.g., inter-group links in DF) and the latter forming short endpoint and router-router connections (e.g., intra-group links in DF or SF). As used topology configurations vary in $N$ (there is always a limited number of configurations of each used topology), for fairness, the final prices are normalized per single endpoint. An example cost model, for $N\approx 10,000$, with the 100Gb Ethernet equipment, is in Figure 10; the prices follow past data [55]. One can distinguish effects caused by topology details, for example lower cable costs in DF due to relatively few expensive global inter-group connections. Variations in final costs are caused by a limited number of topology configurations combined with limited counts of ports in available switches.

VII-A3 Routing and Transport Schemes

We use flow-based non-adaptive ECMP as the baseline (routing performance lower bound). Low-diameter topologies use FatPaths while fat trees use NDP with all optimizations [1], additionally enhanced with LetFlow [5], a recent scheme that uses flowlet switching for load balancing in fat trees. We also compare to a fat tree system using NDP with per-packet congestion-oblivious load balancing as introduced by Handley et al. [1]. For FatPaths, we vary $\rho$ and $n$ to account for different layer configurations, including $\rho=1$ (minimal paths only). We also consider simple TCP, MPTCP, and DCTCP with ECN [13, 88, 89], illustrating that FatPaths can accelerate not only bare Ethernet systems but also cloud computing environments that usually use full TCP stacks [90, 8].

VII-A4 Flows and Messages

We vary flow sizes (and thus message sizes as a flow is equivalent to a message) from 32 KiB to 2 MiB. We use a Poisson distributed flow arrival rate with a $\lambda$ parameter. Flow sizes $v$ are chosen according to the pFabric web search distribution [91], discretized to 20 flows, with an average flow size of 1MB. For the average $v\approx$1MB, we can handle $\approx$1 flow/ms (the injection rate) on a 10G link ($\lambda=1000$ [flows/endpoint/s]). Yet, both our simulations show that even at $\lambda=200$, there is typically more than one concurrent flow per endpoint. This only puts additional stress on flow control, which is not our main focus. Thus, we choose $\lambda=200$ (in TCP simulations) and $\lambda=300$ (in NDP simulations with higher throughput and better flow control). Details and data on flow behavior are in Appendix D-A and D-B.

VII-A5 Metrics

We use (1) flow completion time (FCT), which also represents (2) throughput per flow $\text{TPF}=\frac{\text{flow size}}{\text{FCT}}$. We also consider (3) total time to complete a tested workload 444When reporting some runtimes (cf. Figures 14-17), we use a relative speedup over the plain ECMP baseline for clarity of presentation (as each plot contains runtimes for flows of different sizes, some absolute runtime data becomes hard to read)..

VII-A6 Simulation Infrastructure and Methodology

We use the OMNeT++ [92, 93] parallel discrete event simulator with the INET model package [94] and the htsim packet-level simulator with the NDP reference implementation [1]. OMNeT++ enables detailed simulations of full Ethernet/TCP networking stack, with all overheads coming from protocols such as ARP. We use htsim as its simplified structure enables simulations of networks of much larger scales. We extend both simulators with any required schemes, such as flowlets, ECMP, layered routing, workload randomization. In LetFlow, we use precise timestamps to detect flowlets, with a low gap time of $50$\mathrm{\SIUnitSymbolMicro s} to reflect the low-latency network. As INET does not model hardware or software latency, we add a $1$\mathrm{\SIUnitSymbolMicro s} fixed delay to each link. We also extend the INET TCP stack with ECN (RFC 3168 [95]), MPTCP (RFC 6824 [96], RFC 6356 [97]), and DCTCP. We extend the default router model with ECMP (Fowler-Noll-Vo hash [98]) and LetFlow. In htsim, we use similar parameters; they match those used by Handley et al.. We extend htsim to support arbitrary topologies, FatPaths routing and adaptivity, and our workload model. Routers use tail-dropping with a maximum queue size of 100 packets per port. ECN marks packets once a queue reaches more than 33 packets. Fast retransmissions use the default threshold of three segments. We also model a latency in the software stack (corresponding to interrupt throttling) to 100kHz rate. For FatPaths, we use 9KB jumbo frames, an 8-packet congestion window, and a queue length of 8 full-size packets. All our code is available online.

VII-A7 Scale of Simulations

We fix various scalability issues in INET and OMNeT++ to allow parallel simulation of large systems, with up to $\approx$1 million endpoints. To the best of our knowledge, we conduct the largest shared-memory simulations (endpoint count) so far in the networking community.

VII-A8 Gathering Results and Shown Data

We evaluate each combination of topology and routing method. As each such simulation contains thousands of flows with randomized source, destination, size, and start time, we only record per-flow quantities; this suffices for statistical significance. A run might be affected by a degenerate randomized topology instance, traffic pattern assignment, or layer construction, but for the parameters that we consider, such instances are unlikely and we never observed any during the course of our experiments. We simulate a fixed number of flows starting in a fixed time window, and drop the results from the first window half for warmup. We summarize the resulting distributions with arithmetic means of the underlying time measurements, or percentiles of distributions.

When some variants or parameters are omitted (e.g., we only show SF-JF to cover Jellyfish), this indicates that the shown data is representative.

VII-B Performance Analysis: HPC Systems

First, we analyze FatPaths with Ethernet but without the TCP transport. This setting represents HPC systems that use Ethernet for its low cost, but avoid TCP due to its performance issues. We use htsim that can deliver such a setting.

VII-B1 Low-Diameter Networks + FatPaths Beat Fat Trees

We analyze Figure 2 (page 2, randomized workload) and Figure 11 (skewed non-randomized workload). In each case, low-diameter topologies outperform similar-cost fat trees, with up to 2$\times$ and 4$\times$ improvement in throughput for non-randomized and randomized workload, respectively. Both fat tree and low-diameter networks use similar load balancing based on flowlet switching and purified transport. Thus, the advantage of low-diameter networks is their low diameter combined with the ability of FatPaths to effectively use the diversity of “almost” minimal paths. Answering one of two main questions from § I, we conclude that FatPaths enables low-diameter topologies to outperform state-of-the-art fat trees.

VII-B2 FatPaths Uses “Fat” Non-Minimal Path Diversity Well

We now focus on skewed non-randomized workloads, see Figure 11. Non-minimal balanced routing over FatPaths layers, in each low-diameter topology, leads to an up to $30\times$ FCT improvement over minimal routing (i.e., “circles on topology X outperform triangles on X”). The exception is HyperX, due to its higher minimal path diversity (cf. Figure 6). The traffic causes $p$-way collisions. In HX, its low $p$ explains the relatively good performance of minimal routing on HX. Thus, FatPaths effectively leverages the non-minimal path diversity.

VII-B3 What Layer Setup Is Best?

We also study the impact of the number $n$ and the sparsity $\rho$ of layers in FatPaths on performance and collision resolution; see Figure 12 (layers are computed with random edge sampling, cf. Listing LABEL:lst:layers). Nine layers (one complete and eight sparsified) suffice for three disjoint paths per router pair, resolving most collisions for SF and DF (other networks behave similarly). To understand which $n$ resolves collisions on global channels in DF, we use a complete graph. Here, more layers are needed, since higher-multiplicity path collisions appear (cf. the 99% tail). Moreover, when more layers can be used, a higher $\rho$ is better (cf. FCT for $n=64$). This reduces the maximum achievable path diversity, but also keeps more links available for alternative routes within each layer, increasing chances of choosing disjoint paths. It also increases the count of minimal paths in use across all entries, reducing total network load.

VII-B4 FatPaths Scales to Large Networks

We also simulate large-scale SF, DF, and JF (other topologies lead to excessive memory use in the simulator). We start with SF, SF-JF, and DF ($N\approx$80,000$$) in Figure 13. A slight mean throughput decrease compared to the smaller instances is noticeable, but latency and tail FCTs remain tightly bounded. The comparatively bad tail performance of DF is due to path overlap on the global links, where the adaptivity mechanism needs to handle high multiplicities of overlapping flows. We also conduct runs with $N\approx 1,000,000$ endpoints. Here, we illustrate the distribution of the FCT of flows for SF and SF-JF. Flows on SF tend to finish later that on SF-JF.

VII-C Performance Analysis: Cloud Systems

We also analyze FatPaths on networks with Ethernet and full TCP stack. This represents TCP data centers often used as cloud infrastructure [90]. Here, we use OMNeT++/INET.

We compare FatPaths to ECMP (traditional static load balancing) and LetFlow (recent adaptive load balancing), see Figure 14. The number of layers was limited to $n=4$ to keep routing tables small; as they are precomputed for all routers and loaded into the simulation in a configuration file (this turned out to be a major performance and memory concern). Most observations follow those from § VII-B, we only summarize TCP-related insights.

LetFlow improves tail and short flow FCTs at the cost of long flow throughput, compared to ECMP. Both are ineffective on SF and DF which have little minimal-path diversity. Non-minimal routing in FatPaths and $\rho=0.6$ fixes it, even with only $n=4$ layers. On other topologies, even with minimal paths ($\rho=1$), FatPaths adaptivity outperforms ECMP and LetFlow. Specifically, with non-minimal routing, we observe large improvements in the tail FCT as well as mean throughput in DF and SF. An analysis of the FCT distributions in Fig. 15 shows that with minimal routing and low minimal-path diversity, there are many flows with low performance due to path conflicts, although they do not vastly affect the mean throughput. FatPaths fully resolves this issue and produces an FCT distribution much closer to the queuing model prediction. Short-flow FCTs are dominated by TCP flow control effects, which are mostly unaffected by routing changes.

We also analyze in detail performance effects in flows of different sizes vs. different layer configurations. The findings match those in the “bare Ethernet” simulations in § VII-B. For example, for large flows (1MiB), with $n=4$, the higher $\rho$ is, the faster flows finish. The largest impact of non-minimal routing is for DF and SF, with a 2$\times$ improvement in tail FCT; small improvements on tail FCT are seen in all topologies.

JFs, which provide some minimal-path diversity, can also benefit from non-minimal routing in tail and short flow FCT. However, there is a cost in long flow throughput due to the higher total network load with non-minimal paths. To understand this effect better, Figure 16 shows the impact of the fraction of remaining edges $\rho$ in each layer, and therefore the amount of non-minimal paths, on FCT for long flows. The optimum choice of $\rho$ matches the findings from the Ethernet simulations in § VII-B for SF and DF. For the HyperX topologies, which provide two and three disjoint minimal paths for most router pairs, a different effect can be observed: since there is a higher minimal path diversity, they are typically selected more often over non-minimal ones. This is no better than simply choosing random minimal paths, as it happens at $\rho=1$. Using longer paths just increase the network load and benefit only a few flows in the extreme tail.

Besides FCT means/tails, we also consider a full completion time of a stencil workload that is representative of an HPC application, in which processes conduct local computation, communicate, and synchronize with a barrier; see Figure 17. Results follow the same performance patterns as others. An interesting outcome is JF: high values for LetFlow are caused by packet loss and do not affect the mean/99% tail (cf. Figure 14), only the total completion runtime. Overall, FatPaths ensures high speedups of completion times, e.g., more than 2.5$\times$ and nearly 2$\times$ faster completion times on SF and XP, for flows of the sizes of 200K and 2M bytes, respectively.

FatPaths also enables influencing communication latency: Specifically, whenever lowest latency is prioritized, one can solely use a layer that provides all shortest paths. This ensures low latencies matching those achieved with shortest-path routing in respective networks [55]. For more throughput, one can use any layer configuration offering diversity of almost-minimal paths. Here, any (marginal) latency overheads from the additional router-router hop are caused by the properties of the underlying topology, not the routing protocol.

VII-D Performance Analysis: Routing vs. Topology

How much performance gains in FatPaths come from its routing vs. from simply the benefits of low diameter [55]? Here, we extensively analyzed various design choices in FatPaths; full description is in the extended report. The takeaway is that simple past routing schemes make low-diameter topologies worse ($\approx$2$\times$ and more in FCT) than recent fat tree designs. This is because low diameter must be enhanced with effective tacking of flow conflicts and other detrimental effects, which is addressed by multipathing in FatPaths.

VII-E Performance Analysis: Impact from Partial Design Choices

We also analyze speedups from specific parts of FatPaths, e.g., only the purified transport, flowlet load balancing, layered routing, or non-minimal paths. While many of these elements can solely accelerate workloads in low-diameter networks, it is the combination of effective non-minimal multipath routing, load balancing, and transport that gives superior performance. For example, Figure 11 shows that fat trees with NDP outperform low-diameter networks that do not use multipathing based on non-minimal paths (the “NDP” baseline). Next, different layer configurations ($\rho,n$) for various $D$ are investigated in Figure 12 and in § VII-B (bare Ethernet systems), in Figure 16, and in § VII-C (TCP systems). Differences (in FCT) across layer configurations are up to 4$\times$; increasing both $n$ and $\rho$ maximizes performance. Third, the comparison of adaptive load balancing (“LetFlow”) based on flowlet switching vs. static load balancing (“ECMP”) is in Figure 14 and in § VII-C; adaptivity improves tail and short flow FCTs at the cost of long flow throughput. Fourth, in the comparison of FatPaths with and without Purified Transport, performance with no Purified Transport is always significantly worse. We also analyze performance with and without layered routing (Figure 14, “ECMP” and “LetFlow” use no layers at all); not using layers is detrimental for performance on topologies that have no minimal-path diversity (e.g., SF or DF). Next, we also study the impact of using only the shortest paths in FatPaths (Figure 14, baseline “$\rho=1$”); it is almost always disadvantageous. Finally, the effect from workload randomization is illustrated in Figures 2 (randomization) and 11 (no randomization); randomization increases throughput by $\approx$2$\times$.

Final Performance Takeaway A high-performance routing architecture for low-diameter networks should expose and use diversity of almost minimal paths (because they are numerous, unlike minimal paths). FatPaths enables this, giving speedups on both HPC systems such as supercomputers or tightly coupled clusters, or cloud infrastructure such as data centers.

VIII Discussion

VIII-A Integration with Other Protocols for Wide Applicability

We also discuss integrating FatPaths with Data Center TCP (DCTCP) [13], RDMA [7] (iWARP [16], RoCE [6]), Infiniband [15], MPTCP [14], and non-minimal ECMP on FatPaths.

VIII-A1 DCTCP

We rely on DCTCP’s packet loss to detect and avoid highly congested paths, but also to detect failed links and routes missing in specific layers. This requires only minor changes to the TCP stack: On segment reception, the layer tag in the address is masked out to not interfere with normal operation, and on transmission, the respective bits are populated with the layer tag stored for the flow. The layer tag is initialized to 1, to use a minimal path by default, and randomly modified whenever the congestion window is reduced by DCTCP (which leads to a flowlet boundary), or when an ICMP error is received. By responding to ICMP errors, layered flowlet routing also provides basic fault tolerance.

VIII-A2 MPTCP

We also provide a variant of FatPaths that uses MPTCP for congestion control, as it already provides basic infrastructure and authentication mechanisms for setting up multiple data streams. Our design uses ECN as a measure of congestion instead of packet loss. If an incoming ACK packet does not have the ECN field set, we increase the window analogously to the traditional TCP. Otherwise, (every roundtrip time (RTT)) we update the congestion window size (win size) accordingly.

VIII-A3 Standard TCP

We also considered standard TCP. As a ECN-enabled TCP variant, we extended the standard TCP implementation with ECN echo according to the IETF DCTCP draft and added the matching congestion control algorithm as a module derived from TCPReno which can be used with standard TCP. Since we defined queue limits in packets, we limit the congestion window size to integer multiples of the maximum segment size, to make sure full size segments are transmitted.

VIII-A4 ECMP on Non-Minimal Paths

Our layered design could effectively enable ECMP on non-minimal paths. Specifically, minimal paths in a sparsified layer are effectively non-minimal when considering all the layers (i.e., the whole network). Such layers could then be used by ECMP for multipathing.

VIII-A5 Integration with RDMA

As FatPaths fully preserves the semantics of TCP, one could seamlessly use iWARP [16] on top of FatPaths. FatPaths could also be used together with RoCE [6]. RoCE has traditionally relied on Ethernet with Priority Flow Control [99] (PFC) for lossless data transfer. However, numerous works illustrate that PFC introduces inherent issues such as head-of-line blocking [100, 101, 102, 103]. Now, the design of FatPaths reduces counts of dropped packets to almost zero ($\leq 0.01$%) due to flowlet load balancing. With its packet-oriented design and a thin protocol layer over simple Ethernet, FatPaths could become the basis for RoCE. Moreover, many modern RDMA schemes (e.g., work by Lu et al. [104]) are similar to NDP in that they, e.g., also use packet spraying. Thus, many of our results may be representative for such RDMA environments. For example, using RDMA on top of FatPaths could provide similar advantages on low-diameter topologies as presented in Figure 2 and 11. We leave this for future work.

VIII-A6 Enhancing Infiniband

Although we focus on Ethernet, most of the schemes in FatPaths do not assume anything Ethernet-specific and they could straightforwardly enhance IB routing architecture. For example, all the insights from path diversity analysis, layered routing for multi-pathing, or flowlet load balancing, could also be used with IB. We leave these directions for future work.

VIII-B Integration with Performance Measures and Bounds

For deeper understanding, we intuitively connect our path diversity measures to established network performance measures and bounds (e.g., bisection bandwidth (BB) or throughput proportionality [73]). Figure 18 shows how various measures vary when increasing the network load expressed by count of communicating router pairs $x$. Values of measures are expressed with numbers of disjoint paths $P$. In this expression, bandwidth measures are counts of disjoint paths between two router sets; these numbers must match corresponding counts in the original measure definitions (e.g., path count associated with BB must equal the BB cut size).

VIII-C FatPaths Limitations

To facilitate applicability of our work in real-world installations, we discuss its limitations. First, FatPaths addresses low-diameter topologies, being less beneficial on high-diameter older interconnects such as torus, because such networks provide multiple (almost or completely disjoint) shortest paths between most router pairs. FatPaths also inherits some NDP’s limitations, namely interrupt throttling. As in NDP, this is fixed by dedicating one CPU core to polling for incoming packets.

VIII-C1 Deriving Path Diversity Efficiently

We developed algorithms to efficiently compute diversity measures, basing on schemes by Cheung et. al [105], Ford-Fulkerson [80], Gomory-Hu [106], Gusfield [107]. As these algorithms are outside the core thread of this work, they are detailed in the Appendix.

IX Related Work

FatPaths touches on various areas. We now briefly discuss related works, excluding the ones covered in past sections.

Our work targets modern low-diameter topologies such as Slim Fly [55, 10, 4, 56, 23]. FatPaths enables these networks to achieve low latency and high throughput with various workloads, outperforming similar-cost fat trees.

We analyze routing schemes in Table I and in Section VI. FatPaths is the first to offer generic and adaptive multi-pathing using both shortest and non-shortest disjoint paths. Here, we discuss only layered designs similar to FatPaths. Layered routing exists is various schemes. SPAIN [52] is similar to FatPaths but limits layers to trees. This brings drawbacks, see Section VI. Other protocols are similar to SPAIN, for example PAST [41] that uses one spanning tree per host. However, PAST does not enable multiple paths between two servers, because it uses one spanning tree per destination [53].

Some schemes complement FatPaths in their focus. For example, XPath [53] and source routing [54] could be used together with FatPaths, for example, by providing effective means to encode the rich path diversity exposed by FatPaths.

Adaptive load balancing can be implemented using flows [108, 109, 29, 110, 111, 112, 113, 114, 11], flowcells (fixed-sized packet series) [115], and packets [116, 1, 25, 30, 117, 116, 14, 28]. We choose an intermediate level, flowlets (variable-size packet series) [118, 119, 5, 120, 12]. In contrast, HPC networks often use packet level adaptivity, focusing on choosing good congestion signals, often with hardware modifications [121, 122]. We use flowlet elasticity as introduced by Vanini et al. [5] (which does not need any hardware support) as an adaptivity component to use non-minimal paths efficiently. FatPaths is the first architecture to use load balancing based on flowlets for low-diameter networks.

We do not compete with congestion or flow control schemes; we use them for more performance. FatPaths can use any such scheme in its design [123, 124, 13, 125, 126, 1, 14, 127, 91, 128, 129, 130, 131, 132, 133, 134]. In many HPC networks, flow control is implemented in hardware, since the network is lossless. A backpressure mechanism propagates congestion information through each link up to the endpoints. In contrast, Ethernet-based networks are lossy and flow as well as congestion control needs to be implemented end-to-end, in software, or with schemes such as PFC [135, 99]. Besides the classical TCP Reno and Vegas algorithms, there are more recent schemes such as TIMELY [123], BRR [124] and DCTCP [13], which explicitly require and use ECN. AC/DC [125] move congestion control to the hypervisor, and RackCC [126] even moved it into the network hardware itself. Recently, Handley et al. [1] redesigned end-to-end flow control in Clos topologies entirely, with the NDP protocol (that we incorporate for low-diameter networks in FatPaths). They propose simple changes to the network hardware to support effective per-endpoint flow control, which resolves many well-known issues with TCP, such as the incast problem. Another direction is MPTCP [14], which, among other aspects, allows moving network adaptivity into the endpoint software. More sophisticated flow scheduling was proposed by PIAS [127] or pFabric [91]. Such methods could be combined with our routing scheme to improve real-world application performance.

Many works on multi-pathing exist [112, 136, 30, 31, 29, 137, 73, 52, 117, 138, 139, 140, 141, 142, 143, 144, 136, 145]. Our work differs from them all: it focuses on path diversity in low-diameter topologies and it uses both minimal and non-minimal paths.

Some works analyze various properties of low-diameter topologies, for example path length, throughput, and bandwidth [4, 67, 85, 10, 73, 146, 87, 147, 148, 149, 150, 151, 152, 153, 154, 155]. FatPaths offers the most extensive analysis on path diversity so far.

Some schemes complement FatPaths. For example, XPath [53] and source routing [54] deliver means to encode different paths. They could be used together with FatPaths by encoding the rich path diversity exposed by FatPaths. Finally, FatPaths could be used to accelerate communication-efficient workloads that benefit from low-diameter properties of Slim Fly and other modern topologies, including deep learning [156, 157, 158, 159, 160, 161], linear algebra computations [162, 163, 164, 165], graph processing [166, 167, 168, 169, 87, 170, 171, 172, 173, 174, 175], and other distributed workloads [176, 177, 7, 178, 179, 180] and algorithms [181, 182, 183, 184]. One could possibly use some elements of the FatPaths routing for the associated problems in the on-chip networking [185, 87].

X Conclusion

We introduce FatPaths: a simple, high-performance, and robust routing architecture for a modern family of low-diameter topologies. FatPaths enables such networks to achieve unprecedented performance by exposing the rich (“fat”) diversity of minimal and non-minimal paths. We formalize and extensively analyze this path diversity and show that, even though the considered topologies fall short of shortest paths, they can accommodate three “almost” minimal disjoint paths, which is enough to avoid congestion in many traffic scenarios. Our path diversity metrics and methodology can be used to analyze other properties of networks.

The key part of FatPaths, layered routing, enables harnessing diversity of both shortest and non-minimal paths. Supported with simple yet effective flowlet load balancing, and high-performance transport in TCP settings, FatPaths achieves low-latency and high-bandwidth, outperforming very recent fat tree architectures [1] by 15% in net throughput at 2$\times$ in latency, for comparable cost. Even though we focus on Ethernet, most of these schemes – for example adaptive flowlet load balancing and layers – are generic and they could enhance technologies such as RDMA (RoCE, iWARP) and Infiniband.

We deliver simulations with up to one million endpoints. Our code is online and can be used to foster novel research on next-generation large-scale compute centers.

FatPaths uses Ethernet for maximum versatility. We argue that it can accelerate both HPC clusters or supercomputers as well as data centers and other types of cloud infrastructure. FatPaths will help to bring the areas of HPC networks and cloud computing closer, fostering technology transfer and facilitating exchange of ideas.

**Acknowledgements: We thank Mark Klein, Hussein Harake, Colin McMurtrie, Angelo Mangili, and the whole CSCS team granting access to the Ault and Daint machines, and for their excellent technical support. We thank Timo Schneider for his immense help with computing infrastructure at SPCL. We thank Nils Blach, Alessandro Maisen, and Adam Latos for useful comments that helped improve the quality of the paper. **

APPENDIX

We now provide full discussions, analyses, and results omitted in the main paper body to maintain its clarity.

Appendix A Formal Description of Topologies

We first extend the discussion of the considered topologies. Table V provides details. Some selected networks are flexible (parameters determining their structure can have arbitrary values) while most are fixed (parameters must follow well-defined closed-form expressions). Next, networks can be group hierarchical (routers form groups connected with the same pattern of intra-group local cables and then groups are connected with global inter-group links), semi-hierarchical (there is some structure but no such groups), or flat (no distinctive hierarchical structure at all). Finally, topologies can be random (based on randomized constructions) or deterministic.

The motivation for picking such networks is as follows. Slim Fly (SF) [55] is a state-of-the-art cost-effective topology that optimizes its structure towards the Moore Bound [187]. It represents the recent family of diameter-2 networks. HyperX (Hamming graph) (HX) [56] generalizes, among others, hypercubes (HCs) [188] and Flattened Butterflies (FBF) [57]. We also consider Dragonfly (DF) [23], an established hierarchical network. Jellyfish (JF) [10] is a random regular graph with good expansion properties [188]. Xpander (XP) [4] resembles JF but has a deterministic construction variant. Fat tree (FT) [58], a widely used interconnect, is similar to the Clos network [59] with disjoint inputs and outputs and unidirectional links. FT stands for designs that are widely used and feature excellent performance properties such as full bisection bandwidth and non-blocking routing. We use three-stage FTs (FT3); fewer stages reduce scalability while more stages lead to high diameters. Finally, we also consider fully-connected graphs. They offer lower bounds on various metrics such as minimal path length, and can be used for validation.

Now, each topology uses certain input parameters that define the structure of this topology. These parameters are as follows: $q$ (SF), $a,h$ (DF), $\ell$ (XP), and $L,S,K$ (HX).

A-A Slim Fly

Slim Fly [55] is a modern cost-effective topology for large computing centers that uses mathematical optimization to minimize diameter $D$ for a given radix $k$ while maximizing size $N$. SF’s low diameter ($D=2$) ensures the lowest latency for many traffic patterns and it reduces the number of required network resources (packets traverse fewer routers and cables), lowering cost, static, and dynamic power consumption. SF is based on graphs approaching the Moore Bound (MB): The upper bound on the number of vertices in a graph with a given $D$ and $k^{\prime}$. This ensures full global bandwidth and high resilience to link failures due to good expansion properties. Next, SF is group hierarchical. A group is not necessarily complete but all the groups are connected to one another (with the same number of global links) and form a complete network of groups. We select SF as it is a state-of-the-art design that outperforms virtually all other targets in most metrics and represents topologies with $D=2$.

Associated Parameters $N_{r}$ and $k^{\prime}$ depend on a parameter $q$ that is a prime power with certain properties (detailed in the original work [55]). Some flexibility is ensured by allowing changes to $p$ and with a large number of suitable values of the parameter $q$. We use the suggested value of $p=\left\lceil{k^{\prime}}/{2}\right\rceil$.

A-B Dragonfly

Dragonfly [23] is a group hierarchical network with $D=3$ and a layout that reduces the number of global wires. Routers form complete groups; groups are connected to one another to form a complete network of groups with one link between any two groups. DF comes with an intuitive design and represents deployed networks with $D=3$.

Associated Parameters Input is: the group size $a$, the number of channels from one router to routers in other groups $h$, and concentration $p$. We use the maximum capacity DF (with the number of groups $g=ah+1$) that is balanced, i.e., the load on global links is balanced to avoid bottlenecks ($a=2p=2h$). In such a DF, a single parameter $p$ determines all others.

A-C Jellyfish

Jellyfish [10] networks are random regular graphs constructed by a simple greedy algorithm that adds randomly selected edges until no additions as possible. The resulting construction has good expansion properties [188]. Yet, all guarantees are probabilistic and rare degenerate cases, although unlikely, do exist. Even if $D$ can be arbitrarily high in degenerate cases, usually $D<4$ with much lower $d$. We select JF as it represents flexible topologies that use randomization and offer very good performance properties.

Associated Parameters JF is flexible. $N_{r}$ and $k^{\prime}$ can be arbitrary; we use parameters matching less flexible topologies. To compensate for the different amounts of hardware used in different topologies, we include a Jellyfish network constructed from the same routers for each topology; the performance differences observed between those networks are due to the different hardware and need to be factored in when comparing the deterministic topologies.

A-D Xpander

Xpander [4] networks resemble JF but have a deterministic variant. They are constructed by applying one or more so called $\ell$-lifts to a $k^{\prime}$-clique $G$. The $\ell$-lift of $G$ consists of $\ell$ copies of $G$, where for each edge $e$ in $G$, the copies of $e$ that connect vertices $s_{1},\dots,s_{\ell}$ to $t_{1},\dots,t_{\ell}$, are replaced with a random matching (can be derandomized): $s_{i}$ is connected to $t_{\pi(i)}$ for a random $\ell$-permutation $\pi$. This construction yields a $k^{\prime}$-regular graph with $N=\ell k^{\prime}$ and good expansion properties. The randomized $\ell$-lifts ensure good properties in the expectation. We select XP as it offers the advantages of JF in a deterministically constructed topology.

Associated Parameters We create XP with a single lift of arbitrary $\ell$. Such XP is flexible although there are more constraints than in JF. Thus, we cannot create matching instances for each topology. We select $k^{\prime}\in\{16,32\}$ and $\ell=k^{\prime}$, which is comparable to diameter-2 topologies. We also consider $\ell=2$ with multiple lifts as this ensures good properties [4], but we do not notice any additional speedup. We use $p=\frac{k^{\prime}}{2}$, matching the diameter-2 topologies.

A-E HyperX

HyperX [56] is formed by arranging vertices in an $L$-dimensional array and forming a clique along each 1-dimensional row. Several topologies are special cases of HX, including complete graphs, hypercubes (HCs) [188], and Flattened Butterflies (FBF) [57]. HX is a generic design that represents a wide range of networks.

Associated Parameters An HX is defined by a 4-tuple $(L,S,K,p)$. $L$ is the number of dimensions and $D=L$, $S$ and $K$ are $L$-dimensional vectors (they respectively denote the array size in each dimension and the relative capacity of links along each dimension). Networks with uniform $K$ and $S$ (for all dimensions) are called regular. We only use regular $(L,S,1,\cdot)$ networks with $L\in\{2,3\}$. HX with $L=2$ is about a factor of two away from the MB ($k^{\prime}\approx 2\sqrt{N_{r}}$) resulting in more edges than other topologies. Thus, we include higher-diameter variants with $k^{\prime}$ similar to that of other networks. Now, for full bisection bandwidth (BB), one should set $p=\frac{k^{\prime}}{2D}$. Yet, since HX already has the highest $k^{\prime}$ and $N_{r}$ (for a fixed $N$) among the considered topologies, we use a higher $p=\frac{k^{\prime}}{D}$ as with the other topologies to reduce the amount of used hardware. As we do not consider worst-case bisections, we still expect HX to perform well.

A-F Fat Tree

Fat tree [58] is based on the Clos network [59] with disjoint inputs and outputs and unidirectional links. By “folding” inputs with outputs, a multistage fat tree that connects any two ports with bidirectional links is constructed. We use three-stage FTs with $D=4$; fewer stages reduce scalability while more stages lead to high $D$. FT represents designs that are in widespread use and feature excellent performance properties such as full BB and non-blocking routing.

Associated Parameters A three-stage FT with full BB can be constructed from routers with uniform radix $k$: It connects ${k^{3}}/4$ endpoints using five groups of ${k^{2}}/4$ routers. Two of these groups, ${k^{2}}/2$ routers, form an edge group with ${k}/2$ endpoints. Another two groups form an aggregation layer: each of the edge groups forms a complete bipartite graph with one of the aggregation groups using the remaining ${k}/2$ ports, which are called upstream. Finally, the remaining group is called the core: each of the two aggregation groups forms a fully connected bipartite graph with the core, again using the remaining ${k}/2$ upstream ports. This also uses all $k$ ports of the core routers. Now, for FT, it is not always possible to construct a matching JF as $N/N_{r}$ can be fractional. In this case, we select $p$ and $k^{\prime}$ such that $k=p+k^{\prime}$ and ${k^{\prime}}/p\approx 4$, which potentially changes $N$. Note also that for FT, $p$ is the number of endpoints per edge router, while in the other topologies, all routers are edge routers.

A-G Fully-Connected Graphs

We also consider fully-connected graphs. They represent interesting corner-cases, offer lower bounds on various metrics such as minimal path length, and can be used for validation.

Associated Parameters A clique is defined by a single parameter $k^{\prime}$, leading to $N_{r}=k^{\prime}+1$. We use $p=k^{\prime}$ with the same rationale as for the HyperX topologies.

Appendix B Efficient Path Counting

Some measures for path diversity are computationally hard to derive for large graphs. Algorithms for all-pairs shortest paths analysis based on adjacency matrices are well known, and we reintroduce one such method here for the purpose of reproducibility. For the disjoint-paths analysis however, all-pairs algorithms exist, but are not commonly known. We introduce a method by Cheung et. al [105] and we adapt for length-limited edge connectivity computation.

B-A Matrix Multiplication for Path Counting

It is well known that for a graph represented as an adjacency matrix, matrix multiplication (MM) can be used to obtain information about paths in that graph. Variations of this include the Floyd-Warshall algorithm [189] for transitive closure and all-pairs shortest paths [190], which use different semirings to aggregate the respective quantities. To recapitulate how these algorithms work, consider standard MM using $\cdot$ and $+$ operators on non-negative integers, which computes the number of paths $n_{i}(s,t)$ between each pair of vertices.

Theorem 1**.**

If $A$ is the adjacency matrix of a directed graph $G=(V,E)$, $A_{i,j}=1$ iff $(i,j)\in E$ and $A_{i,j}=0$ iff $(i,j)\not\in E$, then each cell $i\in V,j\in V$ of $Q=A^{l}=\underbrace{A\cdot\ldots\cdot A}_{l\ \text{times}}$ contains the number of paths from $i$ to $j$ with exactly $l$ steps in $G$.

Proof.

By induction on the path length $l$: For $l=1$, $A^{l}=A$ and the adjacency matrix contains a $1$ in cell $i,j$ iff $(i,j)\in E$, else [math]. Since length-1 paths consist of exactly one edge, this satisfies the theorem. Now consider matrices $A^{p}$, $A^{q}$ for $p+q=l$ for which the theorem holds since $p,q<l$. We now prove the theorem also holds for $A^{l}=A^{p}\cdot A^{q}$. Matrix multiplication is defined as

[TABLE]

According to the theorem, $A^{p}_{i,k}$ is the number of length-$p$ paths from $i$ to some vertex $k$, and $A^{q}_{k,j}$ is the number of length-$q$ paths from said vertex $k$ to $j$. To reach $j$ from $i$ via $k$, we can choose any path from $i$ to $k$ and any from $k$ to $j$, giving $A^{p}_{i,k}\cdot A^{q}_{k,j}$ options. As we regard all paths from $i$ to $j$, we consider all intermediate vertices $k$ and count the total number (sum) of paths. This is exactly the count of length-$l$ paths demanded by the theorem, as each length-$l$ path can be uniquely split into a length-$p$ and a length-$q$ segment. ∎

In the proof we ignored a few details caused by the adjacency matrix representation: first, the adjacency matrix models a directed graph. We can also use the representation for undirected graphs by making sure $A$ is symmetrical (then also $A^{l}$ is symmetrical). Adjacency matrices contain the entry $A_{i,j}=0$ to indicate $(i,j)\notin E$ and $A_{i,j}=1$ for $(i,j)\in E$. By generalizing $A_{i,j}$ to be the number of length-1 paths ($=$ number of edges) from $i$ to $j$ as in the theorem, we can also represent multi-edges; the proof still holds.

Finally, the diagonal entries $A_{i,i}$ represent self-loops in the graph, which need to be explicitly modeled. Note that also $i=j$ is allowed above and the intermediate vertex $k$ can be equal to $i$ and/or $j$. Usually self-loops should be avoided by setting $A_{i,i}=0$. Then $A^{l}_{i,i}$ will be the number of cycles of length $l$ passing through $i$, and the paths counted in $A_{i,j}$ will include paths containing cycles. These cannot easily be avoided in this scheme555Setting $A^{l}_{i,i}=0$ before/after each step does not prevent cycles, since a path from $i$ to $k$ might pass $j$, causing a cycle, and we cannot tell this is the case without actually recording the path.. For most measures, e.g., shortest paths or disjoint paths, this is not a problem, since paths containing cycles will naturally never affect these metrics.

On general graphs, the algorithms outlined here are not attractive since it might take up to the maximum shortest path length $D$ iterations to reach a fixed point, however since we are interested in low-diameter graphs, they are practical and easier to reason about than the Floyd-Warshall aorithms.

B-A1 Matrix Multiplication for Routing Tables

As another example, we will later use a variation of this algorithm to compute next-hop tables that encode for each source $s$ and each destination $t$ which out-edge of $s$ should be used to reach $t$. In this algorithm, the matrix entries are sets of possible next hops. The initial adjacency matrix will contain for each edge in $G$ a set with the out edge index of this edge, otherwise empty sets. Instead of summing up path counts, we union the next-hop sets, and instead of multiplying with zero or one for each additional step, depending if there is an edge, we retain the set only if there is an edge for the next step. Since this procedure is not associative, it cannot be used to form longer paths from shorter segments, but it works as long as we always use the original adjacency matrix on the right side of the multiplication. The correctness proof is analogous to the path counting procedure.

B-B Counting Disjoint Paths

The problem of counting all-pairs disjoint paths per pair is equivalent to the all-pairs edge connectivity problem which is a special case of the all-pairs max flow problem for uniform edge capacities. It can be solved using a spanning tree (Gomory-Hu tree [106]) with minimum $s-t$-cut values for the respective partitions on the edges. The minimum $s-t$ cut for each pair is then the minimum edge weight on the path in this tree, which can be computed cheaply for all pairs. The construction of the tree requires $\mathcal{O}(N_{r})$ $s-t$-cuts, which cost $\mathcal{O}(N_{r}^{3})$ each (e.g., using the Push-Relabel scheme [191]).

Since we are more interested in the max flow values, rather than the min-cut partitions, a simplified approach can be used: while the Gomory-Hu tree has max flow values and min cut partitions equivalent to the original graph, a equivalent flow tree [107] only preserves the max flow values. While constructing it needs the same number of max-flow computations, these can be performed on the original input graph rather than the contracted graphs of Gomory-Hu, which makes the implementation much easier.

For length-restricted connectivity, common max-flow algorithms have to be adapted to respect the path length constraint. The Gomory-Hu approach does not work, since it is based on the principle that the distances in the original graph do not need to be respected. We implemented an algorithm based on the Ford-Fulkerson method [80], using BFS [192], which is not suitable for an all-pairs analysis, but can provide results for small sets of samples.

The spanning-tree based approaches only work for undirected graphs, and solve the more general max-flow problem. There are also algorithms that only solve the edge-connectivity problem, using completely different approaches. Cheung et. al [105] propose an algorithm based on linear algebra which can compute all-pairs connectivity in $\mathcal{O}(|E|^{\omega}+|V|^{2}k^{\prime\omega})$; $\omega\leq 3$ is the exponent for matrix-matrix multiplication. For our case of $k^{\prime}\approx\sqrt{N_{r}}$ and naive matrix inversion, this is $\mathcal{O}(N_{r}^{4.5})$ with massive space use, but there are many options to use sparse representations and iterative solvers, which might enable $\mathcal{O}(N_{r}^{3.5})$. Due to their construction, those algorithms also allow a limitation of maximum path length (with a corresponding complexity reduction) and the heavy computations are built on well-known primitives with low constant overhead and good parallel scaling, compared to classical graph schemes.

B-C Deriving Edge Connectivity

This scheme is based on the ideas of Cheung et. al. [105]. First, we adapt the algorithm for vertex connectivity, which allows lower space- and time complexity than the original algorithm and simplifies its design. The original edge-connectivity algorithm is obtained by applying it to a transformed graph.666Vertex-connectivity, defined as the minimum size of a cut set $c_{st}\subset V\setminus\{s,t\}$ of vertices that have to be removed to make $s$ and $t$ disconnected, is not well defined for neighbors in the graph. The edge-connectivity algorithm avoids this problem, but this cannot be generalized for vertex-connectivity.

We then introduce the path-length constraint by replacing the exact solution obtained by matrix inversion with an approximated one based on iterations, which correspond to incrementally adding steps. The algorithm is randomized in the same way as the original is; we ignore the probability analysis for now, as the randomization is only required to avoid degenerate matrices in the process and allow the use of a finite domain. The domain $\mathbb{F}$ is defined to be a finite field of sufficient size to make the analysis work and allow a real-world implementation; we can assume $\mathbb{F}=\mathbb{R^{+}}$.

First, we consider a connection matrix, which is just the adjacency matrix with random coefficients for the edges:

[TABLE]

In the edge-connectivity algorithm we use a much larger adjacency matrix of a transformed graph here (empty rows and columns could be dropped, leaving an $|E|\times|E|$ matrix, but our implementation does not do this since the empty rows and columns are free in a sparse matrix representation):

[TABLE]

Now, we assign a vector $F_{i}\in\mathbb{F}^{k}$, where $k$ is the maximum vertex degree, to each vertex $i$ and consider the system of equations defined by the graph: the value of each vertex shall be the linear combination of its neighbors weighted by the edge coefficients in $K$. To force a non-trivial solution, we designate a source vertex $s$ and add pairwise orthogonal vectors to each of its neighbors. For simplicity we use unit vectors in the respective columns of a $k\times|V|$ matrix $P_{s}$ (same shape as $F$). So, we get the condition

[TABLE]

This can be solved as

[TABLE]

The work-intensive part is inverting $(\mathbb{I}-K)$, which can be done explicitly and independently from $s$, to get a computationally inexpensive all-pairs solution, or implicitly only for the vectors in $P_{s}$ for a computationally inexpensive single-source solution. To compute connectivity, we use the following theorem. The scheme outlined in the following proof counts vertex-disjoint paths of any length.

Theorem 2**.**

The size of the vertex cut set $c_{st}$ from $s$ to $t$ equals $\operatorname{rank}(FQ_{t})$, where $F=-P_{s}(\mathbb{I}-K)^{-1}$ and $Q_{t}$ is a $|V|\times k$ permutation matrix selecting $t$’s incoming neighbors.

Proof.

First, $c_{st}\leq\operatorname{rank}(FQ_{t})$, because all non-zero vectors were injected around $s$ and all vectors propagated through the cut set of $c_{st}$ vertices to $t$, so there cannot be more than $c_{st}$ linearly independent vectors near $t$. Second, $c_{st}\geq\operatorname{rank}(FQ_{t})$, because there are $c_{st}$ vertex-disjoint paths from $s$ to $t$. Each passes through one of the $c_{st}$ outgoing neighbors of $s$, which has one of the linearly independent vectors of $P_{s}$ assigned (combined with potentially other components). As there is a path from $s$ to $t$ trough this vertex, on each edge of this path the component of $P_{s}$ will be propagated to the next vertex, multiplied by the respective coefficient in $K$. So, at $t$ each of the paths will contribute one orthogonal component. ∎

To count length-limited paths instead, we simply use an iterative approximation of the fixed point instead of the explicit solution. Since we are only interested in the ranks of sub-matrices, it is also not necessary to actually find a precise solution; rather, following the argument of the proof above, we want to follow the propagation of linearly independent components through the network. The first approach is simply iterating Equation 13 from some initial guess. For this guess we use zero vectors, due to $P_{s}$ in there we still get nontrivial solutions but we can be certain to not introduce additional linearly dependent vectors:

[TABLE]

This iteration still depends on a specific source vertex $s$. For an all-pairs solution, we can iterate for all source vertices in parallel by using more dimensions in the vectors; we set $k=|V|$. Now we can assign every vertex a pairwise orthogonal start vector, e.g., by factoring out $P_{s}$ and selecting rows by multiplying with $P_{s}$ in the end. The intermediate products are now $|V|\times|V|$ matrices, and we add the identity matrix after each step. Putting all together gives

[TABLE]

The total complexity includes the $\mathcal{O}\left(|V|^{3}l\right)$ operations to precompute the matrix for a maximum path length of $l$ and $\mathcal{O}\left(|V|^{2}k^{3}\right)$ operations for the $\operatorname{rank}$ operations for all vertex pairs in the end, which will be the leading term for the $k=\mathcal{O}\left((\sqrt{|V|}\right)$ (diameter 2) undirected graphs considered here, for a total of $\mathcal{O}\left(|V|^{3.5}\right)$.

For the edge connectivity version, we use the edge incidence connection matrix $K^{\prime}$, and select rows and columns based on edge incidence, instead of vertex adjacency. Apart from that, the algorithm stays identical, but the measured cut set will now be a cut set of edges, yielding edge connectivity values. However, the algorithm is more expensive in terms of space use and running time: $\mathcal{O}\left(|E|^{3}l\right)$ to precompute the propagation matrix.

Appendix C Details of Layered Routing

We extend the description of FatPaths’ layered routing.

C-A Deriving Forwarding Entries

An example scheme for deriving and populating forwarding tables is illustrated in Listing LABEL:lst:layersEntries.

C-B Details of SPAIN Comparison Baseline

In FatPaths, we include SPAIN as a comparison baseline when generating FatPaths routing layers, see Listing LABEL:lst:layersSpain. The implementation of SPAIN consists of two main stages: pre-computation of paths exploiting redundancy in a given network topology and mapping the path sets to VLANs. The time complexity of path computation and path layout algorithm is together $O(|V|^{2}(|V|+|E|))$.

The first stage of the algorithm is based upon a per-destination VLAN computation algorithm. At first, for every destination node, all paths connecting it with other nodes are computed. A good path set should meet two basic requirements – it should exploit the available topological redundancy and simultaneously contain as few paths as possible. The algorithm for path computation greedily searches for $k\in\mathbb{N}$ shortest paths between pairs of nodes, giving the preference to link-disjoint paths over alternative paths, which could be possibly shorter but share links with at least one already selected path. However, even though link-disjoint paths have the advantage as a single link failure does not take down multiple paths, in some circumstances it may be beneficial to consider a shorter path which is not necessarily fully disjoint path but shorter [52]. The paths are computed to be pairwise disjoint only for a certain destination node.

The next step in the per-destination VLAN computation algorithm uses graph coloring techniques to assign the least possible number of VLANs to path sets for a destination node. Afterwards, in order to minimize the number of VLANs, they are being merged together using a greedy algorithm, as any two generated subgraphs for different destinations can be combined into a single graph, if and only if the resulting graph will not contain any loops. The input of the algorithm is the set containing all computed subgraphs. For each graph, the algorithm tries to merge it with as many other graphs as possible (checking them in a randomized order), using a breadth-first search on every combined graph to check whether it is acyclic or not. Unfortunately, the current design of SPAIN lacks the flexibility to define an arbitrary number of layers. Moreover, the greedy merging algorithm may result in creating layers, that will be unbalanced in terms of size (number of edges per each graph).

C-C Details of PAST Comparison Baseline

We consider PAST [41] for completeness as it does not support (by default) multi-pathing between endpoint pairs for more performance. Specifically, PAST uses per-address spanning trees to forward the traffic to any endpoint in the network. Any given switch uses only one path for forwarding the traffic to the given endpoint. It provides various approaches to define the spanning trees, aiming at distributing the trees uniformly across available physical links (i.e., using breadth-first search with random tie-breaking for paths finding or implementing a non-minimal variant, inspired by the Valiant load balancing). A simple specification of generating routing layers in FatPaths when using PAST can be found in Listing LABEL:lst:layersPast.

Specifically, in contrast to SPAIN, which searches for link-disjoint paths to a given destination node, PAST creates spanning trees for every address in the network using one of three possible approaches: standard breadth-first search algorithm, with the destination node being the root of the tree, breadth-first search with random tie-breaking and breadth-first search, which weights its random selection by considering how many endpoints each switch has as children, summed across all trees built so far. The complexity of the bread-first search, which affects directly the complexity of PAST layers creation algorithm, may be expressed as $O(|V|+|E|)$.

Additionally a non-minimal, inspired by Valiant load balancing, variant of PAST was designed. In this approach, before computing the spanning tree, the algorithm selects randomly a switch, which plays the role of the root of spanning tree, instead of the destination endpoint.

C-D Details of $k$-Shortest Paths Comparison Baseline

$k$-shortest paths [10] spreads traffic over multiple shortest paths (if available) between endpoints. For the purpose of evaluation we used Yen’s algorithm with Dijkstra’s algorithm to derive the $k$ shortest loop-free paths. As the complexity of Dijkstra’s algorithm may be expressed as $O(|E|+|V|\log|V|)$, the complexity of computing $k$ paths between a pair of endpoints using Yen’s algorithm is equal to $O(k|V|(|E|+|V|\log|V|))$.

Appendix D Details of Evaluation Setup

We also provide details of the evaluation setup.

D-1 Topology Parameters

We now extend the discussion on the selection of key topology parameters (full details and formal descriptions are in the Appendix). We select $N_{r}$ and $k^{\prime}$ so that considered topologies use similar amounts of hardware. To analyze these amounts, we analyze the edge density: a ratio between the number of all the cables $\frac{1}{2}N_{r}k^{\prime}+N_{r}p$ and endpoints $N=N_{r}p$. It turns out to be (asymptotically) constant for all topologies (the left plot in Figure 19) and related to $D$. Next, higher-diameter networks such as DF require more cables. As explained in past work [55]: Packets traverse more cables on the way to their destination. We also illustrate $k$ as a function of $N$ (the right plot in Figure 19). An interesting outlier is FT. It scales with $k$ similarly to networks with $D=2$, but with a much lower constant factor, at the cost of a higher $D$ and thus more routers and cables. This implies that FT is most attractive for small networks using routers with constrained $k$. We can also observe the unique SF properties: For a fixed (low) number of cables, the required $k$ is lower by a constant factor (than in, e.g., HX), resulting in better $N$ scaling.

D-2 Baselines for Performance Validation

Our evaluation is influenced by a plethora of parameters and effects, many of which are not necessarily related to the core paper domain. Some of them may be related to the incorporated protocols (e.g., TCP), others to the used traffic patterns. Thus, we also establish baseline comparison targets and we fix various parameters to ensure fair comparisons. To characterize TCP effects, one baseline is a star (ST) topology that contains a single crossbar switch and attached endpoints. It should not exhibit any behavior that depends on the topology structure as it does not contain any inter-switch links. We use the same flow distribution and traffic pattern as in the large-scale simulation, as well as the same transport protocols. This serves as an upper bound on performance. Compared to measurements, we observe the lowest realistic latency and the maximum achievable link throughput, as well as flow control effects that we did not explicitly model, such as TCP slow start. There is no additional congestion compared to measured data since we use randomized workloads. Second, as a lower bound on routing performance, we show results for flow-based ECMP as an example of a non-adaptive routing scheme, and LetFlow as an example of an adaptive routing scheme. We also include results of unmodified NDP (with oblivious load balancing) on FTs.

D-A Behavior of Flows in OMNet++

First, we use Figure 20 to illustrate the behavior of long flows (2MB) in the pFabric web search distribution in response to the flow arrival rate $\lambda$ (flows per endpoint per second) on a 60-endpoint crossbar (tail limited to 90% due to the low sample size). The left plot shows how the per-flow throughput decreases beyond $\lambda=250$, which is a sign of network saturation; the right figure shows three samples of completion time distributions for low, moderate, and high loads.

D-B Behavior of Flows in htsim

In htsim simulations, on the star network as well as the baseline $2x$-oversubscribed fat tree, we observe better performance compared to the OMNet++ TCP simulations. This leads to a lower network load, which would be misleading in topology comparisons. Therefore, we use $\lambda=300$, where the system starts to show congestion at the network level. At lower $\lambda$, we only observe endpoint congestion (crossbar (Star) results equal fat tree results), while at higher $\lambda$, the FCTs increase beyond the $2\times$ expected from the oversubscription: the lower service rate leads to more concurrent flows, decreasing the throughput per flow (see Figure 21).

D-C Selection of TCP Parameters

TCP retransmissions on packet loss are controlled by two separate timeouts: one for the initial SYN and SYNACK handshake packets, and one that is used during the flow. Both are guarded by an upper and lower limit. For the handshake timeout, the lower limit is used in the beginning, increasing it up to the upper limit on retries. For the normal limit, it is adapted in response to the measured RTT but limited by the bounds, initially starting from a high value.

Since we usually do not see lost SYN packets, we did not optimize the handshake timeouts. Most of the time, they simply have no effect at all. We did optimize the normal retransmission timeouts, and observed that limiting the lower bound can decrease performance at high load, while the upper bound does not have much impact (again, this is because it is unlikely that a packet is lost before an RTT estimate is produced, so this parameter is not used at all). The value of 200$\mu$s for the RTO lower bound is fairly high and can lead to performance degradation, but it also models a limited timer granularity on the endpoints, which makes low timeouts unrealistic. In the usual workload model considered in this work, packet loss rates are low enough that the RTO does not have any measurable impact, as long as the timeouts are not very high (with the INET default value of 1s, a single flow experiencing a RTO can influence the mean significantly). The TCP retransmission parameters become more relevant if very sparse, and therefore incomplete, layers are used, where packets are lost not only due to congestion but also due to being non-routable. However, in this case we use feedback via ICMP to trigger an immediate retransmission on a different layer, therefore the RTO limits also have no siificant impact in this scenario.