https://www.cnblogs.com/bandaoyu/p/14624808.html
目錄
原文：《我們為什么需要RDMA？為什么需要無損網絡？》https://www.sohu.com/a/258041228_100289134
(Priority-based Flow Control，基於優先級的流量控制)
前言
RDMA技術：降低數據中心內部網絡延遲，提高處理效率。
當前RDMA在以太網上的傳輸協議是RoCEv2，RoCEv2是基於無連接協議的UDP協議，相比面向連接的TCP協議，UDP協議更加快速、占用CPU資源更少，但其不像TCP協議那樣有滑動窗口、確認應答等機制來實現可靠傳輸，一旦出現丟包，依靠上層應用檢查到了再做重傳，會大大降低RDMA的傳輸效率。
所以要想發揮出RDMA真正的性能，突破數據中心大規模分布式系統的網絡性能瓶頸，勢必要為RDMA搭建一套不丟包的無損網絡環境，而實現不丟包的關鍵就是解決網絡擁塞。
一、為什么會產生擁塞
產生擁塞的原因有很多，下面列舉了在數據中心場景里比較關鍵也是比較常見的三點原因：
1.收斂比
進行數據中心網絡架構設計時，從成本和收益兩方面來考慮，多數會采取非對稱帶寬設計，即上下行鏈路帶寬不一致，交換機的收斂比簡單說就是總的輸入帶寬除以總的輸出帶寬。
交換機A：下行帶寬480G，上行帶寬240G，整機收斂比為2:1
交換機B：下行帶寬1200G，上行帶寬800G，整機收斂比為1.5:1
也就是說，當下聯的服務器上行發包總速率超過上行鏈路總帶寬時，就會在上行口出現擁塞。
2.ECMP
當前數據中心網絡多采用Fabric架構，並采用ECMP來構建多條等價負載的鏈路，並HASH選擇一條鏈路來轉發，是簡單的，但這個過程沒有考慮到所選鏈路本身是否有擁塞，對於已經產生擁塞的鏈路來說，很可能加劇鏈路的擁塞。
3.TCP Incast
TCP Incast是Many-to-One（多對一）的通信模式，在數據中心雲化的大趨勢下這種通信模式常常發生，尤其是那些以Scale-Out方式實現的分布式存儲和計算應用，包括Hadoop、MapReduce、HDFS等。
例如，當一個Parent Server向一組節點(服務器集群或存儲集群)發起一個請求時，集群中的節點都會同時收到該請求，並且幾乎同時做出響應，很多節點同時向一台機器(Parent Server)發送TCP數據流，從而產生了一個“微突發流”，使得交換機上連接Parent Server的出端口緩存不足，造成擁塞。
TCP Incast流量模型
正如前面所說，RDMA和TCP不同，它需要一個無損網絡。對於普通的微突發流量，交換機的Buffer緩沖區可以起到一定作用，在緩沖區將突發的報文進行列隊等待，但由於增加交換機Buffer容量的成本非常高，所以它所能起到的作用是有限的，一旦緩沖區列隊的報文過多，仍舊會產生丟包。
為了實現端到端的無損轉發，避免因為交換機中的Buffer緩沖區溢出而引發的數據包丟失，交換機必須引入其他機制，如流量控制，通過對鏈路上流量的控制，減少對交換機Buffer的壓力，來規避丟包的產生。
二、PFC如何實現流控
IEEE 802.1Qbb(Priority-based Flow Control，基於優先級的流量控制)簡稱PFC，是流量控制的增強版。
說PFC之前，我們可以先看一下IEEE 802.3X(Flow Control)流控的機制：當接收者沒有能力處理接收到的報文時，為了防止報文被丟棄，接收者需要通知報文的發送者暫時停止發送報文。
如下圖所示，端口G0/1和G0/2以1Gbps速率轉發報文時，端口F0/1將發生擁塞。為避免報文丟失，開啟端口G0/1和G0/2的Flow Control功能。
端口產生擁塞的打流模型
當F0/1在轉發報文出現擁塞時，交換機B會在端口緩沖區中排隊報文，當擁塞超過一定閾值時，端口G0/2向G0/1發PAUSE幀，通知G0/1暫時停止發送報文。
• G0/1接收到PAUSE幀后暫時停止向G0/2發送報文。暫停時間長短信息由PAUSE幀所攜帶。交換機A會在這個超時范圍內等待，或者直到收到一個Timeout值為0的控制幀后再繼續發送。
IEEE 802.3X協議存在一個缺點：一旦鏈路被暫停，發送方就不能再發送任何數據包，如果是因為某些優先級較低的數據流引發的暫停，結果卻讓該鏈路上其他更高優先級的數據流也一起被暫停了，其實是得不償失的。
如下圖中報文解析所示，PFC在基礎流控IEEE 802.3X基礎上進行擴展，允許在一條以太網鏈路上創建8個虛擬通道，並為每條虛擬通道指定相應優先級，允許單獨暫停和重啟其中任意一條虛擬通道，同時允許其它虛擬通道的流量無中斷通過。
PFC協議報文結構解析
PFC將流控的粒度從物理端口細化到8個虛擬通道，分別對應Smart NIC硬件上的8個硬件發送隊列(這些隊列命名為Traffic Class，分別為TC0,TC1,...,TC7)，在RDMA不同的封裝協議下，也有不同的映射方式。
• RoCEv1：
這個協議是將RDMA數據段封裝到以太網數據段內，再加上以太網的頭部，因此屬於二層數據包。為了對它進行分類，只能使用VLAN(IEEE 802.1q)頭部中的PCP(Priority Code Point)域3 Bits來設置優先級值。
二層以太網幀VLAN頭部結構
RoCEv2：
這個協議是將RDMA數據段先封裝到UDP數據段內，加上UDP頭部，再加上IP頭部，最后再加上以太網頭部，屬於三層數據包。對它進行分類，既可以使用以太網VLAN中的PCP域，也可以使用IP頭部的DSCP域。
三層IP報文頭部結構
簡單來說，在二層網絡的情況下，PFC使用VLAN中的PCP位來對數據流進行區分，在三層網絡的情況下，PFC既可以使用PCP、也可以使用DSCP，使得不同數據流可以享受到獨立的流控制。當下數據中心因多采用三層網絡，因此使用DSCP比PCP更具有優勢。
三、PFC死鎖
雖然PFC能夠通過給不同隊列映射不同優先級來實現基於隊列的流控，但同時也引入了新的問題，例如PFC死鎖的問題。
PFC死鎖，是指當多個交換機之間因微環路等原因同時出現擁塞,各自端口緩存消耗超過閾值，而又相互等待對方釋放資源，從而導致所有交換機上的數據流都永久阻塞的一種網絡狀態。
正常情況下，當一台交換機的端口出現擁塞並觸發XOFF水線時，數據進入的方向(即下游設備)將發送PAUSE幀反壓，上游設備接收到PAUSE幀后停止發送數據，如果其本地端口緩存消耗超過閾值，則繼續向上游反壓。如此一級級反壓，直到網絡終端服務器在PAUSE幀中指定Pause Time內暫停發送數據，從而消除網絡節點因擁塞造成的丟包。
但在特殊情況下，例如發生鏈路故障或設備故障時，BGP路由重新收斂期間可能會出現短暫環路，會導致出現一個循環的緩沖區依賴。如下圖所示，當4台交換機都達到XOFF水線，都同時向對端發送PAUSE幀，這個時候該拓撲中所有交換機都處於停流狀態，由於PFC的反壓效應，整個網絡或部分網絡的吞吐量將變為零。
(BGP（Border Gateway Protocol，邊界網關協議）是用來連接Internet上的獨立系統的路由選擇協議。)
PFC死鎖示意圖
即使在無環網絡中形成短暫環路時，也可能發生死鎖。雖然經過修復短暫環路會很快消失，但它們造成的死鎖不是暫時的，即便重啟服務器中斷流量，死鎖也不能自動恢復。
為了解除死鎖狀態，一方面是要杜絕數據中心里的環路產生，另一方面則可以通過網絡設備的死鎖檢測功能來實現。銳捷RG-S6510-48VS8CQ上的Deadlock檢測功能，可以檢測到出現Deadlock狀態后的一段時間內，忽略收到的PFC幀，同時對buffer中的報文執行轉發或丟棄的操作(默認是轉發)。
例如，定時器的監控次數可配置設置檢測10次，每次10ms內檢測是否收到PFC Pause幀。若10次均收到則說明產生Deadlock，對buffer中的報文執行默認操作，之后將設置100ms作為Recover時間后恢復再檢測。命令如下：
priority-flow-control deadlock cos-value 5 detect 10 recover 100 //10次檢測，100ms recover。
RDMA無損網絡中利用PFC流控機制，實現了交換機端口緩存溢出前暫停對端流量，阻止了丟包現象發生，但因為需要一級一級反壓，效率較低，所以需要更高效的、端到端的流控能力。
四、利用ECN實現端到端的擁塞控制
當前的RoCE擁塞控制依賴ECN(Explicit Congestion Notification，顯式擁塞通知)來運行。ECN最初在RFC 3168中定義，網絡設備會在檢測到擁塞時，通過在IP頭部嵌入一個擁塞指示器和在TCP頭部嵌入一個擁塞確認實現。
(RFC:Request For Comments，縮寫為RFC，是由互聯網工程任務組（IETF）發布的一系列備忘錄。)
RoCEv2標准定義了RoCEv2擁塞管理(RCM)。啟用了ECN之后，網絡設備一旦檢測到RoCEv2流量出現了擁塞，會在數據包的IP頭部ECN域進行標記。
IP報文頭ECN字段結構
這個擁塞指示器被目的終端節點按照BTH(Base Transport Header，存在於IB數據段中)中的FECN擁塞指示標識來解釋意義。換句話說，當被ECN標記過的數據包到達它們原本要到達的目的地時，擁塞通知就會被反饋給源節點，源節點再通過對有問題的Queue Pairs(QP)進行網絡數據包的速率限制來回應擁塞通知。
ECN交互過程示意圖
五、ECN交互過程
① 發送端發送的IP報文標記支持ECN(10);
② 交換機在隊列擁塞情況下收到該報文，將ECN字段修改為11並發出，網絡中其他交換機將透傳;
③ 接收端收到ECN為11的報文發現擁塞，正常處理該報文;
④ 接收端產生擁塞通告，每ms級發送一個CNP(Congestion Notification Packets)報文，ECN字段為01，要求報文不能被網絡丟棄。接收端對多個被ECN標記為同一個QP的數據包發送一個單個CNP即可(格式規定見下圖);--（即對同一個QP的數據發送同一個CNP即可）
⑤ 交換機收到CNP報文后正常轉發該報文;
⑥ 發送端收到ECN標記為01的CNP報文解析后對相應的流(對應啟用ECN的QP)應用速率限制算法。
RoCEv2的CNP包格式如下：
CNP報文結構
值得注意的是，CNP作為擁塞控制報文，也會存在延遲和丟包，從發送端到接收端經過的每一跳設備、每一條鏈路都會有一定的延遲，會最終加大發送端接收到CNP的時間，而與此同時交換機端口下的擁塞也會逐步增多，若發送端不能及時降速，仍然可能造成丟包。建議擁塞通告域的規模不要過大，從而避免因為ECN控制報文交互回路的跳數過多，而影響發送端無法及時降速，造成擁塞。
總結
RDMA網絡正是通過在網絡中部署PFC和ECN功能來實現無損保障。PFC技術讓我們可以對鏈路上RDMA專屬隊列的流量進行控制，並在交換機入口(Ingress port)出現擁塞時對上游設備流量進行反壓。利用ECN技術我們可以實現端到端的擁塞控制，在交換機出口(Egress port)擁塞時，對數據包做ECN標記，並讓流量發送端降低發送速率。
從充分發揮網絡高性能轉發的角度，我們一般建議通過調整ECN和PFC的buffer水線，讓ECN快於PFC觸發，即網絡還是持續全速進行數據轉發，讓服務器主動降低發包速率。如果還不能解決問題，再通過PFC讓上游交換機暫停報文發送，雖然整網吞吐性能降低，但是不會產生丟包。
在數據中心網絡中應用RDMA，不僅要解決轉發面的無損網絡需求，還要關注精細化運維，才能應對延遲和丟包敏感的網絡環境