背景

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

相關(guān)工作

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

設(shè)計

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

實驗評估

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

個人觀點

在網(wǎng)絡(luò)過載的情況下，要求高QoS的RPC數(shù)據(jù)量遠超網(wǎng)絡(luò)的傳輸能力，在這時就要在時延和服務(wù)質(zhì)量之間做出取舍。在這篇論文中，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)

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

背景

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

設(shè)計

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

實驗評估

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

總結(jié)

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

個人觀點

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

背景與問題

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

動機

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

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

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

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

設(shè)計

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

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

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

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

? ABM具備實踐性:

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

性能評估

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

總結(jié)

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

個人觀點

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

背景

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

設(shè)計

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

理論分析結(jié)果表明，dcPIM可以用更少的匹配輪數(shù)實現(xiàn)接近最優(yōu)的網(wǎng)絡(luò)利用；

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

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

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

實驗評估

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

dcPIM實現(xiàn)了接近最優(yōu)的尾延遲和網(wǎng)絡(luò)利用率；

基于匹配的設(shè)計使dcPIM快速收斂到高網(wǎng)絡(luò)利用率；

dcPIM可以實現(xiàn)比理論bound更有的網(wǎng)絡(luò)利用率。

總結(jié)

從pHost，NDP和Homa的設(shè)計出發(fā)，dcPIM提取了connection-less design， per-packet load balancing，packet priorition和fast loss recovery。為短流實現(xiàn)了接近最優(yōu)的延遲。從現(xiàn)代數(shù)據(jù)中心和交換機fabrics的相似性出發(fā)，dcPIM處理了包括適配數(shù)據(jù)中心大規(guī)模拓撲，隱藏數(shù)據(jù)中心RTT，擴大到100Gbps規(guī)模，處理網(wǎng)絡(luò)內(nèi)擁塞，從而實現(xiàn)了數(shù)據(jù)中心的吞吐量最優(yōu)的調(diào)度機制。 ?

個人觀點

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

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數(shù)據(jù)中心網(wǎng)絡(luò)Jupiter近十年的發(fā)展歷程。 ?

背景

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

設(shè)計

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

動態(tài)拓撲重新配置；

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

用于增量容量交付和拓撲工程的自動化網(wǎng)絡(luò)操作。

性能評估

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

總結(jié)

本文回顧了 Google 數(shù)據(jù)中心網(wǎng)絡(luò) Jupiter 近十年的發(fā)展歷程。這一旅程的核心是基于 MEMS 的光電路交換機、軟件定義網(wǎng)絡(luò)和自動安全操作作為關(guān)鍵的支持技術(shù)。借助這些底層技術(shù)，Jupiter 轉(zhuǎn)變?yōu)榭稍隽坎渴鸬慕Y(jié)構(gòu)，其中異構(gòu)網(wǎng)絡(luò)塊共存并以模塊化方式更新。 ? Jupiter 從一個標準的 Clos 拓撲開始，它為任意可接受的流量模式提供最佳吞吐量。為了利用生產(chǎn)網(wǎng)絡(luò)中的閑置的容量并解決 Clos 結(jié)構(gòu)中的主干塊的技術(shù)更新挑戰(zhàn)，作者將 Jupiter 演變?yōu)橹苯舆B接拓撲，并為觀察到的塊級流量模式啟用動態(tài)流量和拓撲工程。與傳統(tǒng)的 Clos 方法相比，這樣做可以實現(xiàn)相當?shù)耐掏铝亢透痰钠骄窂?，此外還可以節(jié)省大量的資本支出和運營支出。?