TCP拥塞控制和宽容

发布时间:2023-05-09 17:00

前面提到过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的不好,说说看。

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

ItVuer - 免责声明 - 关于我们 - 联系我们

本网站信息来源于互联网,如有侵权请联系:561261067@qq.com

桂ICP备16001015号