漫谈无丢包网络拥塞控制和端到端原则

忘是亡心i 2022-09-11 01:19 10阅读 0赞

将一条公网链路用TCP隧道分割成多个段，每一个段根据该段的网络特征使用不同的拥塞控制算法，然后把多条如此分割的长链路合并在一起，这就是一个overlay网络，SDWAN数据面核心不过如此。由于使用TCP搭建隧道，所有的丢包都可以在隧道恢复，这个SDWAN是一个什么网络？这就是一个无丢包网络。

很多人觉得我什么都不懂，TCP隧道和无丢包网络(也叫无损网络)驴头不对马嘴。我当然知道无丢包网络是什么，但用TCP隧道连接的overlay网络类比无丢包网络并没什么不妥。对于端到端而言，感知不到任何丢包，就是无丢包网络。

狭义的无丢包网络往往针对数据中心的底层物理网络，在这里，传播时延极短，以纳秒，微秒计，此时交换机排队时延，主机处理时延，数据拷贝时延，将会是RTT中的大头，如果发生丢包，丢包恢复需要再经历一遍所有这些时延，因此优化掉这些时延在数据中心便是一个刚需。

主机处理时延，内存拷贝时延我并不关注，我依然只关注拥塞控制相关的。

TCP的任何丢包恢复策略，在数据中心都将是代价高昂的，数据中心需要一种特殊的方式进行拥塞控制。显而易见的方式是主动拥塞通知，即ECN，在交换机buffer即将溢出时，交换机暂存本应丢弃的数据包并显式通知拥塞的发生，而不是让端主机浪费至少一个RTT来进行丢包恢复。

ECN是一个好的机制，但它违背了端到端原则，该原则认为，应该把复杂性留给主机处理，网络仅仅保留最基本的路由和转发功能，显然，ECN在中间交换机中干预了数据流的传输行为。

但在刚需面前，原则又算得了什么？

既然如此，何不更进一步，所有交换机协作起来，当buffer即将溢出时，交换机反向发送pause通知，逐级向前传递到发送端，岂不是比ECN前向绕一圈由ACK带回的拥塞通知更有效？

如此一来，丢包尚未发生，拥塞信号就反馈到发送端主机了，结合pause源抑制，ECN，FEC等机制构建的网络，就是一个无丢包网络。这种网络在数据中心很容易实现。

数据中心交换机几乎已经白牌化，支持高度定制，不定制的交换机上不了数据中心的台面，想加入任何功能都可以，想怎么SDN都没有任何问题。在数据中心内部，RDMA，RoCE这些方可大行其道。

> 可能又有人喷我白牌，SDN，RDMA，RoCE驴头不对马嘴了，我只能说这些人太狭隘，对传输网络的认知太肤浅。

这种无丢包网络乍看起来像是取消了TCP协议存在的必要性，但是请注意，交换机实现的无丢包机制是位于链路层甚至链路层以下的，实际上是上层TCP的一个underlay，TCP并不能确保该无丢包网络一定存在并且工作良好。

> 不必纠结层次问题，每个层次所谓的无丢包都有该层次对应的作用范围，比如以太网可以在交换机之间实现无丢包，但无法跨越路由器，更无法控制端到端。underlay如何运输overlay数据，overlay并不之情，比如同样都是无线网络，WIFI就是半双工的，而5G则是全双工的，本质上它们就和本文第一段说的一段一段使用不同的拥塞控制算法是一回事，外层运输内层，万变不离其宗。

所以，在数据中心内部，简单的硬件支持，无丢包的underlay网络得以实现运输TCP，UDP。在TCP，UDP看来，底层的传输网络质量简直太好了。

然而在广域网，由于无法控制转发硬件，想无丢包，只能构建overlay网络，就是本文第一段开篇说的那些话，无丢包网络的驴头和SDWAN的马嘴就是这么对上的，所谓万变不离其宗，本质都相同。它们的差别在于无丢包的实现方式不同。

uderlay的无丢包，是真正的无丢包，在拥塞丢包前就会进行源抑制，如果发生了随机噪声丢包，也可以通过各种FEC机制恢复，然而overlay的无丢包，只是看起来无丢包，丢包了悄悄恢复即可，对于外部看来效果就是无丢包。

数据中心内部交换机紧密合作实现精细化无丢包，这是一种反端到端原则的实践，将复杂性放在了网络，而保持端主机处理的简单，把端主机更多的资源留给应用，显然这对于高性能计算应用是有好处的。

同样，在广域网上的overlay无丢包网络上，隧道连接的链路，隧道端点亦要承担复杂的丢包恢复逻辑，这增加了隧道端点的复杂性，在underlay看来，这些隧道端点依然是转发节点而不是主机，既然隧道端点之间的节点无法在unerlay层面跨越并且控制(比如实现pause源抑制)，那么增加端点复杂性的收益就是不抵代价的。何不简单些？

标准的TCP丢包恢复逻辑过于精细了，精确到对重传队列中每一个数据包的分析判定，显然这会浪费大量的计算资源且效果不一定好，既然无法精确控制链路，精确控制重传队列就无必要，何不在统计意义上进行丢包恢复，大摆拳，大力反而出奇迹。

设置一个丢包阈值，一旦丢包率突破该阈值，不再使用RFC的方案进行丢包恢复，而是简单地一个数据包发两遍甚至三遍，一直到丢包完全恢复或者丢包率降低到阈值以下。类似方案我很早就提出过，比如对于那些很重要很短的数据，一个包发两遍甚至三遍，浪费点带宽又如何，从全局意义上看ROI，冗余发包更佳。对于精细化操作，如果你无法证明反馈依然精确，那么这种精细就是徒劳的，不如大力出奇迹，在统计上取胜。

就好像足球的观赏性就在于，看每次进攻防守射门，它是无法精细化分析的，但是统计意义上，大致结果却是可预知的，这比举重和短跑有意思多了。

写在最后。

拥塞控制在数据中心内部的演进已经不再属于拥塞控制范畴了，更像是一种精细化的资源调度，一切都是可见的，确定的，端到端原则在这里完全反过来，因为端主机资源要让给应用而不是传输，数据中心网络越来越PCIe化了，如何在或CLOS，或胖树，或Spine-Leaf节点为每个连接分配资源是要务，一次传输就好像一个外设的中断事件通知到CPU的过程中经由的路径，资源分配是确定的，确保服务的，这必然要涉及调度和仲裁。

数据中心网络和Internet是完全不同的理念。我并非端到端原则的卫道者，40年前初始的端到端原则在如今还是不是最优解，本来就是一个值得商榷的事情，问题在于，你能接受多少不确定性。

***不确定性的度量，才是所有网络核心理念根本中的根本。***

--------------------

浙江温州皮鞋湿，下雨进水不会胖。