TCP拥塞控制和宽容

Posted 2022-06-08 dog250

前面提到过TCP对网络乱序不宽容以及乱序传输：
TCP和宽容
TCP乱序传输

但也只提到了保序导致的不宽容。但拥塞控制对网络也不宽容。

传统拥塞控制的基本假设是拥塞点位于到达接收端的固定路径上。这个假设使路径调度很难展开。

• 基于包的负载均衡无法实施，不仅因乱序问题，还因一条流的数据包分散在多条路径，拥塞更难识别。

• flowlet调度无法实施，若捕捉到流的flowlet gap，并将其调度到另外路径，则影响拥塞控制所做测量的准确性。

• SDN无法实施调度流量，原因同上，这会影响发送端测量值的准确性。

若一条流在一个buffer发生了溢出，而该溢出并非该流主动所为，可能是其它突发流量导致，若SDN控制器将该流实时调度到其它路径，此前的溢出事件依然会被发送端捕获并实施收敛。这并不是所希望的行为。

在一条固定路径上堵到死，这是传统拥塞控制的基本假设，几乎所有拥塞控制措施都基于此而定，比如BBR的lt限速，这种后天的假设本身就与分组交换网的基本属性相悖。

纵容固定路径假设的除了TCP保序传输，还有最短路径路由。若只有最短路径可选，即使最短路径已经开始拥塞，次优路径以及次次优路径资源也只能浪费，没有任何临时绕路的措施。

TCP保序和最短路径路由减少了传输的很多可能性。

有一种办法可随时启用次优路径，使用流体渗透路由模型替代最短路径模型，所有的路径均可被充分利用：
IDC网络传输新方法-流体渗透原理
IDC网络低时延无阻塞拥塞控制随想

但在公网，除非采用具有全局视角的SDN控制器，否则依靠分布式洪泛，实时排队延时参与加权的路由算法很难快速收敛，还是滞后性难题，等待路由重新收敛时，拥塞可能已经结束。

说完网络再说端。

传统拥塞控制旨在获得最大单流吞吐，最高总带宽利用率，最佳公平性，但这仅仅是文件下载场景的需求。
其它场景，比如音视频流传输只需适配码率，数据同步需求只需适配直到落盘整个过程的最慢环节。

以音视频传输为例，传统拥塞控制的AI，MD，probe 25%，drain 25%，probertt 4 inflights，这些主动的探测和收敛行为与固定编解码速率相冲突，需要buffer来平滑主动引入的抖动。

无论在网络还是在端，buffer都是拥塞控制所必须。网络buffer检测拥塞，端buffer平滑检测拥塞所做的收敛，二者神奇抵消。这本质上是由于拥塞控制既不认识网络，也不认识端。

拥塞控制自决是另一种方案。初始传输速率由应用显式指定，网络尽力传输，若无法满足，由端识别并协商降速或降级。按照编码速率传输，若不成，一起降低编码速率，就好过多了。

底层仅做兜底收敛，用于惩戒恶意连接。

TCP虽可恶，但已经成为事实上的传输标准，没办法。竟然有(我可没说全部)音视频流采用这种丢一个包就卡一个RTT的协议，对于很多业务流，真是一个字节也不能丢吗？我想是CDN纵容了HTTP。虽然HTTP本不限用TCP传输，但大家已经默认HTTP下面是TCP了，因此HTTP-Based基本也就是TCP-Based了。当大家都在无条件使用TCP的时候，也就接受了它的一切，包括缺陷，甚至新的QUIC协议也copy很多TCP feature，所谓优化版TCP。本系列专门抓一些TCP的不好，说说看。

浙江文章皮鞋湿，下雨进水不会胖。