Scalable-RE (Scalable-Reactive) : 一个实验性的单边加速算法

作者: master 分类: 技术 发布时间: 2017-07-05 17:12 ė 1479 views 6 没有评论

鉴于BAT、CNCache等一干大型IT企业压榨国内骨干网的手法愈加精纯,若不牺牲一点公平性,在业务网络上使用所谓的单边加速措施,未免有些不合国情。

既然是用于生产环境,锐速之流的国产闭源模块自然是不在考虑内的; 那么G家所开源的拥塞避免算法 (Congestion Avoidance Algorithms,下称CA) ——BBR (Bottleneck Bandwidth and RTT)本应成为兼顾效率与网络公平性的最优解。

然而赵国的网络环境实在险恶,借用某位大牛的描述便是:

…… 国内的TCP单边加速技术大多数故意都违背了收敛原则,就像我们路上开车一样,随意的变道加塞几乎成了“规矩”,如果你希望与前车保持安全距离,那么必然会有车子塞入那个“安全距离”内……如果你不加塞,就会有人催你加塞,如果你仍然不加塞,你就必须停车,这是典型的劣币驱良币,只因为大家都在做坏事。

更严重的是,大多数的排队系统是人为设置的,比如各类收费站,检查站,互联网上各种清洗设备,各类DPI设备,各类Fire Wall!

在这种“恶劣”的环境下,在任何的排队系统中,政治正确的做法就是加塞!TCP单边加速只是其中之一,远非全部。

避免Buffer bloat,这是正确的做法,bbr,vegas,westwood,甚至cdg背后都有理论支撑并解释“为什么这么做是正确的”,然而从国内实际生产环境上产生的效果上看,这些最终都是被虐的,正确的TCP连接的吞吐量非常低,且RTT抖动到无法使用的地步,反而发现足够简单的Scalable的效果“不符合预期的好”。

于是立志在网络公平性上超越CUBIC的BBR在国内与锐速之流竞争时便有了天然的劣势,因为BBR在拥塞发生时会backoff,而锐速的拥塞控制甚至是默认关闭的(csvmode=”0″)!在4.9以前版本的Linux内核中,忽略拥塞控制对单纯的CA而言是不现实的,一旦丢包发生,内核就会强制接管TCP连接并降窗(除非修改内核)。

感谢G家在4.9版本引入的cong_control(之前只能使用受内核干涉的cong_avoid逻辑)实现了CA对TCP的全局控制,令开源、易于部署、符合socialist value的单边加速方案的诞生成为了可能。

从上述前提出发,笔者基于Scalable的框架实现了一个简单的、对TCP进行完全接管的单边加速算法,暂且称之为Scalable-Reactive(下称Scalable-RE); 之所以不归类为CA,只因醉翁之意不在酒。

Scalable-RE共有三种行为模式:

1. 冗余带宽探测

由tcp_scalable_re_set_cwnd函数实现,初始窗口由scalable_init_cwnd指定,当TCP拥塞状态为Open时,执行乘性增窗(1.0625x),否则将窗口复位到peak threshould ;

2. 丢包响应

由tcp_scalable_re_loss_concealment函数实现,当TCP拥塞状态机处于非Open状态时,将发送速率保持在peak threshould以下,并在Recovery阶段每次将peak threshould减小最多1/8,以应对可能的拥塞丢包与带宽收缩 ;

3. 窗口阈值更新

于每个循环的起始与结束执行,在一个长周期中维护单位时间内应答包数量 (delivered) 的最大值 (peak threshould) ,以便丢包发生时窗口能及时收敛到一个相对安全的值,避免传统CA的激进减窗策略对TCP传输效率的负面影响 ;

以上三者共同构成一个状态驱动的控制流。

Scalable既没有BBR基于RTT的精准拥塞检测,也没有CUBIC高大上的三次凹凸函数的调控,却用足够简单的方式保证了带宽竞争力,而这种特性的延伸在足够鬼畜的国内网路中,或许会比循规蹈矩的BBR来的更加暴力有效。

完整代码已托管于github:

https://gist.github.com/anonymous/a98e9f5a5ca8b4d27bcbf752351b8584/raw/5ad13e0964d23d89edd482c82aa177f4686719f3/tcp_scalable_re.c

 

  • Scalable-RE遵照Dual BSD/GPL许可证开源。
  • Scalable近似,Scalable-RE收敛性 (Convergence) 不佳,在多个流共存时的公平性有待改进。
  • Scalable-RE的稳定性、普适性及公平性未经大规模实践证实,应仅作为BBR与其他商业方案效果不佳时的最后选项。部署到生产环境前建议谨慎斟酌。
  • Scalable-Reactive只是一个简陋的实验性方案,代码中难免存在纰漏

 

来自hostloc论坛

 

本文出自兴凡日志,转载时请注明出处及相应链接。

本文永久链接: http://www.aeaee.com/content/05318.html

0

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Ɣ回顶部