LWN：关于TCP/IP网络拥塞改善方案的争论，以及专利风险

点击上方蓝色字关注我们~

Photo by Brett Sayles from Pexels

The congestion-notification conflict. By Jonathan Corbet. Mar 22, 2019.

通常IETF等组织中编写协议标准的这些繁杂工作并不为人所知。然而，最近关于拥塞通知（congestion-notification）和延迟减少（latency reduction）协议的一些讨论被公开化了。讨论结果很可能会影响未来互联网的运作情况 - 以及Linux系统是否能够仍然保留在互联网中的重要地位。

网络拥塞是很常见的，无法避免。发生后，唯一有用的应对措施是让发送方慢点发。就像交警大队可能会把交通信号灯放在通往很容易发生交通拥堵的区域的公路入口上，减少进入的车流，来预防拥堵。网络流量控制可以采用类似方案，但是在网络的每个入口点处放置红绿灯是不切实际的。因此网络协议必须依赖其他类型的信号来了解何时应降低其传输速率。

遗憾的是，像TCP这样的协议没有设计这样的信号，所以后来添加的拥塞控制算法只能使用唯一一个可靠的信息：丢包数。但是丢包会使情况变得更麻烦，它会导致再次传输retransmission，这会引入延迟，并且当丢包发生时拥塞已经发生了。大家更希望在拥塞发生之前采取一些轻量级的预防手段。

ECN and discontents

在2001年标准化 的explicit congestion notification（ECN）协议是通过在不丢弃数据包的情况下通知发送者拥塞来改善上述问题的一个方案。ECN在IP报头中重新利用了两个bit：

00	Transport is not ECN-capable
01	ECN-capable ECT(1)
10	ECN-capable ECT(0)
11	Congestion experienced

ECT（0）和ECT（1）值具有相同的含义; 它们表明至少在这个IP包的发送方和接收方两端之间的route上的某个地方支持ECN。在实践中，所有实现都使用ECT（0）。ECN方案很出名，因为不少路由器会丢弃那些这两个bit不是00的数据包，莫名其妙的丢包大家是都受不了的。。。

ECN改善了拥塞方案，但还不够。一个问题是“Congestion experienced”的信号仍然来得太晚，拥堵已经发生了。它的处理措施也仍然很粗暴： RFC要求将Congestion experienced的信号视为有数据包已经被丢弃了，因此拥塞控制算法会大幅度降低发送速率，然后慢慢恢复。这种方案可能会“过于”降低网络吞吐量，以及增加了额外的延迟。总之，下手太狠了。

互联网在不断发展，随着网络速度的提高，对低延迟（low latency）的需求也会增加，并且随着路由器开发商优化了路由器上的buffer的使用效率，路由器有更少的buffer了，拥塞控制需要更加精细一点。大家都赞同迫切需要改善拥塞控制方案。

L4S

针对某些特定行业，已经涌现了一种改善拥塞控制的方案，就是所谓的低延迟，低损耗，可扩展吞吐量或L4S（low latency, low loss, scalable throughput）。核心思想是用高级别协议中内置的更灵活的一些flag来取代ECN。 数据中心TCP （DCTCP, data center TCP）就是一个例子。DCTCP协议中的Ack包可以包括queue里面剩余空间的信息，发送方可以利用这个信息来保持队列尽可能满但是不溢出。自4.1发布以来，Linux一直支持DCTCP。

类似DCTCP这种方案的问题是，整个网络通路上的所有路由器上都必须运行支持DCTCP的队列管理算法。这些算法会查看经过路由器的所有流量，而不仅仅是DCTCP流量。L4S的支持者打算用一种特殊处理方式，通过路由器获得low latency响应，又不违反classic TCP。

为了实现这一点，L4S重新定义了上述ECT（1）值，表示“此数据包正在使用更好的拥塞通知”。然后路由器将创建两个单独的队列：L4S数据队列，速度较快；“经典”数据队列，速度较慢。这种改动，让人眼前一亮。但是队列管理算法需要作为一个整体进行评估，因为它的影响太广泛了，也要避免影响它的公平性。

在数据中心等受保护环境之外使用DCTCP并不完全安全。为了能在更大范围部署，开发者想要创建一个名为“TCP Prague”的新的TCP拥塞控制算法。然后，L4S部分将使用称为“DUALPI”的队列管理（queue-management）算法来实现，用它维护上面介绍的两个独立queue。直到最近，这两个改动都还远未成熟：3月12日在github上出现了TCP Prague的项目（尚未提交给mainline），DUALPI于3月11日发布到netdev列表中。

SCE

由buffer优化开发者Jonathan Morton和DaveTäht以及UDP创建者David Reed推动的另一种方案被称为Some Congestion Experienced，SCE。这是一个相当简单的提议，提供了一个“Congestion is imminent”信号，来做预警（而不是拥塞已经发生之后的警告）; 这个方案更优先考虑与现有TCP拥塞控制实现的兼容性。

SCE也利用ECT（1）bit来表示“some congestion”信号。Congestion Experienced这个11的含义保持其当前定义，期望协议将其视为等同于丢弃的分组。相应的，SCE信号应该这样解释：

支持SCE方案的网络接收方和传输层协议，应该将SCE这个标志理解为轻度拥塞的指示，收到的ECT和SCE包的比率表明目前拥塞的相对严重程度，让100％SCE非常接近CE（Congestion experienced）标记的阈值，100％ECT表示瓶颈链路可能未被充分利用，所以 ECT和SCE如果是1:1平衡，才表明当前的发送速率与瓶颈链路的能力很好地匹配。

实现SCE的代码也很新; 它出现在3月14日的fq_codel_fast Repository中。值得注意的是，此方案没有给中间路由器一种了解其中一个端点是否能够响应SCE信号的方法。大家都期望发生的情况是，等SCE得到Linux和FreeBSD的支持，它就能很快成为internet上的事实标准，无处不在。

Which is better

这两个提案明显互相不兼容：每个都对ECT（1）值进行了不同的解释，并且会导致使用另一个方案的网络节点被误导。SCE方面认为它的用法与现有Internet方案完全兼容，而L4S提案是跟现有拥塞控制算法不兼容的协议。L4S支持者认为双队列架构是实现它的low latency目标所必需的，而SCE方案只关注两端的拥塞，没有改善latency。

这其实是由最大的互联网服务提供商推动的协议，与草根人群提出协议之间的一起战斗，很具有典型性。然而，关于L4S还有另一个重要信息：阿尔卡特朗讯声称双队列算法的专利。该公司慷慨地提出以“公平，合理，非歧视”的条款提供该专利; 这种条款跟free software不相容。这种情况下，无法将相关代码合并到GPL许可的Linux内核中。

与许多专利一样，这一专利生命并未得到普遍认可。L4S的开发者之一Bob Briscoe大声宣称，阿尔卡特朗讯专利中的声明的技术已经在此前有了先例，根本就不应该被批准专利。不幸的是，该专利已经存在，只要阿尔卡特朗讯继续拥有这个专利，相关代码就无法成为Linux内核的一部分。如果L4S成为IETF的指定标准，紧接着被行业采用，那么Linux可能会陷入困境。

对这些协议的不同意见反映了开发者与其相关行业巨头之间的道路差异。它理所当然的会有技术和政治双重考量，看这这些争论可能不会很愉快。有人可能会认为，Linux社区可以坐视双方争论，最后有胜者后直接合入即可。也有人认为，SCE更吻合我们已经成型的network stack的精神。然而，这里的专利主张大大增加了风险; 如果最后Linux发现自己无法与其他高性能网络设备一起正常交互，那就麻烦了。所以，只要专利仍然存在，这里做技术选择就很容易 :)

全文完

欢迎将文章分享到朋友圈 
如需转载，请在后台回复“转载”获取授权

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～