Congestion Control for Large-Scale RDMA Deployments

本文主要是介绍Congestion Control for Large-Scale RDMA Deployments，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Introduction

PFC是粗粒度的流量控制机制，在端口层面发挥作用，不区别不同的流。这会导致很多弊端，比如不公平，受害流等。

解决PFC限制的解决方法是flow-level的拥塞控制，DCQCN就是一种RoCEv2上的end-to-end的拥塞控制协议。

DCQCN

DCQCN包括sender（reaction point, RP），switch（congestion point, CP），receiver（notification point，NP）。

CP算法：在switch上，使用以下的概率函数对数据包进行ECN标记。

NP算法：ECN标记的包到达NP（receiver），表示网络中出现了拥塞。NP发送CNP（Congestion Notification Packets）包，将这个信息传达给sender。对于一个流，如果一个标记的包到达，并且在之前的N微秒内没有CNP被发送，CNP就立即被发送。也就是说，对于每个流， 每N微秒最多发送1个CNP包。作者将N设置为$50\mu s$。

RP算法：当一个RP（sender）收到一个CNP时，它减少它的当前发送速率（$R_C$）并且更新速率降低因子（$\alpha$），最后记录当前的速率为之后恢复过程的目标速率（$R_T$）。

当RP每K个时间单元没收到反馈时，它就更新$\alpha$。注意K必须比CNP产生间隔要大。作者将K设置为$55\mu s$。
$$\alpha =(1-g)\alpha$$

而且，RP使用计时器和字节计数器增加发送速率。字节计数器每B字节增加一次速率，计时器每T个时间单元增加一次速率。计时器确保流能够快速恢复，即使在它的速率降到一个很低的值时。速率恢复包括两个主要的阶段，第一个阶段是fast recovery，执行如下的F=5轮迭代，以快速接近目标速率$R_T$：
$$R_C=(R_T+R_C)/2$$

fast recovery后面跟着additive increase，目标速率每次增加$R_{AI}$，当前速率缓慢地靠近目标速率：

状态机如下：

Buffer Setting

DCQCN需要平衡两个冲突的请求：

1. PFC不能触发得太早（不能在ECN发送拥塞反馈之前触发）
2. PFC不能触发得太晚（导致buffer overflow，造成包丢失）

Headroom buffer $t_{flight}$：发送到上游设备的PAUSE消息需要一段时间来到达和发挥作用。为了避免包丢失，PAUSE发送者需要保留足够的buffer空间，以处理这段时间内接收的包。这包括PAUSE被发送时in flight的包，以及上游设备处理PAUSE时发送的包。作者将每个端口，每个优先级的$t_{flight}$设为22.4KB。

PFC Threshold $t_{PFC}$：这是一个进入队列在PAUSE发送到上游设备之前，能够增长到的最大大小。在每个进入端口，每个PFC优先级都有它自己的队列。因此，如果switch buffer的总大小为B，有n个端口，需要遵守$t_{PFC}\le (B-8n{t}_{flight})/(8n)$。当队列降低到$t_{PFC}$以下两个MTU时，交换机发送RESUME消息。

ECN Threshold $t_{ECN}$：一旦外出队列超过这个阈值，交换机开始标记数据包（即上图中$K_{min}$）。为了使DCQCN有效，此阈值必须足够低，以使PFC阈值在交换机有机会用ECN标记数据包之前不会被触及。$t_{ECN}$是外出队列阈值，$t_{PFC}$是进入队列阈值。

在此基础想法上，作者设置了阈值的大小。

除此之外，作者在各种参数上进行了测试，从而选出最佳的参数大小。

这篇关于Congestion Control for Large-Scale RDMA Deployments的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---