TCP拥塞控制

Posted 2022-06-03 dog250

早期TCP没有内置拥塞控制，由于网络的规模小，并未出现拥塞，但内格尔(Nagle算法作者)还是对网络拥塞表达了先见担忧，来自1984年的RFC896中有详情：
Congestion Control in IP/TCP Internetworks

84年的TCP/IP叫IP/TCP。

内格尔描述了拥塞崩溃的成因：

• 交换机buffer随排队加剧直到排队延时超过RTO，GBN重传进一步加剧拥塞，直到有效带宽跌到接近0。

彼时没有拥塞窗口，慢启动等概念，TCP发送端完全按照通告窗口burst发送。

内格尔对拥塞控制关注两点：

• 尽量合并小包，减少包量缓解拥塞。
• 想办法让ICMP源抑制更有效地工作。

第一点就是Nagle算法，这个算法是TCP拥塞控制开山算法，可谓精妙：

• 如果交换机按包排队，合并n个包能将拥塞程度降低n倍。
• 如果交换机按字节排队，合并n个m字节包数据总长降低40*(n-1)字节。

内格尔借助self-clock指示的“状态变更”在等待ACK的时间内尽力合并小包，收到ACK才继续发送。这段时间合并了多少算多少，这是巧妙的自适应，未引入额外复杂性的前提下既减少了包量，又不会死锁。简单说，Nagle算法就是在小包情形TCP回退到“单包停-等”。

关于ICMP源抑制，内格尔表达了遗憾。ICMP无法保证发送，也无法保证传递，同时也无法控制发送端对源抑制报文的反应。ICMP源抑制并非TCP内置，很难相信这种机制能让所有TCP连接公平承担拥塞成本，公平性是拥塞控制的目标，也是前提。

和捕鱼类似。粗放式捕捞，势必会误捕幼小的鱼，结果是大鱼越来越少，最后谁也捞不着。精细化捕捞，只捞大鱼，大家都可持续捕捞。利己一时，全盘皆输，还是人人为我，我为人人，你选哪一个。

内格尔在RFC896中仅给出了愿景，并未给出方案。

果然，内格尔的提醒和担忧成了现实。

1986年10月，NSFNet加州大学伯克利分校和劳伦斯伯克利实验室之间的32kbps链路带宽降低了1000倍跌到40bps，几乎不可用。

范雅各布森(即Van Jacobson)随后于1988年正式引入了AIMD：
Congestion Avoidance and Control

自此，拥塞控制开始内置于TCP。范雅各布森拥塞控制三大件：

• 连接开始或静默后的慢启动
• 探测带宽和丢包时的AIMD
• 快速重传时的数据包守恒。

日子好过了几年，进入21世纪又开始作妖。算法开始分裂，想进录RFC必须确保公平性，但对野算法的部署却没要求，比如没有“不允许无视拥塞激进发送”这种规定。矛盾点在于检测拥塞控制行为需要在网络核心对端到端流量进行干涉，这本身也是违背网络中立原则。

当算法越来越多，很难保证使用不同算法的流之间的公平性，比如CUBIC和Vegas之间，BBR和CUBIC之间分别在深队列，浅队列情形如何保证公平，更有厂商趁机抢占带宽，钻空子添堵，各怀鬼胎。

这大酱缸中如何确保公平，如何确保高带宽利用率，如何确保低延时，痴人说梦。

今天同事介绍一个BBR讨论组issue：
bbrv1 is unable to detect more bandwidth when min_rtt is much smaller typical rtt

看题目“when min_rtt is much smaller typical rtt”，首先这肯定不是BBR自己所为，BBR本质上是杜绝srtt增加的，否则BBR就是错的。 肯定是别的流造成了“min_rtt is much smaller typical rtt”，一条流对另一条流一无所知也一筹莫展，既不知对方用什么算法，也不知是burst与否，或者是不是写死了cwnd，甚至UDP也说不定。

实际部署的任何拥塞算法，类似BBR讨论组中经常展示的这种精细调参，完全是徒劳。问题的根因有两个：
拥塞算法太多，算法之间无法保证公平性。

流模式太多，无法在同一机制作用下收敛。

如我之前所想，统一算法才是极致带宽利用率的前提，否则除了AIMD，其它的都不靠谱。一个自组织博弈系统在公平和效率之间必无偏向，正如你即不能指望一个规模很大的社会运行效率能有多高，也别指望它有多公平。

我有一个成功案例，无超卖的专线开4条TCP隧道，均分带宽，将该均分带宽换算为cwnd和pacing rate在TCP代码里写死。

另一个吞吐比上面稍弱但更简单的案例，同一条专线开4条TCP隧道，开BBR，任其自行收敛，但不保证它们随时均分带宽。

再一个吞吐比上面再弱一点但更公平的案例，在同一条专线上开4条TCP隧道，开CUBIC，任其自行收敛。
我要表达的是，自适应有代价，收敛有代价，这些代价都要从吞吐性能里借贷，还回去的是部署的便利和公平。

TCP拥塞控制不属于技术范畴，它涉及更多的是关于博弈论，社会行为学的范畴，它甚至只是跟统计复用沾边儿。泊松分布，马尔科夫链能很好地参与系统任务调度建模，对于数据包调度，应对拥塞控制却连近似都算不上。同样统计复用，网络是协作分布式的，操作系统却不是。还有有点不一样的，所以有效的TCP拥塞控制基本就两类，一类是Nagle的拥塞控制，一类是Van Jacobson的拥塞控制，别的基本pr居多。

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