这篇文章发表在NSDI 2020会议上。笔者花了相当长的时间细读、理解透彻这篇论文（前前后后几个月哈哈）。笔者的笔记也包含了一些笔者自己的理解。这篇论文重构了目前无损以太网的拥塞控制，指出了当前拥塞管理架构中两个核心模块（拥塞探测和速率调节）存在的根本问题。提出了PCN的拥塞控制协议。
Experimental observations
论文作者通过构造一个经典场景，给出实验性的观察，指出了现有拥塞控制协议存在的根本问题。实验性的观察比单纯的说理更加具有说服力。
拓扑：拓扑的构造看似简单，本质上是CLOS网络单元的高度抽象，很多早期的拥塞控制论文构造的也是类似拓扑。图里的H0、H1、R0、R1都可以替换成一个pod的服务器。
流量：实验的流量是长短流混合，也是作者精巧设计的。F0和F1是长流，H2-H15持续地发送短流，短流的特点是由于长度小于网络的时延带宽乘积（BDP），当发送方被通知拥塞时，短流已经发送完毕，造成短流不被端到端拥塞控制所控制。这种突发性的流量在无损以太网中，只能靠逐跳的PFC所控制，而长流是由端到端拥塞控制所控制的。作者构造的实验，本质上是为了探究网络中突发流量对端到端拥塞控制的干扰。而目前已有的无损以太网拥塞控制，例如DCQCN和Timely，在只有长流的场景下，工作的效果是相似的（无非就是收敛快慢）。PCN就是从这一长短流混合的场景出发，揭示现有拥塞控制的问题。
揭示的问题：
-
PFC干扰拥塞探测与识别笔者认为揭示的这个问题是这篇论文最核心的贡献。在图中，F0的吞吐降低造成性能损失，原因就是拥塞从P2扩展到P0，扩展的标志就是PFC开始起作用，形成拥塞树。P0收到了PAUSE帧，造成P0队列累积。此时的队列累积并不是因为P0处发生了拥塞，P0是victim port。而在现有的拥塞控制协议均将队列长度作为拥塞信号，所以造成拥塞信号不准，端上的拥塞控制会误把F0当做造成拥塞的流进行降速。
-
逐步的端到端速率调节与逐跳的流控不匹配拥塞扩展的根本原因就是造成拥塞的流没有及时快速地减到合适的速率。换句话说，如果速率减的够快，就不会有拥塞扩展出现。无损以太网中，一个好的拥塞控制算法应当尽可能少的减少PFC的触发（可以阅读DCQCN中关于阈值设置的内容进行理解，同时注意DCQCN也说，它并不能保证PFC完全不触发）。本实验中，拥塞控制协议应当将F1快速减到正确的速率，但是由于现有算法的调节都是逐步的，而PFC是逐跳传播的，所以还是出现了从P1到P0的拥塞扩展。
-
增速过程不适应动态网络情况针对增速，论文指出现有协议的增速都是线性的，既慢又不灵活。
Design
针对三个问题，PCN有三个核心设计点：
-
准确探测congested flow （就是真正造成拥塞的流）
已有的拥塞控制算法，只根据队列长度来识别congested flow （Timely根据RTT，本质上也是队长），当网络中PFC没有被触发时，根据队长是准的，但是如果PFC被触发，端口队长累积既可能是因为这个端口就是拥塞发生的端口，也可能因为这个端口经历了拥塞扩展，被pause住导致到达的数据包累积。因此，PCN中对端口状态进行了划分，分成了三种，非拥塞、准拥塞以及真拥塞。重点是对准拥塞端口的理解。准拥塞的端口处于一个在不断收到PAUSE和RESUME帧的阶段，端口的输出速率小于线速，输入速率取决于流量。
交换机标记核心思想：
被PAUSE住的数据包不标
仅通过交换机标记是不够的，因为在连续的PAUSE RESUME之间的数据包仍可能会被标记。因此PCN将真正的拥塞识别放到接收端去做：
如果是真拥塞端口，真拥塞流的数据包一定会连续的被标记；准拥塞端口的数据包一定不被连续标记，根据这一特征，由接收端区分谁是真正的拥塞流
-
receiver-driven的减速，使congested flow直接减速到合适的速率
这里文章指出了，针对无损以太网，造成拥塞的流的正确速率就是它在接收方的接收速率。这一点需要好好理解。可以说，采用拥塞流的接收速率来指导减速是彻底的解决方法。最简单的例子就是多对一的incast场景。实际上复杂的场景下这个思想也是正确的。对任意一条拥塞流，它的接收速率就是能通过瓶颈的最大速率。
-
先缓慢后激进的增速策略
文章作者启发式设计了一个先缓慢后激进的增长函数
Thoughts
PCN这篇论文笔者认为是非常solid的工作，对拥塞控制架构的核心模块进行了彻底的改进，文章读起来让人觉得能学到很多内容。PCN的拥塞识别可以做到接近100%准确，对拥塞流的减速也可以在一个RTT内直接减到最合适的速率。从性能上笔者认为PCN已经将无损以太网的拥塞控制协议做的非常好了。
当然PCN最不足的问题是对交换机和接收端都进行了改动，特别是拥塞识别实际上需要交换机与接收端同时配合，拥塞流减速也完全需要接收端的配合，对部署要求高。
