漫谈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


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

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页