背景

如今，隨著分解式存儲和微服務架構的日益流行，在現代數據中心，高扇出和扇入的遠程過程調用(RPC)產生了大部分的流量，據統計，在谷歌的數據中心網絡中，超過95%的流量均由RPC產生。而RPC性能的好壞是應用性能的好壞的一個重要指標，因此，研究什么會影響RPC的性能至關重要。RPC在大多數情況下性能良好，但是，在網絡負荷超載的情況下，網絡負載可能是平常的8倍以上，RPC的時延是造成網絡時延峰值的主要原因。在這時，網絡的需求量大于容量，所以需要對重要的RPC提供網絡時延SLO保證。RPC被分為3類：對時延敏感的性能重要RPC（Performance-critical，PC）、對吞吐敏感的非重要RPC（Non-critical，NC）和沒有SLO要求的盡最大努力交付RPC（Best-effort，BE）。 ?

相關工作

先前的工作中有基于優先級調度的方法?；诖笮〉膬炏燃壵{度，如最小工作優先（Smallest Job First，SJF）和最小剩余時間優先（Smallest Remaining Time First，SRTF）可以減小平均RPC時延，但是RPC的大小不等同于RPC的優先級且這個方法在實際中很難實施。第二種是對RPC使用嚴格的優先級隊列（Strict Priority Queue，SPQ），這種方法可以提供直接的優先級映射，但同時也會讓每個人都傾向使用最高的優先級，且存在饑餓的問題。另一個方法，就是使用加權公平隊列（Weighted-Fair Queuing，WFQ），很多包括谷歌在內的云服務提供商，使用的也是這種方法。這種方法有兩個有點：第一，RPC的優先級可以直接對應到WFQ的QoS隊列上；第二，WFQ已實際部署在商用交換機上了，使得大規模地部署很簡單。但這方法也存在兩種問題：第一，QoS的類別和SLO并不相關；第二，應用層面上的優先級映射太粗粒度，其體現在PRC優先級和QoS級別的不一致。為了解決WFQ的兩個問題，本文作者設計了Aequitas。 ?

設計

Aequitas的設計目標，是為了解決上述提到的WFQ的兩個問題，具體做法是將優先級映射從粗粒度調整到細粒度；管理不同QoS級別間的流量分布（QoS-mix），為重要的RPC提供有保障的SLO。流程如下圖所示。 ? ? 第一， 將優先級與WFS 的QoS在RPC的粒度上對應。具體來說，對每個應用的每個RPC設定優先級，并按照PC,NC,BE到高、中、低，依次進行映射。 ? ? 第二， 通過允許控制來直接控制QoS-mix。如下圖所示，Aequitas通過概率允許控制機制，對所有的QoS進行調整：保持原來的QoS來傳輸或降到最低級，若發生了QoS降級，則會告知應用修改其不同等級QoS的分布。這樣就能得到最終的QoS-mix。 Aequitas的概率允許機制是一個分布式的算法，概率的調整方式為加法增加和乘法減?。ˋdditive Increase Multiplicative Decrease, AIMD）。具體來說，在各終端主機上，對每個（源地址，目的地址，要求QoS）這樣的元組，維持著一個允許概，測量并收集網絡中RPC的時延（RPC Network Latency，RNL）。如果RNL小于目標SLO，則將允許概率加上增加窗口的大；反之，則乘法減小允許概率。 ?

實驗評估

本文的評估實驗包括模擬、測試集實驗和實際生產應用的結果。重點在兩個方面，首先是通過控制99%或99.9%的RNL，測試Aequitas是否仍然符合正確性；其次是在不論流量如何分布的情況下，Aequitas是否提供接近理想的流量。 ? 從下圖實驗結果可以看出，不論高優先級的流量占比多少，Aequitas都能提供較好的SLO保證（藍色線為Aequitas結果，黃色線為SLO目標，二者很接近）。與其他調度算法，如SPQ相比，Aequitas效果顯著（紅色線為SPQ算法的調度結果，其與SLO相差甚遠）。由此可見，Aequitas可以在網絡過載情況下，保證SLO。 ?

個人觀點

在網絡過載的情況下，要求高QoS的RPC數據量遠超網絡的傳輸能力，在這時就要在時延和服務質量之間做出取舍。在這篇論文中，Aequitas通過犧牲尾時延來獲取更低的99%（99.9%）時延，即犧牲一小部分來獲取整體性能的提升。 ?

Time-division TCP for reconfigurable data center networks

Shawn Shuoshuo Chen (Carnegie Mellon University), Weiyang Wang (MIT), Christopher Canel (Carnegie Mellon University), Srinivasan Seshan (Carnegie Mellon University), Alex C. Snoeren (UC San Diego), Peter Steenkiste (Carnegie Mellon University)

? 本篇文章由卡內基梅隆大學、麻省理工學院以及加州大學圣地亞哥分校的研究者合作完成。本論文提出了時分TCP（TDTCP），這是專門為可重構網絡設計的TCP新變體，旨在充分利用RDCN提供的額外容量。 ?

背景

大多數數據中心網絡大多基于Clos拓撲，并提供單個全平分網絡的“big switch”抽象，以應對通過高帶寬、低延遲結構連接大量終端主機的挑戰。但隨著主機數量的增加以及摩爾定律的放緩，這種方法達到極限。為了應對寬帶供需差距的不斷擴大，一些研究者提出了基于optical circuit switch的可重構數據中心網絡。該方法可以動態分配可用的網絡資源，成本更低，擴展性更好。但由于TCP的擁塞控制不適用于延遲和帶寬劇烈變化的網絡，現有的TCP變體無法充分利用RDCN提供的額外容量。為了充分利用RDCN提供的額外容量，該論文提出了時分TCP (TDTCP)，這是專門為可重構網絡設計的TCP新變體。作者的靈感來自于以下發現—“只要網絡在不同的配置之間清晰移動，就足以在每個配置中分別有效地運行”。具體來說，完整的算法是單個模型的分段函數，TDTCP隨著時間的推移復用獨立的網絡狀態，隨著網絡從一種配置轉移到另一種配置，發送者在網絡模型之間切換。 ?

設計

(1) TDN 變化通知 ? RDCN的光學配置時間大約為幾個RTT，主機幾乎沒有時間對新的網絡環境做出反應。作者利用終端主機連接的ToR交換機直接參與重新配置網絡結構來解決這一個挑戰。具體來說，作者讓ToR交換機在路徑發生變化時直接通知其連接的主機。該信令使得終端主機能夠將可重構網絡視為一系列周期性變化的時分網絡 (TDN) 。具體來說，作者使用ICMP數據包來攜帶該通知，ICMP數據包僅使用一個整數索引，指示當前活動的網絡路徑。因為ToR交換機和終端主機處于同一機架內，通知延遲可以保持在較低的水平。 ? (2) 序列空間與包重排序 ? 當網絡重新配置時，傳輸中的數據包可能屬于多個時分網絡 (TDN)。例如，數據包可能會穿越與其ACK不同的TDN，或者延遲的減少可能會重新排序數據包。TDTCN需要區分瞬態重新排序與真正的丟失，防止不必要的重新傳輸，提高傳輸效率。為了應對這一挑戰，TDTCP跟蹤與每個TDN關聯的序列空間，并使用啟發式和選擇性確認來避免TDN轉換期間的嚴重性能損失。具體來說，TDTCP采用單個連接級序列號空間，而不是使用MPTCP的子流兩級設計。使用這一設計有三個原因。首先是為了避免TDN切換后流量控制停止；其次是為了消除子流之間協調的需要，減少不必要的性能開銷；與此同時，該設計可以減少接受端的額外大量處理。 ? 在TCP采用單個連續級序列號空間的基礎上，讓我們看一下作者如何解決包重排序問題。 ? 傳統的TDP Reno快速重傳啟發式算法RDCN網絡。具體來說，在RDCN網絡中，大多數重新排序是跨TDN重新排序，數據包以及相應的ACK會以不同的延遲遍歷TDN，跨TDN重新排序不會表示丟失；由于增加的路徑延遲，ACK被簡單地延遲，如果TDTCP遵循TCP Reno快速重傳啟發式算法，它將在每次TDN轉換時虛假地重傳大量數據包。 ? 為了避免頻繁的虛假重傳，TDTCP在per-TDN狀態和SACK支持的幫助下放松了三重dupACK啟發式。下圖說明了TDTCP的寬松重排序檢測啟發式算法。當通過 TDN 1 發送的（粉紅色）段在來自 TDN 0 的未完成（藍色）段之前得到確認時，SACK 標記成功確認的段并調用快速恢復。snduna 指針和最高 SACKed 序列號（虛線矩形）之間的所有段都可能丟失，并且可能需要重新傳輸。但是，TDTCP 會檢查這些數據包的相關 TDN ID，并將它們與 TDN 更改指針進行比較。來自 TDN 0 的（藍色虛線）段被忽略，因為它們屬于不同的 TDN，并且它們的 ACK 很可能只是延遲了。只有屬于 TDN 1 的一個（粉紅色虛線）段被確認為真正的丟失，將被重傳。TDN 0 保持打開狀態，允許繼續全速發送；另一方面，TDN 1 由于丟失而進入恢復狀態。 (3)實現與限制 ? 在現代操作系統內核中實現TDTCP具有挑戰性，因為擁塞控制狀態緊密集成到網絡堆棧中。論文研究者確定了必須跨TDN復制的CUBIC擁塞控制狀態子集，并優化了TDN切換過程，以確保及時通知終端主機網絡轉換。TDCN的主要限制是它的運行機制。TDTCP僅在網絡條件以一定的頻率變化時才有用。TDTCP最適合在TDN變化周期在1-100x路徑RTT的網絡中運行。 ?

實驗評估

作者針對內核中現有的TCP 變體以及 MPTCP 和 reTCP評估 TDTCP 的性能。實驗結果表明，長壽命流在 TDTCP 下實現了更好的吞吐量：在一種代表性的 RDCN 設置中比單路徑 CUBIC 和 DCTCP 高 24%，比 MPTCP 高 41%。此外，TDTCP 與 reTCP 的吞吐量性能相匹配，同時表現出較低的交換機緩沖區占用率，并且不依賴于主動交換機緩沖區管理。 ?

總結

TDTCP 是一種新的 TCP 變體，旨在有效利用最新 RDCN 提供的額外容量。TDTCP 使用 TCP 狀態變量的獨立副本監控不同時分網絡的路徑特征，利用交換機生成的路徑更改通知快速收斂到最佳擁塞狀態，并放寬 TCP 的快速恢復啟發式算法以避免在網絡條件下出現虛假重傳改變。作者在 Linux 內核 5.8 中實現了 TDTCP，并在小規模（模擬）RDCN 測試平臺上評估了它的性能。結果表明，對于長壽命流，TDTCP 顯著降低了網絡中的隊列占用率，并且優于傳統的單路徑 TCP 變體，例如 CUBIC 和 DCTCP。TDTCP 可與 reTCP 競爭，但不需要交換機像 reTCP 那樣動態調整緩沖區大小。 ?

個人觀點

個人認為，本論文比較有意思的點是“packet reordering”部分的描寫。首先舉例說明為什么傳統的快速重傳算法不適用于TDTCP，然后在快速重傳算法的基礎之上，設計了寬松的檢測啟發式算法，并且舉了個例子說明算法是如何運行的。這一部分從描寫敘述到舉例說明再到算法的設計都是比較精彩的。 ?

背景與問題

網絡設備配備了一個緩沖區，以避免在瞬時擁塞期間下降，并吸收突發流量。為了降低成本和最大化利用率，on-chip緩沖區在其隊列之間被共享。這種共享自然會導致各種問題。具體地說，一個隊列的過度增長可能會損害另一個隊列的性能，這可能會缺乏、剝奪吞吐量等。更糟糕的是，這種有害的干擾可能發生在看似獨立的隊列之間，例如，映射到不同端口的隊列或由獨立的應用程序形成的隊列。 ? 網絡設備通常采用分層的分組接納控制來協調共享空間的使用。首先，緩沖區管理(BM)算法動態分割緩沖區空間。第二，主動隊列管理(AQM)算法通過選擇性地允許傳入的數據包來管理BM分配給每個單獨隊列的緩沖區片。BM旨在通過管理設備級別上的緩沖區的空間分配來實現跨隊列的隔離。直觀地說，BM的目標是避免長時間的隊列饑餓，有效地在穩定狀態下加強公平。相反，AQM的目標是通過管理隊列級別上的緩沖區的時間分配來保持穩定的排隊延遲。直觀地說，AQM通過避免數據包在緩沖區中停留“太久”的來防止緩沖區膨脹。 ? 雖然BM和AQM在過去是合理和成功的，因為它允許BM和AQM方案進一步發展，但最近的兩個數據中心趨勢使它們之間的協調變得緊迫。首先，緩沖區的大小沒有跟上交換機容量的增加。實際上，BM不再有足夠的可用緩沖區來為每個隊列提供隔離。其次，隨著流量變得更加突發的場景更加普遍，緩沖區的瞬態需要控制在設備級。為了跟上這些趨勢，緩沖區共享方案需要提供隔離、有界排空時間和高突發容差。但是今天的BM和AQM方案根本不能獨立地滿足這些要求。在這一見解的驅動下，作者提出了ABM，一種主動緩沖區管理算法，它結合了來自BM和AQM的見解，以在不犧牲吞吐量的情況下實現高突發流量吸收。 ? 本文的做法旨在建模，綜合考慮了多種因素來為每個隊列分配一定長度的緩沖區空間和時間方面的問題。 ?

動機

優秀的緩沖區管理方案屬性: ? 為了最大限度地提高共享緩沖區的利用率，緩沖區共享方案需要滿足三個關鍵屬性：(1) isolation; (2) bounded drain time; and (3) predictable burst tolerance。 ? （1）Isolation ? 由于緩沖區是跨多個隊列共享的，因此一小組隊列過度使用緩沖區可能會干擾交換機中的其他隊列使用共享緩沖區的能力。如果相互競爭的隊列屬于不同的流量優先級，那么這種干擾可能特別有害。我們要求每個優先級必須在任何給定時間占用可配置的最小緩沖區數量，獨立于緩沖區狀態。形式上，讓Tp(t)表示在任何時間t中所有優先級P的集合中分配給優先級p（P中元素）的總緩沖區。然后，Bp(min)必須始終大于可配置的靜態值。但是，由于總緩沖空間有限，所以總分配必須在總緩沖區內。因此，每個優先級也必須是其分配的上限Bp(max)，以防止獨占緩沖區。 ?

??（2）Bounded drain time ? 緩沖區有限的排空時間減少了緩沖區內的數據包（或流量）的排隊延遲。為了避免高排隊延遲的有害后果，緩沖區共享方案需要綁定每個隊列的排空時間。具體地說，緩沖區共享方案需要通過一個可配置的靜態值q(t)來綁定具有服務速率u(t)的隊列中被占用的緩沖區A。實際上下面的條件總結了緩沖區膨脹問題：所需的屬性是為了避免數據包在緩沖區中停留“太長時間”。??

Bounded drain time: q(t)/u(t)<=A

? （3）Predictable burst tolerance ? 如果預留大量的緩存空間以應對突發的數據包或者等突發數據包到來時直接占用現有的緩存區，雖然足以應對突發事件，但這可能會產生不利影響。一方面，始終保持突發大小的空緩沖區數量會剝奪隊列中寶貴的緩沖區，從而導致潛在的吞吐量損失。另一方面，將所有新釋放的緩沖區（從引流隊列）分配給傳入突發將耗盡引流隊列（刪除每個傳入數據包）?？傊峁┛深A測的突發容忍性避免緩沖浪費，緩沖共享方案需要結合考慮隔離和限制排空時間。 ? 最先進方法動態閾值存在的不足: ? 典型的設備使用分層的數據包進入控制方案：首先，一個緩沖區管理(BM)方案決定在設備級別上每個隊列的最大長度，然后一個活動隊列管理(AQM)方案決定哪些數據包緩沖在隊列中。不幸的是，兩種控制方案之間缺乏合作導致(i)由于缺乏隔離而造成的跨隊列的有害干擾；(ii)由于忽略了每個排隊的排空時間，增加了排隊延遲；(iii)不可預測的突發流量的容忍性。當今數據中心交換機中使用的最先進的緩沖區管理算法動態閾值(DT)根本無法實現上面描述的理想屬性，而且也具備上述缺陷。 ?

設計

ABM同時滿足了隔離、排空時間和可預測的突發流量的容忍三個屬性。在論文附錄A有完整的證明。 ? ABM算法: ABM為每個隊列分配閾值，同時考慮空間的、緩沖區范圍的和時間范圍的、每個隊列的統計信息。Tpi(t)：在端口上的優先級為p的隊列i的閾值。 ?

Tpi(t)=a(p) x 1/n(p) x (B-Q(t)) x U(pi)/b

? a(p)是操作員需要在ABM中配置的唯一參數。其值越高，平均分配值就越高。它定義了每個優先級可用的最小和最大緩沖區。 ? n(p)表示優先級p的擁塞隊列數。如果隊列長度接近相應的閾值，則ABM考慮隊列擁塞。在本文的評估中，如果一個隊列的長度大于或等于其閾值的0.9，我們就認為它是擁塞的。 ? U(pi)/b表示標準化排空率，其中U(pi)為隊列的排空率，b為每個端口的帶寬。 ? (B-Q(t))表示剩余的緩沖區空間。 ?

BM: a(p) x 1/n(p) x (B-Q(t)) AQM：U(pi)/b

? ABM具備實踐性:

（1）ABM使用了當今交換機可用的統計數據。 （2）ABM講述了關于如何配置α的基本經驗。 （3）DT已經部署于數據中心，而ABM可在DT之上近似地使用。 ?

性能評估

本文的評估是基于網絡模擬器NS3，將ABM與數據中心設置中的最先進的方法DT動態閾值進行了比較。作者做了大規模模擬結果表明，與現有的BM和AQM方案相比，ABM將短流量的流量完成時間提高了高達94。此外，ABM不僅兼容先進的擁塞控制算法(如及時、DCTCP和PowerTCP)，而且在繁重的工作負載下，它們的尾部fct的性能提高了高達76。最后，作者證明了與傳統的緩沖區管理方案不同，ABM在不同大小的緩沖區大小上工作良好，包括淺緩沖區。 ?

總結

問題場景: 今天的網絡設備跨隊列共享緩沖區，以避免在瞬時擁塞期間下降，并吸收突發。隨著數據中心中緩沖區帶寬單元的減少，對最佳緩沖區利用率的需求變得更加迫切。 ? ABM核心觀點: 它結合了來自BM和AQM的見解。具體地說，ABM利用了設備級別的總緩沖區占用率和單個隊列的占用時間。本質上，ABM是緩沖區的空間(BM使用)和時間(AQM使用)特征的函數。ABM同時考慮了總緩沖區占用率(通常由BM使用)和隊列排空時間(通常由AQM使用)。 ? 性能結果: 作者分析證明了ABM提供隔離、有界緩沖排空時間，并在不犧牲吞吐量的情況下實現可預測的突發流量吸收。

個人觀點

研究依據明確和方法創新 ? 論文作者觀察到當今數據中心的網絡帶寬與內存buffer問題，并且關注了現代數據中心的流量特征，例如突發流量。以此展開研究動態閾值方法的限制性，再通過數學建模提出自己的創新方法。這種研究路線在許多數據中心相關研究中大多有所體現。首次把緩存和活動隊列統一于一個建模公式中，一個框架內，提出新方法。 ? ABM的實踐性理由不能令人信服 ? 文中提及了它具備實踐性的理由，首先，模擬和使用特定的數據不會具備普適性。而且，在測試的情況下，本文所提議的解決方案也沒有使用當前的硬件進行部署，例如FPGA實現或ASIC。盡管ABM可以近似實現動態閾值的方法，但是沒有實際部署，沒有使用現在的硬件，那成本便難以確定。 ?

背景

過去十年，數據中心網絡的傳輸層設計有兩個目標：短流低延遲，長流高吞吐量。這方面的進展有：DCTCP、D3、PDQ、D2TCP、HULL、Timely、pHost、NDP、Homa、HPCC、Swift等，這些方法解決了短流接近最優的延遲。但是，如何同時實現短流的低延遲和長流的高網絡利用率，這個問題仍然十分挑戰，這主要由于：1. 長流可能和短流競爭；2. 長流可能和網絡中的其他長流競爭；3. 長流可能和主機中其他長流競爭。 ?

設計

作者觀察到現代數據中心和switch fabrics在拓撲、工作負載上的相似性，提出應用交換機上的PIM算法到數據中心，叫做dcPIM。dcPIM是一種基于匹配的設計，即每個發送端和唯一一個接收端配對。PIM用多輪控制信息來計算免沖突的輸入端口和輸出端口之間的配對，每一輪都包括三個階段：request stage，grant stage和accept stage。在每一輪開始，每個沒有匹配的輸入端口給其有輸出數據的端口發動一個request（request stage）；然后，每個沒有匹配的輸出端口從接收到的request中隨機選擇一個，發送grant信息（grant stage）；最后，沒有匹配的輸入端口從接收到的grants中隨機選擇一個，發送accept信息，接收到accept信息的輸出端口和相應的輸入端口實現了配對。直接應用PIM到數據中心有3個挑戰：高延遲、低帶寬利用率和異常處理機制。 ? dcPIM和PIM類似，包括兩個階段：匹配階段和數據傳輸階段。為了克服上面的3個挑戰，dcPIM實現了4個關鍵的設計： ?

理論分析結果表明，dcPIM可以用更少的匹配輪數實現接近最優的網絡利用；

為了處理over subscription和failure，dcPIM使用接收端驅動的單包admission control機制；

為了處理數據中心的匹配階段的高延遲，dcPIM流水化處理匹配和數據傳輸階段；

流水化匹配和數據傳輸后，為了保證兩個階段的時間匹配，dcPIM擴展PIM的算法：為每一個發送端匹配多個接收端，也為每個接收端匹配了多個發送端。

實驗評估

作者在pHost上實現了dcPIM。使用了3種拓撲：leaf-spine，fattree，和oversubscibed。3種工作負載：IMC10，Web Search和Data Mining。3種traffic patterns：all-to-all，bursty，dense traffic ?matrix。評估的協議有：Homa Aeolus，NDP，HPCC。評估的metrics：slowdown，utilization。鏈路屬性：end-hosts使用100Gbps，leaf-spine的交換機間使用400Gbps，FatTree的交換機間使用100Gbps。交換機屬性：每個端口buffer是500KB，交換機buffer是16MB，450ns處理延遲和包傳播。 ? 結論如下： ?

dcPIM實現了接近最優的尾延遲和網絡利用率；

基于匹配的設計使dcPIM快速收斂到高網絡利用率；

dcPIM可以實現比理論bound更有的網絡利用率。

總結

從pHost，NDP和Homa的設計出發，dcPIM提取了connection-less design， per-packet load balancing，packet priorition和fast loss recovery。為短流實現了接近最優的延遲。從現代數據中心和交換機fabrics的相似性出發，dcPIM處理了包括適配數據中心大規模拓撲，隱藏數據中心RTT，擴大到100Gbps規模，處理網絡內擁塞，從而實現了數據中心的吞吐量最優的調度機制。 ?

個人觀點

本文改進了PIM，提升了數據中心短流低延遲，長流高利用率。個人第一次接觸PIM方法，對把PIM應用到數據中心吞吐量調度方法感到有趣。 ?

Jupiter evolving: transforming google's datacenter network via optical circuit switches and software-defined networking

Leon Poutievski, Omid Mashayekhi, Joon Ong, Arjun Singh, Mukarram Tariq, Rui Wang, Jianan Zhang, Virginia Beauregard, Patrick Conner, Steve Gribble, Rishi Kapoor, Stephen Kratzer, Nanfang Li, Hong Liu, Karthik Nagaraj, Jason Ornstein, Samir Sawhney, Ryohei Urata, Lorenzo Vicisano, Kevin Yasumura, Shidong Zhang, Junlan Zhou, Amin Vahdat

? 本論文由Google團隊完成，主要回顧了Google數據中心網絡Jupiter近十年的發展歷程。 ?

背景

雖然使用商用芯片構建的軟件定義網絡和Clos拓撲使得建筑規模數據中心網絡成為云基礎設施的基礎，并且在其他方面也影響巨大，但是很少有人關注如何管理建筑性規模網絡的異構性和增量演進。云基礎設施以增量方式增長，每次增加一個機架或者一個服務器，填滿一座空置的建筑物通常需要幾個月到幾年的時間。建筑物裝滿之后，就會對建筑物立面的基礎設施進行更新，通常每次使用最新一代的服務器硬件更新一個機架。指數級增長和不斷變化的業務需求的現實意味著最好的放置計劃很快就會變得不高效甚至過時，這使得增量和自適應進化成為必要。 ? 對于計算和存儲基礎設施的增量更新相對簡單——每次使用新一代硬件更新一個機架上的基礎設施。網絡基礎設施的增量更新相對更難，需要預先為整個Clos結構的網絡構建主干層，這樣會將數據中心的帶寬限制為在主干部署時可用的網絡帶寬。如下圖所示，一個通用的3層Clos架構包括帶有ToR交換機的機架、連接機架的聚合塊以及連接聚合塊的主干塊。 舉個例子，使用40Gbps技術，每個主干塊可以支持512x40Gbps=20Tbps的突發帶寬。隨著下一代100Gbps的推出，更新的聚合塊可以支持512x100Gbps=51.2Tbps的突發帶寬，但是由于先前主干塊的40Gbps的帶寬限制，每個聚合塊的突發帶寬仍為20Tbps。網絡帶寬的不足會使得服務和存儲容量降低。如果要增加網絡中心的帶寬，需要更新整個建筑規模的主干，這也是不可取的，因為代價昂貴、耗時、需要重新布線。 ? 為了應對這一問題，論文提出了一種新的端到端設計。 ?

設計

本論文利用optical circuit switch將Jupiter從Clos架構遷移到塊級直連結構，從而消除了主干交換層及其相關挑戰。這使得Juptiter能夠整合40Gbps、100Gbps及更高的網絡帶寬速度。除此之外，本論文將直連架構與網絡管理、流量和拓撲工程技術相結合，使得Juptiter能夠應對流量的不確定性、大量的結構異構性，并且可以在不需要任何停機或服務消耗的情況下進行演進更新。具體來說，Jupiter數據中心互連層采用基于微機電系統 (MEMS) 的光電路開關 (OCS) 來實現： ?

動態拓撲重新配置；

用于流量工程的集中式軟件定義網絡 (SDN) 控制；

用于增量容量交付和拓撲工程的自動化網絡操作。

性能評估

與靜態的Clos結構相比，本論文的設計在速度、容量和額外的靈活性方面提高了5倍，并且降低了30%的成本以及41%的功耗。 ?

總結

本文回顧了 Google 數據中心網絡 Jupiter 近十年的發展歷程。這一旅程的核心是基于 MEMS 的光電路交換機、軟件定義網絡和自動安全操作作為關鍵的支持技術。借助這些底層技術，Jupiter 轉變為可增量部署的結構，其中異構網絡塊共存并以模塊化方式更新。 ? Jupiter 從一個標準的 Clos 拓撲開始，它為任意可接受的流量模式提供最佳吞吐量。為了利用生產網絡中的閑置的容量并解決 Clos 結構中的主干塊的技術更新挑戰，作者將 Jupiter 演變為直接連接拓撲，并為觀察到的塊級流量模式啟用動態流量和拓撲工程。與傳統的 Clos 方法相比，這樣做可以實現相當的吞吐量和更短的平均路徑，此外還可以節省大量的資本支出和運營支出。?