RoCEv2的傳輸壅塞管理

陳奕熹
陳奕熹
Oct 18 · 5 min read

主要擷取與翻譯自 <Understanding RoCEv2 Congestion Management> Mellanox Tech 在 2018年的文章

這篇文章主要提到現在數據中心主要用到的 RoCE v2傳輸協議,主要基於 UDP/IPv4 或是 UDP/IPv6 的傳輸層/網路層協議上,RoCE 全名是 RDMA over Converged Ethernet,也就是考慮阻塞狀況下的 RDMA 協議,而這邊提到的 RDMA 協議主要就是跳過一般作業系統的 TCP stack 需要 CPU 運算資源的參與,直接讓收到的封包寫入一段固定的記憶體區域


背景描述為什麼資料中心要採用 RDMA 而不用 TCP 的原因在下方相關論文研究的 Congestion Control for Large-Scale RDMA Deployments[1] 的摘要中有詳細解釋以及相關數據考量,簡單來說就是數據中心需要賺錢,每一筆算力都需要能夠賣,所以花費在建設的運算資源是越少越好,尤其是是這筆經費不能隨著使用者人數增長花費也線性增加,以 kernel TCP stack 來處理的話不僅需要 CPU 算力,速度還達不到數據中心要求的 40Mbps,因此需要 RDMA 的機制把收發封包的任務直接在週邊層級做完

同樣也是在 Congestion Control for Large-Scale RDMA Deployments 這篇文章裡的描述,原始版的 RDMA 底層事實上走得是 InfiniBand 的鏈接層協議,這個協議本身就有實做 lossless 機制,也就是 credit-based flow control (上游裝置在發送封包給下游裝置時,前提需要下游裝置先發給上游一個提示下游還有多少空位的確認封包)

但是後來目前當代的數據中心主要走的是 Ethernet 的鏈接層協議,所以才會出現 RoCE 用來解決 RDMA 的 lossless 網路前提,目前主流的方式是透過一個叫做 PFC (Priority-Based Flow Control) 的協定解決(不過去年 2018 Sigcomm 有一篇文章提出以另外一種方向,也就是下方第二篇參考論文 Revisiting network Support for RDMA[2]),PFC 在我的認知裡就是簡化過後的 credit-based flow control,上游這個時候在正常情況下不需要下游確認的條件,可以自由傳送封包,直到下游主動提醒上游下游沒有空間了,上游才會不繼續往這條連接傳送

這樣的機制的確達到了 lossless 的網路環境,但是也衍生出了很多問題,像是 head-of-line blocking (HoL Blocking),或是 congestion spreading 的問題,以下主要著重在 congestion spreading 的問題討論上


  1. 考慮以上的的網路連結關係,現在假設 A~E 這五個端口嘗試對端口 G 傳送封包,此時端口 G 的端口輸入的吞吐量已經被這五個輸入給塞滿了
  2. 現在在另外一個鄰居交換器上的端口 X 嘗試發送封包到交換器 1 的端口 G 上,這個傳輸需要 20% 的交換器間流量,也就是 20% 的 HJ 流量上限
  3. 此時 F — G 的傳輸可能會因為端口 G 的阻塞而被暫緩,但是這並不危險,一旦 G 處理完部份流量,f 的請求就會馬上被接受
  4. 現在考慮另外一個交換機 2 端口 X,它也想對交換機 1 上的端口 Y 傳送封包,同樣也需要 HJ 頻寬的 20% ,需要注意到的是 X—J 理論上不存在任何阻塞,但是由於 HJ 之間存在的 PFC 停止傳送的訊號,X — Y 傳送的訊息必須與原本已有的 F — G 競爭,無法利用剩下多餘的 80%
  5. 也就是說,這個壅塞現象擴散到其他其實並沒有壅塞的連接上

為了處理這個問題,於是我們有了偉大的 RFC 3168: Explicit Congestion Notification(ECN) [對於網路不太熟的朋友,RFC(Request for comment) 事實上就是網路協議的標準],而 RoCEv2 也實現了這樣的壅塞控制 (RoCEv2 Congestion Management, RCM),利用 ECN 這個 UDP flag 來標誌該連接已被壅塞,接收方看到這個 flag 被設定之後,必須通知發送端這個壅塞現象

同時,RCM 也會偵測如果有連接佔用了太大的流量,也會減緩該連接的傳輸速度,達到連接間的公平性


一些讀後的小問題

  1. 為什麼 RoCE 是基於 UDP ?
    最近越來越多的協議基於 UDP 上發展,像是 google 發展的 QUIC 就是基於 UDP 的應用層協定,我不太理解的是,為什麼 RoCE 無法基於像是 TCP 這樣的協議發展,不過 TCP 本身有所謂的重傳機制對應丟包問題,這個可能在 lossless 條件下相性不太好,同時 RDMA 這樣的機制是需要硬體的配合的,複雜的硬體設計硬體製造商可能不會埋單(需要例子也可以參考第二篇相關文章,裡面有提到 iWarp 嘗試在硬體裡面實現 TCP stack 結果硬體商沒人理它)
  2. PFC 造成的壅塞 ?
    由於像是 credit-based flow control 或是 priority-based flow control 又或是 ECN 都有需要送出額外的封包,尤其是在壅塞的時候需要通知上游不要在送過來了,像這樣主動發出確認封包的行為有沒有可能導致壅塞在上下由網路間擴散開來,尤其萬一是半雙工網路的話上下游的流量還會互相影響 ?

相關的論文研究:

[1] Yibo Zhu et al, Congestion Control for Large-Scale RDMA Deployments, Sigcomm, 2015

[2] Mittal Radhika et al, Revisiting network Support for RDMA, Sigcomm, 2018

陳奕熹

Written by

陳奕熹

應該要是一個工程師的……

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade