背景
高帶寬、低延遲是目前數據中心應用的基本需求。NVM（Non-Volatile Memory）和 RDMA（Remote Direct Memory Access）可以稱得上加速數據中心應用的兩架馬車，分別從存儲和網絡方面滿足高帶寬、低延遲的需求。
TCP/IP 只適用於中等帶寬需求且延遲不敏感的應用，不同層級間的數據拷貝和協議棧本身複雜性（現代網卡已經支持部分功能卸載，例如 TSO、CSO、LRO 等，但並不徹底）爲 TCP/IP 應用引入了大量延遲。RDMA 通過 Memory Region 機制使得網卡能夠直接讀寫用戶態的內存數據，避免了數據拷貝和上下文切換；並將網絡協議棧從軟件實現 offload 到網卡硬件實現，極大降低了 CPU 開銷。隨着 RoCEv2（RDMA over Converged Ethernet v2）技術的成熟，RDMA 可以部署在數據中心已有的網絡設施上，RDMA 成爲數據中心高速網絡通信的主流方案。
在大規模數據中心中部署 RoCEv2，首先面臨的問題是如何保證 RDMA 的可靠傳輸。
可靠傳輸
可靠傳輸是傳輸層對上層應用的承諾，上層幾乎不需要擔心丟包或者重傳的問題（只需要配置重試次數和超時時間）。可靠傳輸的核心是如何應對網絡丟包。
爲什麼會發生丟包？
當發送方發包速率超過了接收方的處理能力時，數據包開始在接收方的接收隊列中積壓，如果積壓情況持續沒有緩解直到接收隊列滿載，接收方只能選擇將之後接收到的數據包丟棄。這裏的接收方可能是數據包的最終接收者或者中間經過的交換機、路由器。
爲什麼需要可靠傳輸？
可靠傳輸是數據中心應用穩定低延遲的保證。一旦發生丟包，傳輸層通常會懲罰性地乘性減慢（Multiplicative-decrease）發送速率，並重傳丟棄的數據包，用戶會感受到突發的性能降級。
以下原因導致了丟包在數據中心網絡中很容易發生：
● 普通交換機的淺緩衝區特性。由於成本原因，數據中心交換機的緩衝區一般都不大（幾 MB 到數十 MB）。這些緩衝區被所有端口共享 [8]，以便實現統計意義的多路複用。
● 許多分佈式應用都遵循 Partition/Aggregate 這種通信模式 [4]。一個請求可能分散到多個工作節點進行處理，每個節點處理數據集的一部分。處理完畢後，所有的工作節點幾乎同時地把結果匯聚到同一個節點做數據整合。這是典型多打一的場景（又稱爲 Incast），匯聚節點所在的端口很容易出現積壓。
● 多路徑負載不均衡。當網絡拓撲中存在多條可達路徑時，RoCEv2 通過 ECMP（Equal-cost multi-path） 爲每個 Flow 選擇合適的路由。ECMP 沒有感知擁塞情況的能力，Flow 可能被分配到擁塞程度已經十分嚴重的路徑，引起擁塞加劇和丟包。
丟包對 RDMA 造成大幅性能下降，這是由 RDMA 的重傳機制決定的。
RDMA 的重傳機制實現在網卡內部，功能比較簡單。如下圖，RDMA 接收方網卡對於每個成功接收到的數據包，都會回覆一個 ACK 包。如下圖中，PSN（Packet Sequence Number）爲 2 的數據包在發送的過程中被丟棄，接收方接收到 PSN 爲 3 的數據包時發現 PSN 不連續，會回覆一個 PSN 2 的 NACK（Not ACK）給發送方，丟棄後續接收到的數據包（PSN 3 ~ 5）。發送方需要重發 PSN 2 之後的所有數據包，導致大幅性能下降。一般我們稱這種方式爲 Go-back-N 重傳方式，即重傳丟棄的數據包 N 之後的所有數據包（Mellanox CX-6 系列網卡已經支持選擇性重傳，但存在一些限制[16]）。而 TCP 的重傳則只需要重傳丟失的單個數據包，丟包帶來的性能負面影響比 RDMA 小得多。
因此 RDMA 要求 L2 層或者 L3 層網絡是無損的。利用流量控制可以防止收發雙方速率不匹配導致的丟包問題。
流量控制和它帶來的問題
流控的原理是，接收方在預測到將要丟包之前通知發送方停止發包。下面介紹幾種流控算法的演變。
Global Pause
Global Pause 是 1997 年在 IEEE 802.3x 定義的第一種以太網流控機制，工作在 L2 層。
其工作原理是，接收方發現接收隊列深度超過某個閾值時，向發送方發送 XOFF Pause Frame，發送方接收到後就停止一切發送操作，直到收到接收方發來的 XON 控制消息或者超時。
Global Pause 無法對流量進行區分，對於上層應用一些高優先級的流量也會被暫停。
PFC（Priority Flow Control）
爲了解決 Global Pause 不區分流量類型的問題，IEEE 802.1Qbb 定義的 PFC 提出了對網絡流量按照優先級 0 - 7 分類。
如上圖，對於每個通信實體，有邏輯上的 Egress 端口和 Ingress 端口，分別對應出口和入口流量。每個端口都有 8 個隊列，對應優先級 0 - 7，不同優先級的數據包會緩存在不同隊列中。
在通信過程中，接收方發現 p1 隊列深度超過 XOFF 閾值，意味着數據包積壓，接收方發送一個 p1 優先級的 PFC Pause Frame 給發送方。Pause Frame 會包含了每個優先級需要暫停發送的時間。發送方將暫停 p1 優先級數據包的發送，直到收到對方發過來恢復控制幀。
按照優先級字段在數據包中的存放位置，可以將 PFC 分成兩類。
（1）基於 PCP 的 PFC
在 IEEE 802.1Qbb 最初的規定，類別 CoS （Class of Service）保存在 L2 層 VLAN Tag 的 PCP（Priority Code Point，3 bits）字段上。
（2）基於 DSCP 的 PFC
然而，VLAN 在某些生產環境可能帶來不便，例如有的生產環境需要使用 PXE 方式安裝部署系統，而 PXE 啓動時候是沒有 VLAN 配置的。RoCEv2 包含了 IP 頭部，因此可以考慮將優先級保存在 IP 頭部的 DSCP 字段。Microsoft 於 2016 年提出了基於 DSCP 的 PFC [1]。 目前大部分廠商的交換機和 RoCE 網卡都已經支持基於 DSCP 的 PFC。
PFC 的問題
在實際部署中 PFC 性能不佳，會導致不公平問題和 Head-of-Line 堵塞問題。
（1）不公平問題
如上圖 a)，交換機上兩個流入端口有數據流向同一個流出端口：Ingress 1 攜帶 Flow 1，Ingress 2 攜帶 Flow 2 和 3。
圖 b) 觸發了 PFC Pause，Ingress 1 和 2 同時暫停發送。
圖 c) Egress 1 隊列空閒，通知 Ingress 1 和 2 恢復發送。
圖 d) 由於 Ingress 1 和 2 是同時暫停和恢復的，Flow 2 和 3 需要競爭 Ingress 2，導致 Flow 1 始終能夠獲得比 Flow 2 或 3 更高的帶寬，出現了不同 Flow 帶寬分配不公平。
（2）Head-of-Line 堵塞問題
如上圖 a)，Flow 1 和 Flow 2 從同一個 Ingress 1 流向不同的 Egress 1 和 2。
圖 b)，Egress 1 觸發了 PFC Pause，Ingress 1 暫停發送。Flow 2 並不需要經過 Egress 1，卻受其影響也被暫停了。
如何解決 PFC 問題
PFC 問題本質的原因是，Pause 機制運行在「端口 + 優先級」這個級別，不能細化到每一個 Flow，而粗暴地將整個發送端口停下來了。如果能夠動態地調整每個 Flow 的發送速率，保持端口的隊列深度比較穩定，那麼就不會觸發 PFC Pause 了。因此，基於 Flow 的擁塞控制算法出現了。
擁塞控制
擁塞控制與 PFC 有兩個明顯區別：
● 擁塞控制根據擁塞程度動態調節發送速率，而 PFC 會讓發送端口完全停下；
● 擁塞控制一般會由接收方將擁塞情況通知到真正的發送方，而 PFC 只會通知前一跳。
後者意味着擁塞控制能夠實現在 Flow 級別：當接收方發現擁塞發生，將會在擁塞通知消息中攜帶 Flow 標識，通知到發送方。發送方可以據此調節該 Flow 的發送速率。在 RoCE 的語境中，Flow 可以通過一對 RDMA QP（Queue Pairs）來標識。
擁塞控制是一個自適應調節過程，依賴於一個好的擁塞檢測方法。
擁塞檢測
檢測擁塞的方式大致可以歸爲三類：基於丟包檢測、基於 ECN 的檢測和基於 RTT 的檢測。
（1）基於丟包檢測
基於丟包檢測的原理很顯然，丟包是擁塞持續得不到緩解的最終結果。TCP 經典的 Tahoe 算法和 CUBIC 算法 [19]，都是基於丟包來做檢測的。上文提到，丟包對於 RDMA 的性能影響要比 TCP 大得多，如果等到已經丟包再進行控制成本就太高了，因此 RDMA 不能採用這種方式。
（2）基於 ECN 檢測
ECN（Explicit Congestion Notification）是 IP 頭部 Differentiated Services 字段的後兩位，用於指示是否發生了擁塞。它的四種取值的含義如下：
| Binary | Keyword | 含義 |
|---|---|---|
| 00 | Non ECN-Capable Transport | 表示發送方不支持 ECN |
| 01 | ECN Capable Transport | 表示發送方支持 ECN |
| 10 | ECN Capable Transport | 同上 |
| 11 | Congestion Encountered | 表示發生了擁塞 |
部署 ECN 功能一般需要交換機同時開啓 RED。如果通信雙方都支持 ECN（ECN 爲 01 或者 10），當擁塞出現時，交換機會更新報文的 ECN 爲 11（Congestion Encountered），再轉發給下一跳。接收方可以根據 ECN 標誌向發送方彙報擁塞情況，調節發送速率。
RED，即 Random Early Drop，是交換機處理擁塞的一種手段。交換機監控當前的隊列深度，當隊列接近滿了，會開始隨機地丟掉一些包。丟棄包的概率與當前隊列深度正相關。隨機丟棄帶來的好處是，對於不同的流顯得更公平，發送的包越多，那麼被丟棄的概率也越大。
當 RED 和 ECN 同時開啓，擁塞發生時交換機不再隨機丟包，而是隨機爲報文設置 ECN。
（3）基於 RTT 檢測
RTT（Round-Trip Time）是發送方將數據包發送出去，到接收到對端的確認包之間的時間間隔。RTT 能夠反映端到端的網絡延遲，如果發生擁塞，數據包會在接收隊列中排隊等待，RTT 也會相應較高。而 ECN 只能夠反映超過隊列閾值的包數量，無法精確量化延遲。
RTT 可以選擇在軟件層或者硬件層做統計。一般網卡接收到數據包後，通過中斷通知上層，由操作系統調度中斷處理收包事件。中斷和調度都將引入一些誤差。因此，更精確地統計最好由硬件完成，當網卡接收到包時，網卡立即回覆一個 ACK 包，發送方可以根據它的到達時間計算 RTT。
需要注意的是，ACK 回覆包如果受到其他流量影響遇到擁塞，那麼 RTT 計算會有偏差。可以爲 ACK 回覆包設置更高優先級。或者保證收發兩端網卡的時鐘基本上同步，然後在回覆包加上時間戳信息。另外，網絡路徑的切換也會帶來一些延遲的變化。
下面介紹 RDMA 下分別基於 ECN 和 RTT 檢測的兩種主流控制算法。
控制算法
（1）DCQCN（ECN 檢測）
DCQCN（Data Center Quantized Congestion Notification）是 2015 年由 Microsoft 和 Mellanox 提出的 RoCEv2 的擁塞控制算法 [2]。其設計基於 QCN（Quantized Congestion Notification）[3] 和 DCTCP（Data Center TCP）[4]。
QCN 是 802.1Qau 定義的 L2 層擁塞控制算法，通過統計單位時間窗口 ECN 標記報文的數量來量化擁塞程度。發送方可以根據量化擁塞程度動態調節發送速率。QCN 通過 MAC 地址來識別一個 Flow，Flow 的接收端將擁塞信息反饋給發送端。如果網絡流量跨路由，報文的 MAC 地址將發生變化，接收端無法知道真正的發送端 MAC 地址，擁塞信息也就無法抵達發送端了，因此 QCN 不適用於跨路由的網絡。
DCTCP 由網絡界大佬 Mohammad Alizadeh 提出，主要改善數據中心小流量被大流量搶佔的問題。接收方對於每個打上 ECN 標記的包，都會回覆一個 ECN-ECHO 的 ACK，發送方可以根據它來量化擁塞程度，按比例調節擁塞窗口。與普通 TCP 不同的是，TCP 遇到擁塞直接將擁塞窗口（更準確的是擁塞門限值）減小一半。
DCQCN 把 QCN 拓展到 IP 網絡，以便用於 RoCEv2，主要功能實現在 RDMA 網卡中，中間交換機只需要支持 RED/ECN。
DCQCN 可以劃分爲三個部分：
擁塞點算法
中間交換機檢查當前擁塞情況，當隊列深度超過閾值時，通過 RED/ECN 標記報文，然後轉發給下一跳。
通知點算法
由接收方網卡完成，主要是把擁塞信息通知到發送方。RoCEv2 新增了 CNP（Congestion Notification Packets）控制報文用於擁塞通知。接收方網卡檢查每個接收包的 ECN 標誌，如果 CN 被設置，那麼發送 CNP 給發送方。爲了減少性能開銷，每 50 us 只發送一個 CNP（DCTCP 是每個包都回復一個）。
響應點算法
由發送方網卡完成，負責調節發送速率避免擁塞。在每個週期窗口，發送方網卡更新擁塞程度參數（取值爲 0 ~ 1），更新的依據是：
● 如果收到擁塞通知，增加擁塞參數
● 否則，逐漸減少擁塞參數
然後根據擁塞程度參數調節發送速率（Rt 爲目標速率，Rc 爲當前速率），
● 如果收到擁塞通知，降低速率（最多降低到原來的一半）：
● 否則（與 QCN 一樣）
○ 快速恢復（持續沒收到擁塞通知的前五個週期，每個週期爲每發出 150 KB 報文或者 10 ms），向上一次遇到擁塞的速率 Rt 靠近：
○ 主動恢復（快速恢復後，每個週期爲 50 個報文或者 5 ms），探測可用帶寬（可能超過 Rt）：
其中擁塞點算法依賴於交換機的已有的 RED/ECN 功能。而通知點和響應點算法需要在 RDMA 網卡實現，包括收發 CNP 報文、發送端需要增加對於每個 Flow 的計時器和字節計數器。目前 Mellanox 的網卡已經支持 DCQCN。
（2）Timely（RTT 檢測）
Timely 與 DCQCN 同年出現 SIGCOMM 會議上，由 Google 提出，旨在提供一種通用的擁塞控制方法，而不僅限於 RoCE [5]。它是數據中心網絡第一個基於延遲的擁塞控制算法。
Timely 算法主要包括三個部分，它們都運行在發送方。算法不涉及中間交換機的處理，但要求接收方網卡對於每一個接收包回覆一個 ACK。
RTT 統計模塊
Timely 中將 RTT 定義爲數據包在網絡中傳播時間與在隊列中等待時間之和。下面的公式中，發送的時間戳由發送方軟件層記錄；完成的時間戳爲發送方接收到接收方網卡返回的 ACK 時間戳。由於一個大包可能被拆分成多個，同時數據包從網卡發送出去有傳輸時延，因此還需要減去這部分時間。
速率計算模塊
對於每一個發包結束事件，速率計算模塊從 RTT 統計模塊得到該包的 RTT，然後輸出一個期望的發送速率。
Timely 並沒有根據 RTT 的絕對值來衡量擁塞情況，而是通過 RTT 的梯度變化來捕捉延遲變化：當 RTT 上升時，表明擁塞愈發嚴重；反之，擁塞正在減輕。這種方式對於延遲更加敏感，有利於滿足應用低延遲需求。
速率計算的算法如上圖，首先計算 RTT 梯度變化。計算連續兩個 RTT 的差值，並與歷史值做平滑化過濾掉突發抖動帶來的偏差，然後再與 minimum RTT（可以取值爲估計的網絡傳播往返時間）做歸一化，得到 RTT 梯度變化率。然後確定期望的發送速率：
● 如果新的 RTT 低於 Tlow，那麼採用和性增長（Additive Increment）探測可用帶寬，提高發送速率。流量剛啓動時，RTT 可能會突然增長，這時候不應該視爲擁塞加重。
● 如果新的 RTT 高於 Thigh，那麼採用乘性減少（Multiplicative Decrement）減少發送速率。如果 RTT 持續維持在高水平，但梯度幾乎沒有變化，就需要這個機制防止擁塞。
● 根據 RTT 梯度變化率計算，
○ 如果 RTT 梯度變化率不爲正，說明擁塞減輕，那麼通過和性增長提高發送速率。如果連續五次 RTT 梯度變化率都不爲正，那麼增長步長相應提高。
○ 如果 RTT 梯度變化率爲正，說明擁塞加重，那麼通過乘性減少方式降低發送速率。
速率控制模塊
Timely 在軟件層增加了一個調度器。當應用需要發送數據包時，不會將發送請求提交給網卡，而是先交給調度器。根據前一模塊得到的期望發送速率，調度器將注入發包延遲，把能夠放行的數據包交給網卡發送，將需要延遲發送的數據包加入等待隊列中，在未來發送。
算法對比
DCQCN 作者隨後於 2016 年在文章 [6] 中，通過流體模型和仿真測試證明 Timely 將 RTT 作爲唯一衡量標準，難以同時兼顧公平性和延遲上限；而 DCQCN 卻可以做到。感興趣的同學可以瞭解一下。
下面從檢測方式、不同通信組件行爲、速率調整方式、適用場景等角度對比 DCQCN 和 Timely 兩種擁塞控制算法，同時也把經典的 TCP Tahoe 流控作爲參考。DCQCN 和 Timely 沒有采用基於窗口的調整方式，主要是窗口方式可能出現突發的流量帶來較大延遲，同時實現起來也比基於速率的方式複雜。
| DCQCN | Timely | TCP Tahoe | |
|---|---|---|---|
| 檢測方式 | ECN | RTT 的梯度變化 | 丟包（重複確認或者 ACK 超時） |
| 交換機 | 檢測擁塞設置 ECN | 無 | 無 |
| 接收方 | 網卡發送 CNP 通知擁塞 | 網卡發送 ACK | TCP 發送 ACK |
| 發送方 | 網卡根據是否有 CNP 調整發送速率 | 軟件調度器根據 RTT 調整發送速率 | TCP 根據是否丟包調節擁塞窗口 |
| 速率調整方式 | 基於擁塞參數調節，增加時包括快速增加和主動增加兩階段，減少時是乘性減 | 基於 RTT 的 AIMD | 如果發生丟包，那麼進入快重傳，慢啓動門限降爲當前擁塞窗口一半，擁塞窗口降爲 1 |
| 適用場景 | RoCEv2 | 通用，只要網卡支持發送 ACK | TCP |
在生產中，一般需要調節 DCQCN 和 Timely 的參數，使得它們在 PFC 生效之前先被觸發。但 PFC 仍然是必要的配置，因爲無論是 DCQCN 還是 Timely，RDMA 網卡在開始傳輸時都是以線速發送而不是慢啓動探測，需要藉助於 PFC 防止擁塞和丟包嚴重化。
DCQCN 的實現主要在網卡，是 RDMA 目前推薦的擁塞控制方案。
討論：流控是否有必要？
總結一下，RDMA 對於丟包十分敏感，需要 PFC 流控防止丟包發生。PFC 流控有不公平和 Head-of-Line 堵塞問題，需要藉助擁塞控制緩解它對網絡性能帶來的負面影響。但是，流控和擁塞控制有許多參數需要配置，默認參數無法適應所有場景，在我們的部署中就發現需要進行繁瑣的調參過程。
回過頭來，我們思考一下 RDMA 是否可以沒有 PFC 流控呢？
網卡改進
RDMA 網卡低效的 Go-back-N 重傳方式導致其依賴於 PFC。沿着這一思路，Timely 的作者於 2018 年提出新的 RDMA 網卡設計 IRN（Improved RoCE NIC）[7]。其靈感來源於 iWARP，在設計哲學上卻與 iWARP 有本質差別：iWARP 力求完整地將 TCP/IP 協議棧在網卡內部實現一遍，雖然可以高效應對丟包問題，但是其臃腫而複雜的實現導致其性能低下，在市場上表現弱於 RoCE；IRN 則是在 RoCEv2 之上做加法，只考慮加入最小的功能來去除對 PFC 的依賴。
IRN 主要從兩方面改進 RoCE 網卡：
1）增強丟包恢復機制
類似於 TCP，接收方不丟棄亂序包，發送方只選擇性重傳丟失的數據包。當接收方接收到一個亂序包，接收方會回覆一個 NACK，攜帶當前接收到的包序列號和期望收到的包序列號。發送方根據它就知道哪些包丟失了，哪些包已經被成功接收。
網卡作爲發送方時，通過維護一個位圖記錄發送的包是否收到了確認，如果接收到 NACK 或者發送超時，那麼就會重傳丟失或者超時的數據包。
網卡作爲接收方時，需要處理接收到的亂序包。假設我們限制每個 Flow 最多同時發送 100 個標準 MTU 大小（1 KB）大小的包，爲了支持 1000 個 Flow，網卡需要至少 100 MB 內存緩存亂序的包。而網卡內部一般只有幾 MB 的內存。IRN 提出不緩存接收到的亂序包，而是直接 DMA 寫到用戶的內存中。在這種設計下，需要解決以下問題：
● 首包問題。對於一個 RDMA Write 操作，可能被拆分成多個 MTU 大小的包，只有第一個包包含 RETH（RDMA Extented Transport Header）攜帶遠端的地址信息，如果第一個包在其他包之後被接收，其他包將無法知道 DMA 的目的地址。因此，IRN 要求爲每個包都有 RETH 信息的拷貝。
● WQE（Work Queue Entry）匹配問題。熟悉 RDMA 編程 API 的同學知道，應用通過構造一個 WQE 發起 RDMA 操作，WQE 記錄了操作的描述信息。RDMA 的內部實現假定了每次接收到完整的數據包，對應的就是下一個待處理的 WQE。亂序推翻了這一假設。IRN 要求每個 WQE 有自己的序列號，同時報文頭部需要攜帶序列號信息，用於兩者匹配。
● 尾包問題。RDMA 網卡在處理最後一個包時，一般會對包序列號加一，同時產生一個 CQE（Completion Queue Entry）用於通知上層 RDMA 操作完成。在亂序場景中，只有當同一個操作的所有包都完成傳輸，才能向上通知完成事件。IRN 需要額外的狀態來跟蹤每個包是否是最後一個完成傳輸的包。
● 覆蓋寫問題。假如同一片內存區域發生了兩次 RDMA 寫操作，第一次寫操作發生了丟包，第二次寫先到達，第一次寫經過重傳後到達，就可能出現舊數據將新數據覆蓋。IRN 需要上層應用自己處理這一問題。
2）網卡內實現基於 BDP（Bandwidth Delay Product）的流量控制
Bandwidth 一般是通信雙方網卡支持的速率上限，Delay 是網絡包在網絡信道中的傳播時間，因此 BDP 反映的是端到端的最大通信能力。文中計算 BDP 時 Delay 採用的是其網絡最長路徑的傳播時延估算值，這樣才能保證在最長路徑中，網絡帶寬始終是滿載的。
將每個 Flow 發送中的流量限制在一個 BDP 內，一方面可以減少網卡需要維護每個包狀態的數量，另一方面也降低了中間交換機出現緩衝區溢出的可能性。我們來簡單計算一下：一個 25GbE 兩層網絡架構，跨 ToR 交換機兩個節點間的 RTT 大概是 6us，BDP 爲 19 KB（即 25 * 1000 * 1000 * 1000 * 6 / 1000 / 1000 / 8 B）；而 Mellanox Spectrum 交換機的動態緩衝區大小爲 12 MB，因此可以容忍大約 640 路 Incast。這樣，在一般場景下丟包會很少出現，也就可以去掉 PFC 的配置了。
這種方式可能存在的缺陷是：
● 如果多個 Flow 同時經過同一路徑，即便限制每個 Flow 流量在 BDP 內，在中間路徑交換機上仍舊會開始排隊積壓，乃至出現丟包。一種可能的優化方式是動態地調整 BDP 限制值。
● 它要求整張網絡中沒有其他一些不守規矩的流量。換句話說，它要求網絡中的所有流量都限制在 BDP 內。
● BDP 的取值可能影響性能。如果設置地過小，那麼帶寬可能無法跑滿；設置地過大，可能容易引起擁塞。
總結一下，選擇性重傳實際上在 TCP 早已支持，但在 RDMA 中實現卻是困難重重，這主要是因爲 RDMA 零拷貝的設計以及 RDMA 網卡內部資源受限。IRN 目前並沒有完整實現，帶來的更多是對於未來 RDMA 網卡設計的思考。
應用約束
針對小包傳輸爲主的業務，擁塞導致丟包發生的機率非常小，PFC 就沒有那麼必要了。基於這一思想，Anuj Kalia 提出了 FaSST（Fast, Scalable and Simple Distributed Transactions）[17]（OSDI 2016），一個基於不可靠的 RDMA 數據報傳輸模式設計的分佈式事務系統。FaSST 中的 RPC 大小一般是 256 字節。由於丟包很少發生，FaSST 直接重啓 FaSST 進程，處理方式比較粗暴。
Anuj Kalia 後續在 NSDI 2019 又提出了 eRPC [8]，旨在提供數據中心的一個通用的高性能 RPC 庫，大家不再需要爲了高性能將 RDMA 網絡模塊和業務邏輯耦合在一起實現。eRPC 主要的設計要點有，
● 爲了減少擁塞，IRN 在網卡內部實現基於 BDP 的流量控制，eRPC 則是在應用層實現。eRPC 爲每一個 RPC 會話分配可用的發送額度 credits，其值小於 BDP 與 MTU 的商。RPC 客戶端每次發送一個請求都需要花費一個 credit，服務端確認接收後歸還一個 credit。如果 credits 耗盡，客戶端的請求將進入隊列。eRPC 默認的 credits 額度爲 8。可以想象到 credits 值的選擇將影響到單個會話和多個會話的帶寬和延遲。
● 在 RDMA 數據報傳輸模式下，網卡不會處理丟包或者亂序包。eRPC 會丟棄所有的亂序包，然後客戶端以 Go-back-N 方式重傳丟包序列號之後的所有請求。eRPC 認爲丟包是非常罕見的，因此並沒有在丟包處理上做太多優化。
FaSST 和 eRPC 都是基於不可靠的 RDMA 數據報傳輸模式，不再需要 PFC，適合丟包很少的業務場景。對於像分佈式存儲這樣的業務就不適合了。可見，針對具體業務場景進行選型也是 RDMA 系統設計的重點。
展望
流控和擁塞控制技術是網絡領域的基本問題，對於 RDMA 這種新型網絡也不例外。DCQCN 的出現使得 RDMA 在數據中心真正落地，可以想象未來將會有更多的 RDMA 應用。簡單總結一下 RDMA 應用和研究的現狀。
如何用好 RDMA 本身的研究，如 [13, 14]。這已經比較成熟，前人總結了許多經驗：
● 如何使用 Memory Region 管理內存？
● 如何選擇 RDMA Verbs？
● 編程基於事件驅動還是輪詢？
● 如何減少 MMIO 或者 DMA 操作提高性能？
● 如何避免網卡的 Cache Miss？
● 如何利用好網卡的多隊列和多處理器併發？
流控和擁塞控制。PFC 和 DCQCN 的配置對於大規模數據中心帶來不小挑戰，參數配置會極大影響性能。基於 SDN 由中央控制器負責調度整張網絡的流量是一個比較 promising 的方向。另外，基於機器學習的擁塞控制算法也有不少研究。
網卡架構的新設計。目前 RDMA 網卡已經支持包括 NVMe over Fabric、EC、OvS、VXLAN/NVGRE 等多種功能卸載。對於 IRN 提出的亂序接收問題，Mellanox ConnectX-5 網卡已經支持亂序數據存放，但需要用戶層自己檢測亂序。相信 RDMA 與 SRIOV、NVM、Multi-Path、容器等技術的結合中會對網卡設計帶來更多的需求。
RDMA 在容器中的應用。SRIOV 可以將 RDMA 網卡的虛擬功能分配給容器使用，但是容器遷移時需要重新配置，不夠輕便。最近有一些研究希望在軟件層面實現 RDMA 在容器中的隔離，將 RDMA 控制路徑（如創建 QP，註冊 MR，創建 GID 等）交給軟件層實現，例如 FreeFlow（NSDI 2019）和 MasQ（SIGCOMM 2020）。另外，vDPA [18] 允許 VM 或者 容器通過標準的 VirtIO 控制和數據接口與網卡 VF 交互，目前已經在 RedHat 支持，在未來可能替代 SRIOV，vDPA 與 RDMA 結合也是一個有意思的話題。
RDMA 與新型存儲結合。目前基於 RDMA 的網絡存儲協議發展比較成熟，包括 NFS over RDMA、iSER、NVMe over Fabric 等，許多存儲廠商已經支持。對於新型的 NVM，FileMR（NSDI 2020）提出瞭如何將 RDMA 和 NVM 之間重疊的部分（命名、權限管理、內存管理等）去掉，提高效率。
參考文獻
[1] RDMA over Commodity Ethernet at Scale
[2] Congestion Control for Large-Scale RDMA Deployments
[3] Data Center Transport Mechanisms: Congestion Control Theory and IEEE Standardization
[4] Data Center TCP (DCTCP)
[5] TIMELY: RTT-based Congestion Control for the Datacenter
[6] ECN or Delay: Lessons Learnt from Analysis of DCQCN and TIMELY
[7] Revisiting Network Support for RDMA
[8] Datacenter RPCs can be General and Fast
[9] Traffic Control for RDMA-Enabled Data Center Networks- A Survey
[10] White Paper: RoCE in the Data Center
[11] RDMA in Data Centers: Looking Back and Looking Forward
[12] 數據中心網絡的流量控制：研究現狀與趨勢
[13] Minimizing the Hidden Cost of RDMA
[14] Design Guidelines for High Performance RDMA Systems
[15] Intro to Congestion Control
[16] ConnectX-6 Dx Adapter Cards Firmware Release Notes
[17] FaSST: Fast, Scalable and Simple Distributed Transactions with Two-Sided (RDMA) Datagram RPCs
[18] Achieving network wirespeed in an open standard manner: introducing vDPA
[19] TCP congestion control
作者介紹
Jiewei，SmartX 研發工程師。SmartX 擁有國內最頂尖的分佈式存儲和超融合架構研發團隊，是國內超融合領域的技術領導者。