漫谈TCP新算法Elastic-TCP

自适应的CCA(Congestion Control Algorithm)给人一种简洁明快的感觉。

Elastic-TCP是一种新近的算法，比BBR还新，但比BBR简洁多了，可以从Wiki上了解其大概：

Elastic-TCP has been proposed in February 2019 by Mohamed A. Alrshah et al. to increase the bandwidth utilization over high-BDP networks to support recent applications such as cloud computing, big data transfer, IoT, etc. It is a Linux-based CCA which is designed for the Linux kernel. It is a receiver-side algorithm that employs a Loss-delay-based approach using a novel mechanism, called Window-correlated Weighting Function (WWF). It has a high level of elasticity to deal with different network characteristics without the need for human tuning. It has been evaluated by comparing its performance to Compound-TCP (the default CCA in MS Windows), CUBIC (the default of Linux) and TCP-BBR (the default of Linux 4.9 by Google) using NS-2 simulator and testbed. Elastic-TCP significantly improves the total performance in term of average throughput, loss ratio, and delay.

Elastic-TCP的目标是让AIMD的AI增量可以自适应BDP，比方说如果目标BDP很大，AI增量就大一些，反之，如果目标BDP很小，AI增量就小一些，Elastic的创新点在于它真正地基于Loss-Delay来调节AI增量。Elastic-TCP采用 R T T c u r r R T T m a x \dfrac{RTT_{curr}}{RTT_{max}} RTTmaxRTTcurr来表示带宽的利用率，由于来计算目标BDP。

自适应算法都有一个负反馈环。典型的例子，比如用于队列管理的codel算法。Elastic-TCP负反馈环的核心就是上面这个比值，当到达极限时， R T T c u r r RTT_{curr} RTTcurr等于 R T T m a x RTT_{max} RTTmax，一切重新开始。

在此之前，AIMD的几种思路都无法解决长RTT环境下窗口打开慢的问题：

Reno：AI增量固定为 a a a，无法适应长肥管道，且具有RTT不公平性。
CUBIC：解决了RTT不公平性，绝对时间轴上调节AI增量，无法适应长肥管道。
Scalable：双斜率固定AI增量，扩展性粒度太粗。
High Speed：修改response function适应不同的网络，针对特定带宽优化，实现复杂。
…

Elastic-TCP将AI增量设计成一个与当前窗口 w w w相关的函数 f ( w ) f(w) f(w)，称作WWF(Window-correlated Weighting Function)，且 f ( w ) f(w) f(w)由当前的带宽利用率直接导出：

f ( w ) = R T T m a x R T T c u r r w f(w)=\sqrt{\dfrac{RTT_{max}}{RTT_{curr}}w} f(w)=RTTcurrRTTmaxw

关于这个WWF的推导，详见Elastic-TCP的paper描述：
https://arxiv.org/pdf/1904.13105.pdf
其推导过程非常简洁直白，这里不再重复。但是可以用不同的视角去看这个WWF：

f ( w ) = w R T T c u r r R T T m a x f(w)=\sqrt{\dfrac{w}{RTT_{curr}}RTT_{max}} f(w)=RTTcurrwRTTmax

其中 w R T T c u r r \dfrac{w}{RTT_{curr}} RTTcurrw代表的是当前的吞吐率，与 R T T m a x RTT_{max} RTTmax的乘积就是BDP，这个BDP不一定是 最大BDP ，但随着buffer开始被填充，吞吐率将达到BltBW后不会再增加，因此在buffer固定的假设下，WWF趋向于一个固定值，即 B P D m a x \sqrt{BPD_{max}} BPDmax ，该 B D P m a x BDP_{max} BDPmax便是一个epoch的BDP目标值，以上计算所得的WWF便是Elastic-TCP AI的增量，其要点在于：

AI增量与当前连接的窗口可以达到的最大值(而不是当前窗口值)正相关。
在AI开始的位置，buffer尚未填充，BDP快速增长，取平方根，增速逐渐变缓。

随着buffer被填满，BDP达到最大值的同时，拥塞窗口 w w w也达到了最大值， Elastic-TCP使用BDP的平方根作为AI增量，其意义就显而易见了， AI增量会始终保持跟着 B D P BDP BDP走 ，这就是所谓的负反馈环带来的自适应。核心就是 R T T m a x R T T c u r r \dfrac{RTT_{max}}{RTT_{curr}} RTTcurrRTTmax表示的权重和 R T T c u r r RTT_{curr} RTTcurr的反比例关系，设计一个反比例函数， R T T RTT RTT大的时候就低走， R T T RTT RTT小的时候就高开。

在审视Elastic-TCP算法的时候，虽然它有Delay-based因素，但与传统Delay-based算法比如Vegas不同，Elastic-TCP并非基于Delay来决定增窗还是减窗，而是用Delay来计算AI增量，并且在一个Loss-based epoch中，Elastic-TCP矢志不渝地向目标BDP靠近，这个过程中，起作用的是 R T T m a x RTT_{max} RTTmax，而不是 R T T m i n RTT_{min} RTTmin。哈哈，Elastic-TCP依然是一个buffer友好的算法，且更凶猛。

但不管怎么说，Elastic-TCP毕竟是一个全新的CCA，它出现在网络带宽延展范围很大(从kbps到10Gbps)的当下，其目标是很明确的：

to increase the bandwidth utilization over high-BDP networks to support recent applications such as cloud computing, big data transfer, IoT, etc.

如此应景的算法，我不觉得它在故弄玄虚，且Elastic-TCP非常简单，没有任何花哨的东西，也没有可以任人乱调的经验参数：

这是继Reno之后最简单的CCA了，甚至比Scalable TCP还简单(Scalable TCP还有人问为什么是100)，我希望这是一个干净的开始，但似乎只是延缓了终结，Elastic-TCP依然需要buffer的overflow信号来进行收敛，但buffer的大小无法跟上带宽增长的速度，这就使得在高速网络中buffer overflow成了BltBW的限制因素，而这是摩尔定律决定的，人们无法改变。

另一方面，我们不能改变整个网络 Intelligence Edge & Dummy Core 的本质，我们不能为了CCA而期望网络变成 Complex Core & Dummy Client 般的怪物，这便约束了CCA能力的上限。虽然bufferbloat不是什么好事，但Elastic-TCP依然正视了bufferbloat的现实，并没有引入像BBR那样的新模型，依然在以AIMD为基础的Reno为依托，在buffer上大展舞姿。

关于Elastic-TCP的实现，我这里有个极简版本：
https://github.com/marywangran/Elastic-TCP

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

漫谈TCP新算法Elastic-TCP相关推荐

漫谈TCP High Speed与TCP Africa(TCP China)
自春节假期开启了漫谈TCP,很多想法都想往这上面靠,本周单休,早上4点起来写一篇春节假期没来得及写完的,今天这个关于HSTCP和TCP Africa的话题也归入漫谈了,实际上也真的是漫谈. 很多人看到 ...
【RFC6582 TCP快速恢复算法的NewReno修改】（翻译）
原文 https://datatracker.ietf.org/doc/html/rfc6582 The NewReno Modification to TCP's Fast Recovery Al ...
TCP rwnd算法挖坟
新算法的模拟代码明早再写. 一个大厂内部分享,讲师说TCP长肥管道无法填满,这是错误的.我曾经单流填满过一条200ms的5Gbps专线. 为什么大家碰到填充长肥管道难题后首先想到的都是rcvbuff不 ...
TCP 漕河泾算法(tcp_caohejing)
题目没意义,要说意义,大致类似于 Vegas,Reno,Tahoe,Westwood,地名. 周三傍晚发一则朋友圈: 总之,名字就是个名字,跟 tcp_vegas,tcp_reno,tcp_tahoe ...
TCP BBR算法与Reno/CUBIC的对比
我一再强调,BBR算法是个分界点,所有的TCP拥塞控制算法,被分为BBR之前和BBR之后的(其实发现,这并不是我个人的观点,很多人都这么认为,所有想写本文探个究竟).当然这里的"所有&quo ...
Scalable TCP拥塞算法
Scalable TCP(STCP)拥塞控制算法,在每个RTT周期内,如果没有发生拥塞,将在接收到每个ACK报文后,将拥塞窗口增加0.01(a值). cwnd = cwnd + 0.01 如果在一个R ...
TCP BBR算法中Pacing，cwnd，fq以及TSQ对RTT的影响
无论多忙,一周至少写一篇作文的时间必须要挤出来的,而且还不能让质量打折扣,所以,本文依然会探讨一个大多数人没有意识到的很偏的问题,我的文章一如既往地会写一些别的地方搜不到的疑难杂症的解法,希望大家多提 ...
tcp报文格式_34.TCP取样器
阅读文本大概需要3分钟. 1.TCP取样器的作用 TCP取样器作用就是通过TCP/IP协议来连接服务器,然后发送数据和接收数据. 2.TCP取样器详解 TCPClient classname:TCP报 ...
TCP/IP协议栈：TCP超时重传机制
目录基础概念重传超时时间RTO RTO的设定连接往返时间RTT RTT的计算 Karn算法往返时间测量重传拥塞避免算法快速重传和快速恢复算法重新分组网络数据包丢失,重传和重复确认是 ...

漫谈TCP新算法Elastic-TCP

漫谈TCP新算法Elastic-TCP相关推荐

最新文章

热门文章