DCQCN：Congestion Control for Large-Scale RDMA Deployments 来源简书，我觉得写的很好

PFC是基于端口（每个端口有8条虚拟优先级链路）的，不能区分流，容易造成拥塞扩散的现象，降低吞吐量。

设计DCQCN的必要性：TCP/IP协议栈不能提供超低时延和超低CPU开销；目前PFC方案的弊端；以及解决方案的弊端
（1）测量比较TCP与RDMA的吞吐量、时延和CPU利用率
方案：TCP：修改iperf，开启LSO，RSS，使用16条线程，零拷贝操作 RDMA：使用自定义的工具测试IB read操作传送数据，一条线程占满一条链路。

（2）PFC的限制和弊端
PFC：通过监控ingress queue以及向上一跳发送PAUSE帧的方式避免交换机缓冲区和NIC缓冲区出现缓存溢出，从而避免丢包。

问题：PFC是针对端口和优先级进行流控的，不能识别流，会造成HOL问题，对单条流性能造成影响。不公平性。级联性。

解决方案：添加8条优先级。但随着发送端数量的增多，网络规模的扩大，可扩展性不高。并且处于同一优先级的不同流仍会遭受HOL问题。

（3）PFC改进方案的不足之处
改进方案：使用流级拥塞控制机制。

QCN：二层流控机制。依据mac地址和流id确定某条流，根据排队长度依概率判定是否拥塞，向发送该拥塞报文的源端发送拥塞通知。源端在周期内若收到拥塞通知，则降低发送速率，否则增加发送速率。

问题：QCN是通过二层mac地址标识流的，在IP网络中不可行，mac地址会变，交换机不知道该向谁发送拥塞通知包。

解决方案：扩展QCN支持三层流控。需要做的是修改NIC和交换机以支持用五元组标识流。修改交换机需要修改ASIC芯片，周期长，可实现性低。

缓存区设置：Tflight，Tpfc，Tecn
需求：PFC的触发要晚于ECN，早于缓存溢出，避免丢包和吞吐量下降

讨论的前提：交换机为共享缓存模式，有32个全双工的40Gbps端口，12MB的共享内存，支持PFC的8条优先级队列

Tflight：用于存储PAUSE包发送时和生效时到达的数据包的内存大小。根据BDP，每个端口，每个优先级所需要的内存空间为22.4KB。

Tpfc：可理解为触发PFC的ingress 队列中可以占用的最大内存区域。每个端口的每个优先级队列的Tpfc值要小于等于24.47KB。而触发PFC的条件一定要比它小。当队列内存占用降低到Tpfc减去两个MTU的值时，会自动发送RESUME信号，恢复发包。

Tecn：触发ECN标记的最小egress queue占用的内存空间。该值的设置一定要使ECN先于PFC触发。最坏情况下，所有的egress queue的包都来自于同一条ingress queue，为保证ecn先于pfc触发，则Tecn应小于0.85KB，小于一个MTU长度，不可行。这种想法过于静态，由于交换机内缓存资源是共享的，所以Tpfc的设置应取决于剩余的可用资源。如下公式：

S为所有egress队列占用的缓存资源，此公式为是交换机依赖的
在最坏情况下的Tecn经过放缩后的结果

作者：JennyLQ
链接：https://www.jianshu.com/p/44dd54142f46
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。