本文主要解決的問題是在RoCEv2體系中，基於優先級的擁塞控制PFC是一種粗粒度的機制。 它在端口（或端口加優先級）級別上運行，並且不區分流。PAUSE機制是基於每個端口（和優先級）的，而不是基於每個流的。 這將導致Unfairness和Victim flow等問題。爲了解決這個問題，作者提出了DCQCN機制，DCQCN提供快速收斂以達到公平性，實現高鏈路利用率，確保低隊列建立和低隊列振盪。並且爲了優化DCQCN性能，我們建立了一個流體模型，並提供了調整開關緩衝區閾值和其他協議參數的指南。
Abstract
現代數據中心應用要求網絡具有高吞吐量（40Gbps）和超低延遲（每跳<10 µs），且CPU開銷較低。 標準的TCP / IP堆棧不能滿足這些要求，但是可以使用遠程直接內存訪問（RDMA）。 在IP路由的數據中心網絡上，RDMA使用RoCEv2協議進行部署，該協議依賴於基於優先級的流控制（PFC）來實現無損網絡。 但是，由於行首阻塞和不公平之類的問題，PFC可能導致較差的應用程序性能。 爲了緩解這些問題，我們引入了DCQCN，它是RoCEv2的端到端擁塞控制方案。 爲了優化DCQCN性能，我們建立了一個流體模型，並提供了調整開關緩衝區閾值和其他協議參數的指南。 通過使用3層Clos網絡測試平臺，我們證明DCQCN極大地提高了RoCEv2 RDMA流量的吞吐量和公平性。 DCQCN已在Mellanox NIC中實現，並已部署在Microsoft的數據中心中。
1. Introduction
諸如雲存儲[16]之類的數據中心應用需要高帶寬（40Gbps或更高）才能滿足不斷增長的客戶需求。 傳統的TCP / IP堆棧不能以這種速度使用，因爲它們具有非常高的CPU開銷[29]。 雲服務業務的殘酷經濟學表明，應將無法貨幣化的CPU使用率降到最低：用於支持高TCP吞吐量的核心是不能作爲VM出售的核心。 其他應用程序，例如分佈式內存緩存[10、30]和大規模機器學習，都要求超低延遲（每跳小於10 µs）的消息傳輸。 傳統的TCP / IP堆棧具有更高的延遲[10]。
我們正在Microsoft的數據中心中部署遠程直接內存訪問（RDMA）技術，以提供超低延遲和高吞吐量的應用程序，而CPU開銷卻非常低。 使用RDMA，網絡接口卡（NIC）可以在兩個終端主機上的預註冊內存緩衝區中進出數據。 網絡協議完全在NIC上實現，繞過主機網絡堆棧。 Kernel-by-pass大大降低了CPU開銷和整體延遲。 爲了簡化設計和實現，該協議採用了無損網絡結構。
儘管HPC社區在特殊用途的集羣中長期使用RDMA [11、24、26、32、38]，但在現代的IP路由數據中心網絡中大規模部署RDMA卻帶來了許多挑戰。 一個關鍵的挑戰是需要一種擁塞控制協議，該協議可以在高速，無損環境中高效運行，並且可以在NIC上實現。
爲此，我們已經開發了一種稱爲數據中心QCN（DCQCN）的協議。 DCQCN建立在RoCEv2標準中定義的擁塞控制組件的基礎上。 DCQCN在Mellanox NIC中實現，目前正在Microsoft的數據中心中部署。
要了解DCQCN的需求，有必要指出，從歷史上看，RDMA是使用InfiniBand（IB）[19，21]技術進行部署的。 IB使用定製的網絡堆棧和專用硬件。 IB鏈路層（L2）使用基於hop-by-hop流量控制來防止由於緩衝區溢出而導致數據包丟失。 無損鏈路層L2使IB傳輸協議（L4）變得簡單而高效。 大部分IB協議棧都在NIC上實現。 IB通過所謂的單邊操作支持RDMA，其中服務器在其NIC上註冊一個內存緩衝區MR，客戶端從該NIC讀取（寫入），而無需服務器CPU的進一步參與。
但是，IB網絡堆棧無法輕鬆地部署在現代數據中心中。 現代數據中心採用IP和以太網技術構建，而IB堆棧與此不兼容。 DC運營商不願在同一數據中心內部署和管理兩個獨立的網絡。 因此，爲了啓用基於以太網和IP網絡的RDMA，已經定義了基於聚合以太網（RoCE）[20]的RDMA標準及其後繼產品RoCEv2 [22]。 RoCEv2保留IB傳輸層，但用IP和UDP封裝代替IB網絡層（L3），並用以太網代替IB L2。 IP標頭用於路由，而UDP標頭用於ECMP [15]。
爲了實現高效運行，例如IB，RoCEv2也必須部署在無損鏈路層L2上。 爲此，使用基於優先級的流量控制（PFC）來部署RoCE [18]。 PFC允許以太網交換機通過強制級聯的上游實體（另一臺交換機或主機NIC）暫停數據傳輸來避免緩衝區溢出。 但是，PFC是一種粗粒度的機制。 它在端口（或端口加優先級）級別上運行，並且不區分流。 這可能導致擁塞擴散，從而導致性能不佳[1，37]。（基於優先級的流量控制存在的問題）
PFC侷限性的基本解決方案是flow-level級別的擁塞控制協議。 在我們的環境中，該協議必須滿足以下要求：（i）通過無損鏈路層，L3路由的數據中心網絡進行的功能；（ii）在最終主機上產生較低的CPU開銷；以及（iii）在公共端提供超快速啓動沒有擁塞的情況。 當前用於DC網絡中擁塞控制的建議不能滿足我們的所有要求。 例如，QCN [17]不支持L3網絡。 DCTCP [2]和iWarp [35]包含一個緩慢的啓動階段，這可能會導致突發存儲工作負載的性能下降。 DCTCP和TCP-Bolt [37]是用軟件實現的，並且可能具有很高的CPU開銷。
由於當前的提議都不能滿足我們的所有要求，因此我們設計了DCQCN。 DCQCN是RoCEv2的端到端擁塞控制協議，用於在大型IP路由數據中心網絡中部署RDMA。 DCQCN僅需要數據中心交換機支持標準的RED [13]和ECN [34]。 協議的其餘功能在最終主機NIC上實現。 DCQCN提供快速收斂以達到公平性，實現高鏈路利用率，確保低隊列建立和低隊列振盪。
本文的結構如下。 在§2中，我們提供證據來證明需要DCQCN。 第3節介紹了DCQCN的詳細設計，並簡要介紹了硬件實現。 在§4中，我們展示瞭如何設置PFC和ECN緩衝器閾值以確保DCQCN的正確運行。 在§5中，我們描述了DCQCN的流體模型，並用它來調整協議參數。 在§6中，我們使用3層測試平臺和來自數據中心的跟蹤來評估DCQCN的性能。 我們的評估表明，DCQCN大大提高了RoCEv2 RDMA流量的吞吐量和公平性。 在某些情況下，它使我們可以處理多達16倍的用戶流量。 最後，在§7中，我們討論了諸如非擁塞包丟失之類的實際問題。
2. THE NEED FOR DCQCN
爲了證明對DCQCN的合理性，我們將證明TCP堆棧不能以低CPU開銷和超低延遲提供高帶寬，而RoCEv2上的RDMA可以提供。 接下來，我們將證明PFC會損害RoCEv2的性能。 最後，我們將爭辯說，現有的解決PFC疾病的解決方案不適合我們的需求。
2.1 Conventional TCP stacks perform poorly
現在，我們比較RoCEv2和傳統TCP堆棧的吞吐量，CPU開銷和延遲。 這些實驗使用通過40Gbps交換機連接的兩臺機器（Intel Xeon E5-2660 2.2GHz，16核，128GB RAM，40Gbps NIC，Windows Server 2012R2）。
Throughput and CPU utilization：爲了測量TCP吞吐量，我們使用針對環境定製的Iperf [46]。 具體來說，我們啓用LSO [47]，RSS [49]和zero-copy操作，並使用16個線程。 爲了測量RDMA吞吐量，我們使用了一個自定義工具，該工具使用IB READ操作來傳輸數據。 使用RDMA，單個線程會使鏈接飽和。
圖1（a）顯示TCP具有很高的CPU開銷。 例如，消息大小爲4MB，以驅動全部吞吐量，TCP在所有內核上平均消耗20％以上的CPU週期。 在較小的消息大小下，由於CPU成爲瓶頸，TCP無法使連接傳輸飽和。 馬裏諾斯（Marinos）等人 [29]曾報道Linux和FreeBSD的TCP性能同樣差。 他們甚至建議的用戶級堆棧也會消耗20％以上的CPU週期。 相反，即使對於較小的消息大小，RDMA客戶端的CPU利用率也低於3％。 正如預期的那樣，RDMA服務器幾乎不佔用CPU週期。
Latency：延遲是小規模數據傳輸的關鍵指標。 現在，我們比較使用TCP和RDMA傳輸2K消息的平均用戶級別延遲。 爲了最大程度地減少TCP延遲，已預先建立並預熱了連接，並禁用了Nagle。 使用高分辨率計時器（≤1 µs）測量延遲[48]。 網絡上沒有其他流量。
圖1（c）顯示TCP延遲（25.4 µs）明顯高於RDMA（讀/寫爲1.7 µs，發送爲2.8 µs）。 在Windows的[10]和Linux [27]中報告了類似的TCP延遲。
2.2 PFC has limitations
RoCEv2需要PFC才能啓用無損以太網結構。 PFC可以防止以太網交換機和NIC上的緩衝區溢出。 交換機和NIC跟蹤入口隊列。 當隊列超過特定閾值時，將PAUSE消息發送到上游實體。 然後，上游鏈路實體停止在該鏈路上發送，直到獲得RESUME消息爲止。 PFC最多指定八個優先級類別。 暫停/恢復消息指定了它們適用的優先級。
問題在於，PAUSE機制是基於每個端口（和優先級）的，而不是基於每個流的。 這可能導致行頭阻塞問題； 導致個別流的效果不佳。 現在，我們使用代表現代數據中心網絡的3層測試平臺（圖2）來說明問題。
Unfairness:：考慮圖3（a）。 四個發送方（H1-H4）使用RDMA WRITE操作將數據發送到單個接收器（R）。 所有發送者都使用相同的優先級。 理想情況下，四個發送方應平均共享瓶頸鍊接（T4至R）。 但是，對於PFC，存在不公平。 當隊列開始在T4上建立時，它將暫停傳入的鏈接（端口P2-P4）。 但是，P2僅承載一個流（來自H4），而P3和P4可能承載多個流，這是因爲H1，H2和H3必須共享這兩個端口，具體取決於ECMP如何映射這些流。 因此，H4比H1-H3獲得更高的吞吐量。 這被稱爲parking lot problem問題[14]。
如圖3（b）所示，該圖顯示了H1-H4在1000次4MB數據傳輸中測得的最小，中值和最大吞吐量。 H4的吞吐量高達20Gbps，例如 當ECMP將所有H1-H3映射到P3或P4時。 H4的最小吞吐量高於H1-H3的最大吞吐量。
Victim flow：由於PAUSE幀可能具有級聯效果，因此流甚至可能不在其路徑上被擁塞所傷害。 考慮圖4（a）。 四個發送器（H11-H14）將數據發送到R。此外，我們有一個“受害者流”-VS發送到VR。 圖4（b）顯示了受害流的中值吞吐量（每個250MB的250個傳輸）。
如果在T3下沒有發送方，則在中間值情況下（H11-H14中的兩個映射到T1-L1，其他映射到T1-L2。每個H11-H14獲得10Gbps的吞吐量。VS映射到T1的一個上行鏈路），一個可能 期望VS獲得20Gbps的吞吐量。 但是，我們看到它只能得到10Gbps。 這是由於級聯的“暫停”。 由於T4是H11-H14傳播的瓶頸，因此最終會暫停其傳入的連接。 這進而導致L3和L4暫停其傳入的鏈接，依此類推。 最終，L1和L2最終暫停了T1的上行鏈路，並且T1被迫暫停發送者。 使用這些上行鏈路的T1上的數據流同樣受到這些暫停的影響，而不論它們的目的地是什麼–這也被稱爲“head-of-the-line blocking”問題。
當我們啓動發送器H31和H32並將其發送到R時，問題變得更加嚴重。我們看到，儘管從H31和H32到R的路徑沒有任何共同的鏈接，但中值吞吐量進一步從10Gbps下降到4.5Gbps。發生這種情況是因爲H31和H32在L3和L4上與H11-H14競爭，使它們的暫停S1和S2更長，最終使T1暫停發送者更長。
Summary：這些實驗表明，由於PFC的擁塞擴散特性，RoCEv2部署中的流量可能會看到較低的吞吐量和/或較高的可變性。
2.3 Existing proposals are inadequate
許多提案試圖解決PFC的侷限性。 一些人認爲，ECMP可以通過在多個鏈路上分散流量來緩解此問題。 上一節中的實驗表明，情況並非總是如此。 PFC標準本身包含優先級概念，以解決最前端的阻塞問題。 但是，該標準僅支持8個優先級類別，並且通過擴展拓撲並添加更多發件方，可以使上述兩種情況都變得更糟。 此外，同一類別內的流量仍將受到PFC的限制。
PFC問題的根本解決方案是使用流量級別flow-level的擁塞控制。 如果對每個流應用適當的擁塞控制，則很少觸發PFC，因此可以避免本節前面所述的問題。
爲此，定義了量化擁塞通知（QCN）[17]標準。 QCN啓用L2域內的流級別擁塞控制。 使用源/目標MAC地址和流ID字段定義流。 交換機在每個數據包到達時計算擁塞度量。 它的值取決於瞬時隊列大小和所需均衡隊列大小之間的差異，以及其他因素。 然後，交換機可能（概率取決於擁塞的嚴重程度）將擁塞度量的量化值作爲反饋發送到到達數據包的源。 源響應於擁塞反饋而降低其發送速率。 由於在沒有擁塞的情況下不會發送任何反饋，因此發送方使用內部計時器和計數器來提高其發送速率。
QCN不能用於IP路由網絡中，因爲流的定義完全基於L2地址。 在IP路由網絡中，當數據包通過網絡傳輸時，原始的以太網報頭不會保留。 因此，擁塞的交換機無法確定向其發送擁塞反饋的目標。
我們考慮將QCN協議擴展到IP路由網絡。 但是，這並非易事。 至少要將QCN擴展到IP路由網絡，需要使用IP五元組作爲流標識符，並在擁塞通知數據包中添加IP和UDP標頭，以使其能夠到達正確的目的地。 要實現這一點，需要對NIC和交換機進行硬件更改。 由於QCN功能已深深集成到ASIC中，因此對開關進行更改尤其成問題。 ASIC供應商實施，驗證和發佈新的交換ASIC通常需要數月甚至數年的時間。 因此，更新芯片設計不是我們的選擇。
在§8中，我們將討論爲什麼其他提議（例如TCP-Bolt [37]和iWarp [35]）不能滿足我們的需求。 由於現有建議不足，出於我們的目的，我們提出DCQCN。
3. THE DCQCN ALGORITHM
DCQCN是基於速率的端到端擁塞協議，它基於QCN [17]和DCTCP [2]。 大多數DCQCN功能都在NIC中實現。
如前所述，我們對DCQCN有三個核心要求：（i）在無損，L3路由，數據中心網絡上運行的能力，（ii）低CPU開銷，以及（iii）在沒有擁塞的常見情況下超快速啓動 。 此外，我們還希望DCQCN爲公平的帶寬分配提供快速收斂，避免在穩定點附近發生振盪，保持較短的隊列長度，並確保較高的鏈路利用率。
還有一些實際問題：我們不能要求交換機提供任何自定義功能，並且由於該協議是在NIC中實現的，因此我們必須注意實現的開銷和複雜性。
DCQCN算法由發送方（反應點（RP）），交換機（擁塞點（CP））和接收方（通知點（NP））組成。
3.1 ALGORITHM
不改交換機，在NIC上實現，考慮CPU開銷。在性能方面上，要求公平帶寬分配的快速收斂，避免震盪，維持短隊長，確保高鏈路利用率。
CP算法（Congestion Point）：在交換機上。與DCTCP機制相同，利用RED功能依據隊列長度按照概率分佈給數據包打上ECN標籤。本方案中改進了DCTCP的參數設置模型。
NP算法（Notification Point）：在接收端。決定了在收到ECN包後什麼時間和怎樣構造CNP（congestion notification packet）的問題。在某一時間週期內，最多隻發送一個CNP包。N=50us。
RP算法（Reaction Point）：在發送端。當收到CNP包時，怎麼調節速率。當收到CNP包後，依照equation 1 調節；在連續K時間內，未收到CNP包，根據當前計時器（每T個時間單元爲1，保證快恢復）和計數器（每B個字節爲1）的值，按照equation 2 快速增加速率。
4. BUFFER SETTINGS
需求：PFC的觸發要晚於ECN，早於緩存溢出，避免丟包和吞吐量下降
討論的前提：交換機爲共享緩存模式，有32個全雙工的40Gbps端口，12MB的共享內存，支持PFC的8條優先級隊列
Tflight：用於存儲PAUSE包發送時和生效時到達的數據包的內存大小。根據BDP，每個端口，每個優先級所需要的內存空間爲22.4KB。
Tpfc：可理解爲觸發PFC的ingress 隊列中可以佔用的最大內存區域。每個端口的每個優先級隊列的Tpfc值要小於等於24.47KB。而觸發PFC的條件一定要比它小。當隊列內存佔用降低到Tpfc減去兩個MTU的值時，會自動發送RESUME信號，恢復發包。
Tecn：觸發ECN標記的最小egress queue佔用的內存空間。該值的設置一定要使ECN先於PFC觸發。最壞情況下，所有的egress queue的包都來自於同一條ingress queue，爲保證ecn先於pfc觸發，則Tecn應小於0.85KB，小於一個MTU長度，不可行。這種想法過於靜態，由於交換機內緩存資源是共享的，所以Tpfc的設置應取決於剩餘的可用資源。如下公式：
4. ANALYSIS OF DCQCN
建立了當前速率，目標速率，速率增長步長，速率調節參數α，等一系列參數。
實驗結果：搭建實驗牀驗證流模型和參數設置的有效性
DCQCN是基於速率調整的擁塞控制方案，DCTCP、iWarp和TCP-Bolt都是基於窗口的擁塞控制算法。
下一步研究方向：將機器學習應用到DCQCN算法中調節參數設置