【RDMA】RDMA流控|RDMA对于网络的诉求
目录
bandaoyu,本文随时更新，连接：http://t.csdn.cn/TNdBb
前言
推荐配合下文阅读：
《无损网络和PFC（基于优先级的流量控制）|ECN》 ： https://blog.csdn.net/bandaoyu/article/details/115346857
RDMA对于网络的诉求
对于支撑端到端传输的基础网络而言，低延时（微秒级）、无损（lossless）则是最重要的指标。
- 低延时
网络转发延时主要产生在设备节点（这里忽略了光电传输延时和数据串行延时），设备转发延时包括以下三部分：
存储转发延时：芯片转发流水线处理延迟，每个hop会产生1微秒左右的芯片处理延时（业界也有尝试使用cut-through模式，单跳延迟可以降低到0.3微秒左右）；
Buffer缓存延时：当网络拥塞时，报文会被缓存起来等待转发。这时Buffer越大，缓存报文的时间就越长，产生的时延也会更高。对于RDMA网络，Buffer并不是越大越好，需要合理选择；
重传延时：在RDMA网络里会有其他技术确保不丢包，这部分不做分析。
- 无损
RDMA在无损状态下可以满速率传输，而一旦发生丢包重传，性能会急剧下降。在传统网络模式下，要想实现不丢包最主要的手段就是依赖大缓存，但如前文所说，这又与低延时矛盾了。因此，在RDMA网络环境中，需要实现的是较小Buffer下的不丢包。
在这个限制条件下，RDMA实现无损主要是依赖基于PFC和ECN的网络流控技术。
（为什么需要无损网络：长期以来，HPC（高性能计算）的RDMA都是在Infiniband集群中使用，数据包丢失在此类群集中很少见，因此RDMA Infiniband传输层（在NIC上实现）的重传机制很简陋，既：go-back-N重传，但是现在RDMA的使用更广泛，在其他网络中，丢包的概率大于Infiniband集群，一旦丢包，使用RDMA的go-back-N重传机制效率非常低，会大大降低RDMA的传输效率，所以要想发挥出RDMA真正的性能，势必要为RDMA搭建一套不丢包的无损网络环境，go-back-N重传，见2.1 Infiniband RDMA and RoCE：https://blog.csdn.net/bandaoyu/article/details/115620365）
RDMA无损网络的关键技术
1、PFC（通道）
PFC（Priority-based Flow Control），基于优先级的流量控制。是一种基于队列的反压机制，通过发送Pause帧通知上游设备暂停发包来防止缓存溢出丢包。
▲ PFC工作机制示意图
PFC允许单独暂停和重启其中任意一条虚拟通道，同时不影响其它虚拟通道的流量。如上图所示，当队列7的Buffer消耗达到设置的PFC流控水线，会触发PFC的反压：
- 本端交换机触发发出PFC Pause帧，并反向发送给上游设备；
- 收到Pause帧的上游设备会暂停该队列报文的发送，同时将报文缓存在Buffer中；
- 如果上游设备的Buffer也达到阈值，会继续触发Pause帧向上游反压；
- 最终通过降低该优先级队列的发送速率来避免数据丢包；
- 当Buffer占用降低到恢复水线时，会发送PFC解除报文。
• 保证缓存设置
保证缓存是一个静态水线（固定的、独享的）。静态水线的利用率非常低，资源消耗却非常大。我们在实际部署时建议不分配保证缓存，以减少这部分的缓存消耗。这样，入方向报文直接使用共享缓存空间，可提高Buffer的利用率。
• 共享缓存设置
对于共享缓存的设置，需要采用更为灵活的动态水线。动态水线能根据当前空闲的Buffer资源，以及当前队列已使用的Buffer资源数量来决定能否继续申请到资源。由于系统中空闲共享Buffer资源与已使用的Buffer资源都是时刻变化的，因此阈值也处于不断变动中。相对于静态水线，动态水线能更灵活、有效的利用Buffer及避免造成不必要的浪费。
锐捷网络交换机支持基于动态的方式进行Buffer资源的分配，对共享缓存的设置分为11档，动态水线alpha值=队列可申请缓存量/剩余共享缓存量。队列的α值越大，其在共享缓存中可使用的百分数占比也就越高。
▲共享水线α值与可使用率对应关系
我们不妨分析一下：
队列的α值设置越小，其最大可申请的共享缓存占比就越小。当端口拥塞时就会越早触发PFC流控，PFC流控生效后队列降速，可以很好地确保网络不丢包。
但从性能的角度看，过早触发PFC流控，会导致RDMA网络吞吐下降。因此我们在MMU水线设置时需要选取一个平衡值。
PFC水线到底设置多少，是一个非常复杂的问题，理论上不存在一个固定的值。实际部署时，需要我们具体分析业务模型，并搭建测试环境进行水线调优，找到匹配业务的最合适的水线。
• Headroom设置
Headroom：顾名思义，就是头部空间的意思，是在PFC触发后，到PFC真正生效这一段时间，用来缓存队列报文的。Headroom设置多大合适？这里与4个因素有关：
- PG检测到触发XOFF水线，到构造PFC帧发出的时间（这里主要跟配置的检测精度以及平均队列算法相关，固定配置是固定值）
- 上游收到PFC Pause帧，到停止队列转发的时间（主要跟芯片处理性能有关系，交换芯片实际上是固定值）
- PFC Pause帧在链路上的传输时间（跟AOC线缆/光纤距离成正比）
- 队列暂停发送后链路中报文的传输时间（跟AOC线缆/光纤距离成正比）
因此Headroom所需要的缓存大小，我们可以根据组网的架构，以及流量模型测算得出。以100米光纤线 + 100G光模块，缓存64字节小包，计算出所需的Headroom大小是408个cell（cell是缓存管理的最小单元，一个报文会占用1个或者多个cell），实际测试数据也吻合。当然，考虑一定的冗余性，Headroom设置建议比理论值稍大。
2、ECN（作用于主机与主机之间）
ECN（Explicit Congestion Notification）：显示拥塞通知。ECN是一个非常古老的技术，只是之前使用的并不普遍，该协议机制作用于主机与主机之间。
ECN是报文在网络设备（中间交换机？）出口（Egress port）发生拥塞并触发ECN水线时，使用IP报文头的ECN字段标记数据包，表明该报文遇到网络拥塞。一旦接收服务器发现报文的ECN被标记，立刻产生CNP（拥塞通知报文），并将它发送给源端服务器，CNP消息里包含了导致拥塞的Flow信息。源端服务器收到后，通过降低相应流发送速率，缓解网络设备拥塞，从而避免发生丢包。
PFC的水线设置
通过前面的描述可以了解到，PFC和ECN之所以可以实现网络端到端的零丢包，是通过设置不同的水线来实现的。对这些水线的合理设置，就是针对交换机MMU的精细化管理，通俗讲就是对交换机Buffer的管理。接下来我们具体分析下PFC的水线设置。
交换芯片都有固定的Pipeline（转发流水线）， Buffer管理处于入芯片流程和出芯片流程的中间位置。报文处于在这个位置上时，已经知道了该报文的入口和出口信息，因此逻辑上就可以分成入方向和出方向分别对缓存进行管理。
PFC水线是基于入方向缓存管理进行触发的。芯片在入口方向提供了8个队列，我们可以将不同优先级的业务报文映射到不同的队列上，从而实现对不同优先级的报文提供不同的Buffer分配方案。
具体到每个队列，其Buffer分配根据使用场景设计为3部分：保证缓存，共享缓存，Headroom。
- 保证缓存：每个队列的专用缓存，确保每个队列均有一定缓存以保证基本转发；
- 共享缓存：流量突发时可以申请使用的缓存，所有队列共享；
- Headroom：在触发PFC水线后，到服务器响应降速前，还可以继续使用的缓存。
RDMA网络实践
锐捷网络在研发中心搭建了模拟真实业务的RDMA网络，架构如下：
▲锐捷网络RDMA组网架构
- 组网模型：大核心三级组网架构，核心采用高密100G线卡；
- POD内：Spine采用提供64个100G接口的 BOX设备，Leaf采用提供48个25G接口+8个100G接口的BOX设备；
- Leaf作为服务器网关，支持和服务器间基于PFC流控（识别报文的DSCP并进行PG映射），同时支持拥塞ECN标记；
- RDMA仅运行于POD内部，不存在跨POD的RDMA流量，因此核心无需感知RDMA流量；
- 为了避免拥塞丢包，需要在Leaf与Spine之间部署PFC流控技术，同时Spine设备也需要支持基于拥塞的ECN标记；
- Leaf和Spine设备支持PFC流控帧统计、ECN标记统计、拥塞丢包统计、基于队列的拥塞统计等，并支持将统计信息通过gRPC同步到远端gRPC服务器。
写在最后
锐捷网络在研发中心搭建了模拟真实业务的浸泡组网环境（包括RG-S6510、RG-S6520、RG-N18000-X系列25G/100G网络设备、大型测试仪、25G服务器）。在叠加了多种业务模型，并进行了长时间浸泡测试后，我们对于RDMA网络的MMU水线设置已有一些推荐的经验值。此外，在RDMA网络中，还存在一些部署难点，比如多级网络中 PFC风暴、死锁问题、ECN水线设计复杂问题等。对于这些问题，锐捷网络也有一些研究和积累，期待与大家共同探讨。
本期作者：颜晓波（技术盛宴 | 浅析RDMA网络下MMU水线设置）
DC-QCN（数据中心拥塞控制）
网络工程师必会：
https://blog.csdn.net/bandaoyu/article/details/117436019
DC-TCP(面向数据中心的TCP协议)
【动机】数据中心对其网络有3个需求：1、短数据流低时延（因为短数据流往往是实时信息），2、对突发数据流高容忍性，3、长数据流高带宽利用率。基于对一个约6000台服务器构成的数据中心的流量测量，作者发现TCP协议造成了数据中心网络中短数据流的高时延，其深层原因是TCP对交换机缓存空间的消耗过大，导致长数据流（的大数据量）塞满了交换机的缓存，短数据流被迫排队等待。
【想法】作者设计了DCTCP：面向数据中心的TCP协议来解决上述问题。DCTCP只需要修改30行TCP代码、1个交换机参数，因此实现难度很低。DCTCP利用了交换机中新出现的显式拥塞通知（ECN）功能，将之与数据源端的控制策略相结合，从而保证交换机缓存空间的数据占据率始终低于某个阈值，这样短数据流就无需排队通过交换机，而长数据流的吞吐量同时较高。
【局限性】DCTCP利用了数据中心网的特殊属性，它并不期望应用到普通的广域网中（那里仍然是TCP的舞台）。此外，DCTCP利用了交换机中新出现的显式拥塞通知（ECN）功能，如果交换机不够新（在很多发展中或欠发达国家）那就没办法了。
