基于RTT梯度的TCP CDG拥塞控制算法
Posted ksiwnhiwhs
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了基于RTT梯度的TCP CDG拥塞控制算法相关的知识,希望对你有一定的参考价值。
在BBR之前,业内已经逐渐学会如何判断网络拥塞并且用于TCP拥塞控制了。
再次重申,我鄙视并且非常恶心TCP!
我本来想看看CDG算法究竟是个什么东西,无奈并没有发现什么资料,所以,就像BBR一样,只能由我来写,我不希望到时候再搜索CDG的资源,都是我写的了,请注意,CDG不是腾讯的CDG,而是CAIA Delay-Gradient。虽然CDG在BBR之前,但是我认为,在褪去了BBR的光环之后,CDG显得更加适合中国人。毕竟BBR的要求太TMD多了,只是很多人不晓得而已,他们显露着一张张疲惫的脸庞,最终是一张张更加疲惫的脸庞...在介绍CDG之前,我先来说一下BBR的要求:
1.BBR要求底层为其开路,Google B4 SDN做到了,然而国内运营商,BAT的骨干网做不到。
2.BBR在通用下载模式中迎合了HTTP 2.0,因为其支持stream,都是“不短的连接”。
3.BBR适用于非速率优先的连接,比如恒定码率的视频流,Pacing最适合这种,而这种连接最怕传统TCP的突发。
4....
...可能还有5
如果你连1,2,3都不知道,就不要盲目测试BBR了。理解SDN的重要性,以程序员的视角,难!
-----------------------------------
好了,我要开始介绍CDG了。
一开始可能要扫兴一下,如今Linux 4.2内核版本以后实现的CDG算法,简直就是垃圾!这不怪CDG算法,这怪Linux拥塞控制算法框架本身就是一个垃圾框架!这一切在4.9内核之后得到了改善,这一切不得不让人感谢BBR算法的提供者,是他们修改了Linux的拥塞控制算法框架的结构,然而只有BBR本身收益了,CDG并没有收益。
这也许是因为CDG一开始就不受欢迎吧,所以它的作者没有动力去完善它。然而这一切被我尝试了一下,效果碾压BBR。一开始不受喜欢并不是CDG的错,而是其受制于Linux拥塞控制算法框架限制的错,被掣肘当然无法发挥,但是被我修改后,它可以驰骋了。关于我对CDG的修正,会有一篇单独的文章阐明。
CDG算法的核心,在于盯着RTT的变化,以便判断是否队列已经填满,由此来指导丢包发生后的行为。要点有二:
1.如果队列满了而丢包,那么乘性减窗;
2.如果队列非满而丢包,那么概率性乘性减窗;
事实上,如果不是为了保证公平性,如果队列非满而丢包,完全可以不减窗。现在的问题是“如何判断队列是否已经满了”。
其实很简单,下面的图示足以说明CDG模型的简单性:
为了让“非队列满情况下拥塞而丢包”这件事被忽略,就必须要保持窗口继续增长,然而Linux TCP的实现基于30年前的模型,在快速恢复阶段必须脱离拥塞控制算法的控制,降低窗口,所以对于CDG而言,在实现上必须要使用”小技巧“。Linux在快速恢复阶段采用了PRR算法而不是RFC算法,算是一个创举,然而即便如此,PRR算法也不受任何特定拥塞控制算法的控制。
这很悲哀!所以,在BBR算法对Linux内核TCP实现进行重构之前,CDG之类的优秀算法只能委曲求全!
现在让我们看一下CDG的标准行为吧:
-----------------------------------
多么好的算法,类似BBR那样对网络进行主动的探知,而不是仅仅依靠ACK反馈。
我说过BBR是最简单的拥塞控制算法,但是CDG却是比BBR更加简单的。它的模型为其建立了判断拥塞的根据,使CDG算法从对丢包敏感进化成了对拥塞敏感,以此就可以知道到底是拥塞了发生的丢包还是没有拥塞,而拥塞与否是拥塞控制的关键。这就是CDG算法的全部了。
再次重申,我鄙视并且非常恶心TCP!
我本来想看看CDG算法究竟是个什么东西,无奈并没有发现什么资料,所以,就像BBR一样,只能由我来写,我不希望到时候再搜索CDG的资源,都是我写的了,请注意,CDG不是腾讯的CDG,而是CAIA Delay-Gradient。虽然CDG在BBR之前,但是我认为,在褪去了BBR的光环之后,CDG显得更加适合中国人。毕竟BBR的要求太TMD多了,只是很多人不晓得而已,他们显露着一张张疲惫的脸庞,最终是一张张更加疲惫的脸庞...在介绍CDG之前,我先来说一下BBR的要求:
1.BBR要求底层为其开路,Google B4 SDN做到了,然而国内运营商,BAT的骨干网做不到。
2.BBR在通用下载模式中迎合了HTTP 2.0,因为其支持stream,都是“不短的连接”。
3.BBR适用于非速率优先的连接,比如恒定码率的视频流,Pacing最适合这种,而这种连接最怕传统TCP的突发。
4....
...可能还有5
如果你连1,2,3都不知道,就不要盲目测试BBR了。理解SDN的重要性,以程序员的视角,难!
-----------------------------------
好了,我要开始介绍CDG了。
一开始可能要扫兴一下,如今Linux 4.2内核版本以后实现的CDG算法,简直就是垃圾!这不怪CDG算法,这怪Linux拥塞控制算法框架本身就是一个垃圾框架!这一切在4.9内核之后得到了改善,这一切不得不让人感谢BBR算法的提供者,是他们修改了Linux的拥塞控制算法框架的结构,然而只有BBR本身收益了,CDG并没有收益。
这也许是因为CDG一开始就不受欢迎吧,所以它的作者没有动力去完善它。然而这一切被我尝试了一下,效果碾压BBR。一开始不受喜欢并不是CDG的错,而是其受制于Linux拥塞控制算法框架限制的错,被掣肘当然无法发挥,但是被我修改后,它可以驰骋了。关于我对CDG的修正,会有一篇单独的文章阐明。
CDG算法的核心,在于盯着RTT的变化,以便判断是否队列已经填满,由此来指导丢包发生后的行为。要点有二:
1.如果队列满了而丢包,那么乘性减窗;
2.如果队列非满而丢包,那么概率性乘性减窗;
事实上,如果不是为了保证公平性,如果队列非满而丢包,完全可以不减窗。现在的问题是“如何判断队列是否已经满了”。
其实很简单,下面的图示足以说明CDG模型的简单性:
图中的参数是以下的含义:
-----------------------------------
为了让“非队列满情况下拥塞而丢包”这件事被忽略,就必须要保持窗口继续增长,然而Linux TCP的实现基于30年前的模型,在快速恢复阶段必须脱离拥塞控制算法的控制,降低窗口,所以对于CDG而言,在实现上必须要使用”小技巧“。Linux在快速恢复阶段采用了PRR算法而不是RFC算法,算是一个创举,然而即便如此,PRR算法也不受任何特定拥塞控制算法的控制。
这很悲哀!所以,在BBR算法对Linux内核TCP实现进行重构之前,CDG之类的优秀算法只能委曲求全!
现在让我们看一下CDG的标准行为吧:
然而你在Linux中可能看不到这些,你只能看到个大概。上图中的第4个步骤,在Linux的实现中就没有很好的体现出来,我改了一版自己的实现,实现了这个逻辑。
-----------------------------------
多么好的算法,类似BBR那样对网络进行主动的探知,而不是仅仅依靠ACK反馈。
我说过BBR是最简单的拥塞控制算法,但是CDG却是比BBR更加简单的。它的模型为其建立了判断拥塞的根据,使CDG算法从对丢包敏感进化成了对拥塞敏感,以此就可以知道到底是拥塞了发生的丢包还是没有拥塞,而拥塞与否是拥塞控制的关键。这就是CDG算法的全部了。
将CDG的思想用在CUBIC非常简单,这样改造后的CUBIC就可以过滤非拥塞丢包了,这也是我将要做的事情。但是在TODO之前,我必须将Linux本身的CDG算法搞完善才行。现在离Linux 4.9发布的时间还不是太久,该版本集成了BBR算法和其对TCP框架的修改,如果CDG意识到了这里的意义,肯定会优化的,但是起码现在还没有,由于我要自用,只能我来做了。首先,我已经把BBR的逻辑移植到了3.10版本内核,其次,我要把4.3的CDG移植到3.10内核,然后基于这个移植做修改。
参考:《Revisiting TCP Congestion Control using Delay Gradients》
再分享一下我老师大神的人工智能教程吧。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!https://blog.csdn.net/jiangjunshow
以上是关于基于RTT梯度的TCP CDG拥塞控制算法的主要内容,如果未能解决你的问题,请参考以下文章