DCTCP之FCT优化随想

IDC网络和广域网有什么不同?如果把网络抽象成BDP管道,那么:

  • 广域网:B中等,D超级大。
  • IDC网络:B超级大,D超级小。

将一次传输的RTT分为三部分:

R T T = T p r o c e s s + T p r o p + T q u e u e RTT=T_{process}+T_{prop}+T_{queue} RTT=Tprocess+Tprop+Tqueue

对于广域网, T p r o p T_{prop} Tprop维持在10ms~100ms量级,因此可以通过观测或者调整1ms~50ms量级的 T q u e u e T_{queue} Tqueue来进行拥塞控制。

对于IDC网络, T p r o p T_{prop} Tprop维持在1us~100us量级,但 T q u e u e T_{queue} Tqueue依然是1ms~50ms量级,这意味着交换机拥塞排队将会导致RTT产生10倍到百倍的飙升,产生严重的业务抖动。

雪上加霜的是,由于IDC网络的超高带宽,这意味着轻微的突发都可能导致严重的拥塞排队,使得抖动更容易发生,这实属一种悲哀。

因此,IDC网络的拥塞控制策略必须改变。和传统拥塞控制的目标不同,IDC网络根本没有时间等待 T q u e u e T_{queue} Tqueue的反馈,与之相反,它必须严格控制 T q u e u e T_{queue} Tqueue在极小的阈值之下。

总的来讲,广域网的 T p r o p T_{prop} Tprop占大头,因此可以忽略 T p r o c e s s T_{process} Tprocess,并利用 T q u e u e T_{queue} Tqueue反馈做cc,对于IDC而言, T p r o p T_{prop} Tprop T p r o c e s s T_{process} Tprocess差不多, T q u e u e T_{queue} Tqueue是全局敏感量,必须限制在阈值内,同时针对 T p r o c e s s T_{process} Tprocess做优化。

从云原生看IDC网络,结论依然不变。

在云原生环境,IDC内部遍布微服务,IDC网络更重要的职责在微服务调用间的消息传递而非大块数据传输,数据传输更多的是要解决数据同步等分布式一致性问题。消息传递只有一个需求,低延时!

DCTCP是IDC内部的算法,它的目标:

  • 保持低时延。
  • 长流不损害短流。
  • 长流保持高吞吐。

支持ECN的交换机在排队超过阈值 K K K时会对TCP数据包进行标记,该标记通过接收端的ACK回送到发送端,DCTCP会采集被标记数据包的比例 F F F,采用下面的公式控制拥塞窗口:

α = ( 1 − g ) × α + F × α \alpha=(1-g)\times\alpha+F\times\alpha α=(1g)×α+F×α

W = ( 1 − α 2 ) W W=(1-\dfrac{\alpha}{2})W W=(12α)W

可见以下特性:

  • 若无拥塞, F F F为0, α \alpha α逐渐平滑到0, W W W保持。
  • 若有拥塞, F F F增加, α \alpha α逐渐增大, W W W减小。
  • 拥塞越剧烈, F F F越大, α \alpha α越大, W W W减小越剧烈。

和广域网上拥塞窗口陡然变化不同,DCTCP更有利于发现突然的变化并无级变速。但这种策略不利于突发短流:

  • 突发短流开始前,长流的 α \alpha α已经平滑到0,多条短流突发导致拥塞, α \alpha α的移指平均导致长流 W W W下降过缓,新的短流受到抑制。

谁需要为拥塞负责是个问题。

站在业务的角度,突发短流的FCT指标更重要,而不是带宽利用率,公平收敛等传统指标,比如数量众多的pingpong查询流,而长流反而是可适当延迟的背景流量。因此最短完成优先,最短总时间优先可能是更好的策略。

如何利好突发短流呢?一个想法是,惩罚长流,变相优待短流。
α \alpha α的移指计算中引入一个参数 t t t,即连接建议到现在的时间, t t t的演化 f ( t ) f(t) f(t)使 α \alpha α满足:

  • t t t越小, α \alpha α越接近标准DCTCP算法的结果
  • t t t越大, α \alpha α相比标准DCTCP算法的结果越偏大。

类似下面的函数是满足要求的:

y = 0.5 2 x + 1 + 0.5 y=\frac{0.5}{2x+1}+0.5 y=2x+10.5+0.5

下面是它的图像:
在这里插入图片描述

新的 α \alpha α移指表达式为:

α = ( 1 − g ∗ f ( t ) ) × α + F × α \alpha=(1-g*f(t))\times\alpha+F\times\alpha α=(1gf(t))×α+F×α

它需要满足:

  • t t t为0时, f ( t ) = 1 f(t)=1 f(t)=1,维持和标准DCTCP一致。
  • t t t大于0时,稍微陡峭不要太缓慢地减少。
  • f ( t ) f(t) f(t) y = k > 0 y=k>0 y=k>0为渐近线,保证 α \alpha α可以平滑到0。

这就修正了标准DCTCP平等对待所有流的问题,利好短流FCT。

我的观点依然是:

  • 广域网的拥塞控制一视同仁,网络简单些,端到端复杂些。
  • IDC的拥塞控制需要区分业务,网络复杂些,端到端简单些。
  • IDC交换机回送ECN标识本身就可以让不同类型的流区分对待。
  • IDC网络是协作非博弈网络,无需无条件公平收敛保证。

你是怎么想的呢?欢迎讨论,有机会赢温州名牌皮鞋👞!

PS:Linux内核的DCTCP的实现并没有根据ECN标记实时调整拥塞窗口,而只是在检测到丢包时才作出反应。这背后的假设依然是丢包作为拥塞的信号。这和ECN相悖,ECN的意思是,交换机通过显式的通知告诉发送端发生了拥塞,而不是丢包,否则包都丢了,谁负责通知呢?所以,Linux的DCTCP算法需要修改,别总觉得能发一个包就多发一个包,反正能等到丢包信号,这不还是传统的广域网拥塞控制思维吗?要改。

传统意义的拥塞控制是针对运营商的广域网用户而言的,其目标在于公平收敛,提高带宽利用率,毕竟互联网第一次拥塞崩溃事件就发生在广域网,拥塞控制控制由此诞生。
对于IDC网络,强交互特征意味着它更关注低延时而不是传输效能,但传统的拥塞控制策略并不能有效降低延时,这意味着挑战,也意味着新的趣味。周末随便写点与此有关的东西,就有了本文。

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

  • 3
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
LabVIEW是一款图形化编程软件,可以在不需要编写代码的情况下,通过拖拽和连接图形元件,实现各种复杂的控制系统和数据采集/处理方案。为保证这些系统和方案的正确性和稳定性,需要进行各种测试。 FCT(Functional Test)测试是LabVIEW中常用的一种测试方法,其目的是验证被测系统在各种正常和异常的工作条件下,是否能够正确地响应输入和输出。FCT测试通常采用自动化测试的方式进行,即编写测试程序,通过半自动化或全自动化的方式进行测试。 在LabVIEW中,可以使用各种测试工具和VI(Virtual Instrument)进行FCT测试。例如,可以使用TestStand工具来创建测试序列和自动化测试程序,以验证被测系统在各种情况下的响应性和稳定性。也可以使用NI-DAQmx等VI来进行数据采集和处理,从而验证系统的数据输入和输出是否正确。 在进行FCT测试前,需要明确被测系统的功能、输入输出要求和特殊工况下的响应等相关信息,并进行测试用例的设计和相关VI的开发。测试过程中,需要记录各种测试结果和异常情况,并进行问题分析和解决。 综上,FCT测试是LabVIEW中常用的一种测试方法,用于验证被测系统是否能够正确地响应输入和输出。在测试前需要进行系统分析和测试用例设计,测试过程中需要采用相应的测试工具和VI,记录测试结果和异常情况,并进行问题分析和解决。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值