本文只代表作者個人觀點
---------------------
RDMA的設計思路
（一）摘要
本文討論，RDMA網絡的2種設計思路：
容損網絡：Chelsio公司主導的iWarp
無損網絡：Mellanox公司主導的InfiniBand, RoCE，
Chelsio經常公開指責 RoCE的設計思路（無損）有不可克服的理論缺陷和風險，
Mellanox 從不在理論上與Chelsio辯論，而是用優秀的測試結果和客戶選擇回擊Chelsio。
本文要討論2個問題：
（1）為啥RoCE要求網絡不許丟包，而iWarp能容忍網絡丟包？
（2）RoCE“不允許網絡丟包”這種要求合理嗎？
（二）RDMA的兩種流派的設計思路差異：
先回答第一個問題：為啥iWarp不要求網絡無損，而RoCE要求網絡無損？
其根本原因是：“選擇重傳協議” 與 “回退N幀協議” 的差異
iWarp的 “選擇重傳協議” 是丟哪個報文就重傳哪個報文，因此對丟包不敏感。
RoCE的 “回退N幀協議” 是丟失報文序號之后的全部報文都要重發，因此對丟包非常敏感。
iWarp的性能問題，和RoCE的穩定性問題，都源於此。
| 容損網絡：iWarp | 無損網絡：InfiniBand, RoCE | |
| 對待丟包 | 選擇性重傳， 對丟包不敏感 需要緩存報文 |
回退N幀， 對丟包非常敏感 因此想盡辦法讓網絡不丟包。 |
| 對網絡的要求 | 不需要交換機配合， 不要求網絡無損 |
需要交換機配合， 要求網絡無損 InfiniBand是專用交換機， RoCE是普通交換機做流控配置 |
| 成本 | 略有小貴 | InfiniBand：很昂貴 --------------- RoCE：便宜 |
| 易用性 | 易用性很好 | InfiniBand：易用性較好， --------------- RoCE：配置和監控比較麻煩。 |
| 是否需要 集中管控 |
不需要leader來管理。 |
InfiniBand：SubnetManager 就是網絡的leader，InfiniBand網絡不能沒有Leader。 --------------- RoCE：其實也需要全網緊密配合，但實際是沒有leader做交換機到網卡的端到端的拉通，因此用起來很麻煩。 |
| 性能 | 時延大，性能還可以。 | 時延低，性能很好。 |
| 風險 | 存在個體性風險，主要是網卡硬件太復雜。 | 存在系統性風險，即：局部拖累整體。平時很少出問題，可一出問題就是全局性問題。 |
| 可擴展性 | 可擴展性好 | 可擴展性差，只適用於封閉的內網，無法跨地域部署。 |
（三）容損網絡-iWarp
（3.1)iWarp的設計思路是：
把整個TCP/IP協議棧卸載到智能網卡中，由網卡硬件（目前是FPGA）來實現，雖然降低了CPU的負荷，但增加了iWarp網卡的硬件復雜度。
（3.2)iWarp的優點：
不要求交換機做任何配合，選擇性重傳對丟包相對不敏感。
（3.3)iWarp的缺點：
TCP/IP協議對於智能網卡來說過於復雜，開銷大，時延大，因此iWarp的性能比RoCE差。
（3.4) 基於容損網絡的其他設計思路：
SIGCOMM2018：Revisiting Network Support for RDMA
SIGCOMM2018會議上，提出了IRN（Improved RoCE NIC）算法。該設計仍然保留“選擇性重傳” 這一設計思路，作者認為iWarp的思路大方向正確，但是TCP協議對於智能網卡太過復雜，需要簡化。截至今年（2021年），該設計仍處於實驗室階段，沒有經過任何生產環境的考驗。
（四）無損網絡-RoCE
（4.1) RoCE的主要技術
ECN/CNP, DCQCN ：理想的情況是避免發生擁塞
PFC ：一旦發生擁塞，至少不要丟包（PFC是麻煩制造者）
Go-Back-N：一旦丟包，回退N幀，（對丟包過於敏感）
（4.2) PFC：簡單的協議和不簡單的后果
PFC協議說起來很簡單，就是逐層向上游發送流控幀。如果下游網卡接近擁塞，就會向上游交換機發出一個PFC啟動，要求交換機暫停發送。上游交換機在緩存不足時也會向自己的上游各端口發PFC。
說明下：PFC流控是基於端口的，而不是基於流的！
郭傳雄曾經如此評價PFC，PFC看起來非常簡單，但它所導致的后果一點也不簡單。這些后果包括：
不公平降速（Unfairness）和傷及無辜（Victim flow）：
明明是網卡4即將擁塞，為啥網卡1/2/3要跟着一起流控？ 網卡1/2/3之間的通信鏈路，原本與網卡4毫無關系，卻也被無辜的執行流控，這就是不公平降速。我舉個形象的例子，假如北四環堵車，我們去南四環也一起被流控，這公平嗎？
PFC風暴：
假設網卡驅動軟件由於某種原因（比如掛死），沒法及時處理網卡的接收隊列。導致網卡一直處於擁塞狀態，也就一直向上游發出PFC。導致整集群通信中斷，這就是PFC風暴。
（4.3) 永遠慢半拍的ECN/CNP
因為PFC存在種種問題，因此在RoCEV2中，又補充了ECN協議。
(1)發送端發送IP 報文標記ECN(ECN=10)；
(2)交換機在隊列擁塞的情況下收到該報文，將ECN 字段修改為11 並轉發出去；轉發路徑上存在擁塞。
(3)接收服務器收到ECN 為11 的報文，就知道了來自某發送端的路徑上存在擁塞。
(4)接收端周期性的向轉發路徑上存在擁塞的Sender發送CNP（Congestion Notification Packets）報文，就是要求該Sender慢點發。ECN字段為01。
如何判定存在擁塞？要看緩沖區的水位的配置。
(5)交換機收到CNP 報文后正常轉發該報文；
(6)發送服務器收到ECN 標記為01 的CNP 報文解析后對相應的數據流限速算法，目前主流的流控算法是DC-QCN。
（4.4）無法避免的微突發，瞬間多打一，
對於分布式系統，在瞬間出現多打一的情況非常常見，比如大比例EC的讀操作，這個微突發擁塞往往集中在不到1個ms之內就會結束。因此ECN的擁塞處理一直慢半拍。ECN可以保證不會在一個瓶頸點出現持續的擁塞，但對瞬間的微突發作用有限。
（4.5）業界對RoCE的不滿和無損網絡的改進思路
顯然，業界認為RoCE（尤其是對PFC）是有待改進的。否則SIGCOMM會議也不會連續5年(2015-2019)，每年都有討論如何改進RoCE的論文了。
（a）Mellanox自己提出的備選方案：Resilient RoCE
壓低ECN/CNP的水線，更低的水位就可以觸發CNP降速，但不配置端口級的PFC流控。該思路其實已經是容損網絡了，該配置會導致性能大幅度降低，喪失了RoCE的傳統優勢。
（b）阿里巴巴提出的HPCC
Sigcomm2019：High Precision Congestion Control（HPCC）
其設計思路是仍然遵循RoCE要求網絡不許丟包這一原則，用可編程的白牌交換機，把整個網絡從網卡到交換機，端到端的管理起來。
通過智能網卡與交換機的配合，端到端實時抓取擁塞信息，從而精確獲取實時的鏈路負載，並且根據精確的鏈路負載來計算合適的發送速率。
如圖所示，發送方發送的每個數據包將由接收方確認。在從發送器到接收器的數據包傳播過程中，沿路徑的每個交換機利用其INT功能來插入一些數據，這些數據報告了包括時間戳（ts），隊列長度（qLen），發送字節數（tx字節）和鏈路帶寬容量（B）的信息。當接收方獲取數據包時，它會將記錄的所有元數據復制到ACK消息中發送回發送方。每次收到帶有網絡負載信息的ACK時，發送方決定如何調整其流速。
顯然：HPCC的思路仍然是全網更緊密的配合，以達到“網絡不丟包”的目的，HPCC的交換機與網卡的耦合加深了。
（4.6）我對RoCE的設計思路的看法
靠全網的緊密配合來應對局部風險，一點擁塞，多點流控。其后果是任何局部風險，一旦處理失敗，就可能上升為系統性風險。
其實分布式系統能容忍任何一個局部的徹底故障，但不能容忍整個網絡在同一時間一起流控。當局部出現問題時，及時隔離有問題的局部，避免局部拖累整體才是有韌性的設計思路。
最后回答開篇提出的第二個問題：RoCE“不允許網絡丟包”這種要求合理嗎？
我認為：
如果在封閉內網內，如果集群規模也不大，那無損網絡的要求就是合理的。
如果在開放網絡上，尤其是跨地域的通信，那無損網絡的要求就不現實。
因此，RoCE雖然風險不少，但是在高性能的封閉內網中仍將占據一定位置。