RoCE网络
什么是RDMA
RDMA(远程直接数据存取)就是为了解决网络传输中服务器端数据处理的延迟而产生的，无需使用CPU，就可以从一个主机或服务器的内存直接访问另一主机或服务器的内存。它释放了CPU去执行其应做的工作，比如运行应用程序和处理大量数据。这既提高了带宽又降低了延迟、抖动和 CPU 消耗。
RDMA与TCP/IP模式示意图。对比传统的网络传输机制，RDMA无需操作系统和TCP/IP协议栈的介入。RDMA的内核旁路机制，允许应用与网卡之间的直接数据读写，将服务器内的数据传输时延降低到1us以下。同时，RDMA的内存零拷贝机制，允许接收端直接从发送端的内存读取数据，极大的减少了CPU的负担，提升CPU的效率。
RDMA 网络类型
目前，大致有三类RDMA网络，分别是Infiniband、RoCE、iWARP。其中，Infiniband是一种专为RDMA设计的网络，从硬件级别保证可靠传输 ，而RoCE 和 iWARP都是基于以太网的RDMA技术，支持相应的verbs接口。
InfiniBand
InfiniBand（直译为“无限带宽”技术，缩写为IB）是一个用于高性能计算的计算机网络通信标准，它具有极高的吞吐量和极低的延迟，用于计算机与计算机之间的数据互连。InfiniBand也用作服务器与存储系统之间的直接或交换互连，以及存储系统之间的互连。
该方案重新设计了物理链路层、网络层、传输层，是RDMA最初的部署方案，所以要使用专用的InfiniBand交换机做物理隔离的专网，成本较大，但性能表现最优。
iWARP
该方案的目的是让主流的以太网支持RDMA，将InfiniBand移植到TCP/IP协议栈，使用TCP协议保证无丢包，但缺点在于TCP开销较大，相比RoCE，在大型组网的情况下，iWARP的大量TCP连接会占用大量的额内存资源，对系统规格要求更高。另外，RoCE支持组播，而iWARP还没有相关的标准定义。
RoCE
RoCE(RDMA over Converged Ethernet )，是在InfiniBand Trade Association(IBTA)标准中定义的网络协议，允许通过以太网络使用RDMA。
该方案的目的也是让主流的以太网支持RDMA。网络侧使用PFC保证拥塞时不丢包，网卡侧又使用DCQCN的拥塞控制算法进一步减缓拥塞（该拥塞算法需要网络侧支持ECN标记），传统的以太网经过PFC和ECN的加持进化成为无损以太网，在无损以太网上运行RDMA性能大大增强。简而言之，它可以看作是RDMA技术在超融合数据中心、云、存储和虚拟化环境中的应用。
RoCE版本
RoCEv2版本已经是现在的主流版本，RoCEv1版本已很少提及了。
最初由IBTA实施和标准化，RoCE被设想为2层协议。实际上，IBTA第1层和第2层字段被相应的以太网字段替换。具体而言，在2层LRH由以太网MAC报头和帧检查序列替换。EtherType字段表示有效负载封装了RoCE协议，该协议在2层之上实现IBTA协议。此外，IBTA网络管理（子网管理器）由标准以太网2层管理协议取代。
这种方法的优点是易于实现、严格分层，并保留位于通道接口之上的应用层API；缺点是2层以太网部署的可扩展性限制，这是由广播域和跨子网的IP分配约束的复杂性造成的。此外，与普通IP数据包相比，某些交换机可能在较慢的异常路径上转发RoCE数据包。这些限制促使RoCE在第3层（可路由）环境中运行。幸运的是，RoCE框架的一个简单扩展允许它在3层网络上轻松传输。
如下图所示，支持3层的RoCE协议只是继续向上堆栈，并用标准IP网络头替换可选的L3全局路由头（GRH），并添加UDP头作为第4层有效负载的无状态封装。这是RoCE的一个非常自然的扩展，因为3层头已经基于IP地址，因此这种替换非常简单。此外，UDP封装是L4数据包的标准类型，是当前主流的数据层面的封装，路由器可以高效地转发。
简言之，当前RDMA在以太网上的传输协议是RoCEv2，RoCEv2是基于无连接协议的UDP协议
RoCE优势
- 低CPU占用率：访问远程交换机或服务器的内存，无需消耗远程服务器上的CPU周期，从而可以充分利用可用带宽和更高的可伸缩性。
- 零复制：向远程缓冲区发送数据和接收数据。
- 高效：由于RoCE改善了延迟和吞吐量，网络性能得到了很大提高。
- 节省成本：借助RoCE，无需购买新设备或更换以太网基础设施即可处理大量数据，从而大大节省了公司的资本支出。
RoCEv2网络关键点
要想发挥出RDMA真正的性能，突破数据中心大规模分布式系统的网络性能瓶颈，势必要为RDMA搭建一套不丢包的无损网络环境，而实现不丢包的关键就是解决网络拥塞。
为什么会产生拥塞
1. 收敛比
进行数据中心网络架构设计时，从成本和收益两方面来考虑，多数会采取非对称带宽设计，即上下行链路带宽不一致，交换机的收敛比简单说就是总的输入带宽除以总的输出带宽。
也就是说，当下联的服务器上行发包总速率超过上行链路总带宽时，就会在上行口出现拥塞。
2. ECMP
当前数据中心网络多采用Fabric架构，并采用ECMP来构建多条等价负载均衡的链路，通过设置扰动因子并HASH选择一条链路来转发是简单的，但这个过程中却没有考虑到所选链路本身是否有拥塞。ECMP并没有拥塞感知的机制，只是将流分散到不同的链路上转发，对于已经产生拥塞的链路来说，很可能加剧链路的拥塞。
3. TCP Incast
TCP Incast是Many-to-One的通信模式，在数据中心云化的大趋势下这种通信模式常常发生，尤其是那些以Scale-Out方式实现的分布式存储和计算应用，包括Hadoop、MapReduce、HDFS等。
例如，当一个Parent Server向一组节点(服务器集群或存储集群)发起一个请求时，集群中的节点都会同时收到该请求，并且几乎同时做出响应，同时向一台机器(Parent Server)发送TCP数据流，从而产生了一个“微突发流”，使得交换机上连接Parent Server的出端口缓存不足，造成拥塞。
正如前面所说，RDMA和TCP不同，它需要一个无损网络。对于普通的微突发流量，交换机的Buffer缓冲区可以起到一定作用，在缓冲区将突发的报文进行列队等待，但由于增加交换机Buffer容量的成本非常高，所以它所能起到的作用是有限的，一旦缓冲区列队的报文过多，仍旧会产生丢包。
为了实现端到端的无损转发，避免因为交换机中的Buffer缓冲区溢出而引发的数据包丢失，交换机必须引入其他机制，如：
- 流量控制
- QoS
- 拥塞控制
流量控制
Pause帧
Pause帧机制是Ethernet (802.3)的一个标准，在以太网链路的点到点邻接，接收者发送Pause帧让发送者停止发送数据，以保护缓存溢出、丢包。Pause帧在很多场景会有问题，所以不建议使用。
例如，H-J链路承载了F-G和X-Y的流量，如果A-F都发送流量到G，导致G被打满（但H-J还有充足带宽）那么SW1向SW2发送Pause帧，减少了H-J的流量势必会影响到X-Y的流量。这就是个问题了。
另外在超融合网络里，FCoE和LAN流量共享一条链路，存储阵列发送的Pause也会使LAN的流量停止。这也是个问题。
PFC(802.1Qbb)
PFC是Pause帧的一个扩展，暂停帧包含802.1p优先级的8位掩码，可以针对某一个队列发送Pause帧。
水线
在博通的XGS系列芯片中，有一块缓存管理单元MMU（简称缓存），存放已收到但没转发走的报文，并给入口和出口都计数：“0/1的入口和0/2的出口，都用了1个cell”（cell是缓存资源的最小单位）。
缓存会给每个入口和出口设置一个上限，超过这个上限就不能再使用cell缓存报文了。上限以下还画了很多其它的水线，同时对每一个出口和入口进行进一步细分，可以按照队列进行统计限额其中入方向。入方向上，细分了PG-Guaranteed大小、PG-Share大小、Headroom大小；出方向上，细分了Queue-Guaranteed大小，Queue-Share大小（如下图所示，这里我们不考虑端口，只考虑队列）。
►PG-Guaranteed和Queue-Guaranteed是保证缓存，这部分是独享的，即使不用，别的队列也不能抢占使用。
►PG-Share和Queue-Share使用的是共享缓存，因为动态水线的缘故，它们的大小不固定，如果很多队列都在用，那平分一下，每个队列的水线就都很小。另外，PG-Share还有另一个重要的作用：PFC发送的临界点，也称为xoff水线，只要到达该水线，PFC就会从这个口发出去，回落一些后，才恢复正常。在无损队列中，我们希望在缓存丢包前，能触发PFC进行反压，所以在任何情况下，都应该入口PG-Share先到达水线，出口Queue-Share永远不能到达水线（PG-Share到达会发PFC，Queue-Share到达会丢包）。
►Headroom是一个特殊的水线，只有在无损队列中才能发挥其作用。设想一下，PFC发出去以后，流量真的能瞬间停下来么？答案是不能的！因为线缆中还有一部分数据，而且七七八八的转发处理时间也要算进去。所以Headroom空间就是用来做这个的。
死锁
死锁产生的一个必要条件是CBD（环状缓存依赖），在数据中心典型的CLOS组网中，稳定状态下不会存在CBD，也没有死锁风险。
死锁问题解决的三种方法：
- 针对各种微环路场景，通过设计网络协议，控制收敛的现先后关系，避免出现微环路出现。
- 对于其它未知的死锁风险，使用交换机的死锁检测功能，释放缓存（释放缓存会产生丢包，但收敛过程本身就有乱序/丢包情况）。
- 将PG-Share的水线适当拉高，尽量使用DCQCN拥塞控制来压制流量。
QoS
1. 流分类
一般在网络边缘设备（如：TOR）根据数据包特征打上相应标记（如：DSCP），
在网络中的设备，信任标记，入相应队列。
2. 队列调度
出方向一般可以采用SP+WRR的队列调度模式，如图：
信令类绝对优先，直到队列为空，才开始转发其它队列；
RoCE类和普通流量加权轮询。
3. QoS和PFC的使用
使用QoS时不强制使用PFC。可能存在具有多个流量类别的网络，这些流量类别中没有一个需要无损(loss-less)特性
当网络中不启用QoS，交换机只有一个进方向缓存。当使用QoS，交换机会按流量分类生成多个进方向缓存。
如下图：
一般网络中有多个流量类别，则应启用QoS，为每个流量类别提供不同的服务。
例如，如果优先级3映射到TC1，并且我们在这个优先级上运行RDMA应用程序，我们希望TC1是无损的（TC1缓冲区上没有丢弃）。因此，我们将在优先级3上启用PFC。
拥塞控制
ECN
网络中间的交换机必须支持ECN功能。
在DSCP的后两位做ECN，Not-ECT “00”表示不支持ECT（ECN-capable Transport）；CE“11”表示发生拥塞；ECT(1)“01”一般是发送端设置，ECT(0)“10”一般是接收端设置（两者也可以互换，也就是“10”在发送端设置，“01”在接收端设置）。其实ECT(0)和ECT(1)两个编码就是一个互相验证的机制。
拥塞控制流程
RoCE拥塞控制流程图：
1 发送端必须设置ECN，ECT标记为10；
2 RoCEv2报文进入网络设备，当然网络设备必须也支持ECN；
3 网络设备在拥塞的情况下会检查ECN位，并开启CE bit（11），而不是直接丢包；
4 报文从网络设备到接收端时，ECN为11
5 接收端会对开启CE位的RoCE的报文过滤，触发事件然后做正常流处理；
6-7 接收端针对每个QP（Queue Pair）产生的拥塞做汇聚，在几微秒内将一个CN（Congestion
Notification）报文发给发送端。报文ECN设置为01；
8 接收端到网络设备的CNP报文；
9 CNP报文封在UDP里，网络设备在处理CNP报文和普通IP报文一样；
10 发送端收到CNP报文并过滤ECN 01，然后对相应流做相应算法限制速率。
简单总结：发送方叫Reaction Point，简称RP；接收方叫Notification Point，简称NP；中间交换机叫 Congestion Point，简称CP。发送方（RP）以最高速开始发送，沿途过程中如果有拥塞，会被标记ECN显示拥塞，当这个被标记的报文转发到接收方（NP）的时候，接收方（NP）会回应一个CNP报文，通知发送方（RP）。收到CNP报文的发送方（RP），就会开始降速。当发送方没有收到CNP报文时，就开始又提速了。
DCQCN
RoCE使用的拥塞控制算法是DCQCN非常复杂，《Congestion Control for Large-Scale RDMA Deployments》这篇论文很详细地描述了该算法。DCQCN算法中，对RP、NP和CP都有很多参数可以调节。
参考：
https://www.sohu.com/a/258041228_100289134
https://zhuanlan.zhihu.com/p/103231705
https://community.mellanox.com/s/article/roce-v2-considerations#jive_content_id_What_is_RoCE
https://community.mellanox.com/s/article/understanding-rocev2-congestion-management
https://community.mellanox.com/s/article/network-considerations-for-global-pause–pfc-and-qos-with-mellanox-switches-and-adapters