QoS in RoCE
首頁分類標簽留言關於訂閱2018-03-22 | 分類 Network |
Overview
TCP/IP協議棧滿足不了現代IDC工作負載(workloads)的需求，主要有2個原因：(1)內核處理收發包需要消耗大量的CPU；(2)TCP不能滿足應用對低延遲的需求：一方面，內核協議棧會帶來數十ms的延遲；另一方面，TCP的擁塞控制算法、超時重傳機制都會增加延遲。
RDMA在NIC內部實現傳輸協議，所以沒有第一個問題；同時，通過zero-copy、kernel bypass避免了內核層面的延遲。
與TCP不同的是，RDMA需要一個無損(lossless)的網絡。例如，交換機不能因為緩沖區溢出而丟包。為此，RoCE使用PFC(Priority-based Flow Control)帶進行流控。一旦交換機的port的接收隊列超過一定閥值(shreshold)時，就會向對端發送PFC pause frame，通知發送端停止繼續發包。一旦接收隊列低於另一個閥值時，就會發送一個pause with zero duration，通知發送端恢復發包。
PFC對數據流進行分類(class)，不同種類的數據流設置不同的優先級。比如將RoCE的數據流和TCP/IP等其它數據流設置不同的優先級。詳細參考Considerations for Global Pause, PFC and QoS with Mellanox Switches and Adapters
Network Flow Classification
對於IP/Ethernet，有2種方式對網絡流量分類：
- By using PCP bits on the VLAN header
- By using DSCP bits on the IP header
詳細介紹參考Understanding QoS Configuration for RoCE。
Traffic Control Mechanisms
對於RoCE，有2個機制用於流控：Flow Control (PFC)和Congestion Control (DCQCN)，這兩個機制可以同時，也可以分開工作。
- Flow Control (PFC)
PFC是一個鏈路層協議，只能針對port進行流控，粒度較粗。一旦發生擁塞，會導致整個端口停止pause。這是不合理的，參考Understanding RoCEv2 Congestion Management。為此，RoCE引入Congestion Control。
- Congestion Control (DCQCN)
DC-QCN是RoCE使用的擁塞控制協議，它基於Explicit Congestion Notification (ECN)。后面會詳細介紹。
PFC
前面介紹有2種方式對網絡流量進行分類，所以，PFC也有2種實現。
VLAN-based PFC
- VLAN tag
基於VLAN tag的Priority code point (PCP，3-bits)定義了8個Priority.
- VLAN-based PFC
In case of L2 network, PFC uses the priority bits within the VLAN tag (IEEE 802.1p) to differentiate up to eight types of flows that can be subject to flow control (each one independently).
- RoCE with VLAN-based PFC
HowTo Run RoCE and TCP over L2 Enabled with PFC.
## 將skb prio 0~7 映射到vlan prio 3
for i in {0..7}; do ip link set dev eth1.100 type vlan egress-qos-map $i:3 ; done
## enable PFC on TC3
mlnx_qos -i eth1 -f 0,0,0,1,0,0,0,0
例如：
[root@node1 ~]# cat /proc/net/vlan/eth1.100
eth1.100 VID: 100 REORDER_HDR: 1 dev->priv_flags: 1001
total frames received 0
total bytes received 0
Broadcast/Multicast Rcvd 0
total frames transmitted 0
total bytes transmitted 0
Device: eth1
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings:
[root@node1 ~]# for i in {0..7}; do ip link set dev eth1.100 type vlan egress-qos-map $i:3 ; done
[root@node1 ~]# cat /proc/net/vlan/eth1.100
eth1.100 VID: 100 REORDER_HDR: 1 dev->priv_flags: 1001
total frames received 0
total bytes received 0
Broadcast/Multicast Rcvd 0
total frames transmitted 0
total bytes transmitted 0
Device: eth1
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings: 0:3 1:3 2:3 3:3 4:3 5:3 6:3 7:3
參考HowTo Set Egress Priority VLAN on Linux.
- 問題
基於VLAN的PFC機制有2個主要問題：(1)交換機需要工作在trunk模式；(2)沒有標准的方式實現VLAN PCP跨L3網絡傳輸(VLAN是一個L2協議)。
DSCP-based PFC通過使用IP頭部的DSCP字段解決了上面2個問題。
DSCP-based PFC
DSCP-based PFC requires both NICs and switches to classify and queue packets based on the DSCP value instead of the VLAN tag.
- DSCP vs TOS
The type of service (ToS) field in the IPv4 header has had various purposes over the years, and has been defined in different ways by five RFCs.[1] The modern redefinition of the ToS field is a six-bit Differentiated Services Code Point (DSCP) field[2] and a two-bit Explicit Congestion Notification (ECN) field.[3] While Differentiated Services is somewhat backwards compatible with ToS, ECN is not.
詳細介紹參考：
PFC機制的一些問題
RDMA的PFC機制可能會導致一些問題：
- RDMA transport livelock
盡管PFC可以避免buffer overflow導致的丟包，但是，其它一些原因，比如FCS錯誤，也可能導致網絡丟包。RDMA的go-back-0算法，每次出現丟包，都會導致整個message的所有packet都會重傳，從而導致livelock。TCP有SACK算法，由於RDMA傳輸層在NIC實現，受限於硬件資源，NIC很難實現SACK算法。可以使用go-back-N算法來避免這個問題。
- PFC Deadlock
當PFC機制與Ethernet的廣播機制工作時，可能導致出現PFC Deadlock。簡單來說，就是PFC機制會導致相應的port停止發包，而Ethernet的廣播包可能引起新的PFC pause依賴（比如port對端的server down掉)，從而引起循環依賴。廣播和多播對於loseless是非常危險的，建議不要將其歸於loseless classes。
- NIC PFC pause frame storm
由於PFC pause是傳遞的，所以很容器引起pause frame storm。比如，NIC因為bug導致接收緩沖區填滿，NIC會一直對外發送pause frame。需要在NIC端和交換機端使用watchdog機制來防止pause storm。
- The Slow-receiver symptom
由於NIC的資源有限，它將大部分數據結構，比如QPC(Queue Pair Context) 和WQE (Work Queue Element)都放在host memory。而NIC只會緩存部分數據對象，一旦出現cache miss，NIC的處理速度就會下降。
ECN
ECN with TCP/IP
ECN是一個端到端的擁塞通知機制，而不需要丟包。ECN是可選的特性，它需要端點開啟ECN支持，同時底層的網絡也需要支持。
傳統的TCP/IP網絡，通過丟包來表明網絡擁塞，router/switch/server都會這么做。而對於支持ECN的路由器，當發生網絡擁塞時，會設置IP頭部的ECN(2bits)標志位，而接收端會給發送端返回擁塞的通知(echo of the congestion indication)，然后發送端降低發送速率。
由於發送速率由傳輸層(TCP)控制，所以，ECN需要TCP和IP層同時配合。
rfc3168定義了ECN for TCP/IP。
ECN with IP
IP頭部有2個bit的ECN標志位：
- 00 – Non ECN-Capable Transport, Non-ECT
- 10 – ECN Capable Transport, ECT(0)
- 01 – ECN Capable Transport, ECT(1)
- 11 – Congestion Encountered, CE.
如果端點支持ECN，就數據包中的標志位設置為ECT(0)或者ECT(1)。
ECN with TCP
為了支持ECN，TCP使用了TCP頭部的3個標志位：Nonce Sum (NS)，ECN-Echo (ECE)和Congestion Window Reduced (CWR)。
ECN in RoCEv2
RoCEv2引入了ECN機制來實現擁塞控制，即RoCEv2 Congestion Management (RCM)。通過RCM，一旦網絡發生擁塞，就會通知發送端降低發送速率。與TCP類似，RoCEv2使用傳輸層頭部Base Transport Header (BTH)的FECN標志位來標識擁塞。
實現RCM的RoCEv2 HCAs必須遵循下面的規則：
(1) 如果收到IP.ECN為11的包，HCA生成一個RoCEv2 CNP(Congestion Notification Packet)包，返回給發送端； (2) 如果收到RoCEv2 CNP包，則降低對應QP的發送速率； (3) 從上一次收到RoCEv2 CNP后，經過配置的時間或者字節數，HCA可以增加對應QP的發送速率。
- RCM的一些術語
| Term | Description |
|---|---|
| RP (Injector) | Reaction Point - the end node that performs rate limitation to prevent congestion |
| NP | Notification Point - the end node that receives the packets from the injector and sends back notifications to the injector for indications regarding the congestion situation |
| CP | Congestion Point - the switch queue in which congestion happens |
| CNP | The RoCEv2 Congestion Notification Packet - The notification message an NP sends to the RP when it receives CE marked packets. |
- RoCEv2的ECN示例
- ECN的配置
Refs
一些關於PFC的文獻
- RDMA over Commodity Ethernet at Scale
- Network Considerations for Global Pause, PFC and QoS with Mellanox Switches and Adapters
- Understanding QoS Configuration for RoCE
- HowTo Run RoCE and TCP over L2 Enabled with PFC
- Revisiting Network Support for RDMA
- RoCE v2 Considerations