漫谈TCP新算法Elastic-TCP_tcp cca

自适应的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}}

RTTmax​RTTcurr​​来表示带宽的利用率，由于来计算目标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$
• 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)=RTTcurr​RTTmax​​w
​

关于这个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)=RTTcurr​w​RTTmax​
​

其中

w

R

T

T

c

u

r

r

\dfrac{w}{RTT_{curr}}

RTTcurr​w​代表的是当前的吞吐率，与

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增量会始终保持跟着

BDP走 ，这就是所谓的负反馈环带来的自适应。核心就是

R

T

T

m

a

x

R

T

T

c

u

r

r

\dfrac{RTT_{max}}{RTT_{curr}}

RTTcurr​RTTmax​​表示的权重和

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

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