低时延,可扩展的 l4s 拥塞控制算法

这篇具有很好参考价值的文章主要介绍了低时延,可扩展的 l4s 拥塞控制算法。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

最好的拥塞控制算法是维持不拥塞状态。

低时延不必多说,可扩展意思是无论流再多,也要低时延,时延不随流数量增加而增加。遗憾的是,由于缺乏足够信息,任何端到端算法都无法同时满足低时延和可扩展,甚至一个都满足不了。
当提到 vegas 可扩展时,并非指它的低时延可扩展,相反,如果如 vegas 约束 “每条流在 buffer 中滞留 alpha 个报文”,满足以下不等式即可:

α t q u e u i n g < 吞吐 = W t c u r r < β t q u e u i n g \dfrac{\alpha}{t_{queuing}}<吞吐=\dfrac{W}{t_{curr}}<\dfrac{\beta}{t_{queuing}} tqueuingα<吞吐=tcurrW<tqueuingβ

很明显,排队时延和 rtt 可同步增大,如果有 n 条流,就会带来 n ∗ α B W t o t a l \dfrac{n*\alpha}{BW_{total}} BWtotalnα 的时延,这违背了低时延可扩展性,它自己也这么说(vegas 论文 5.3 Queue Behavior):

Given that Vegas purposely tries to occupy between one and three extra buffers along the path for each connection, it seems possible that persistent queues could form at the bottleneck router if the whole world ran Vegas. These persistent queues would, in turn, add to the latency of all connections that crossed that router.

尝试修正它是徒劳的,必然掉入 bbr 主动排空 buffer 再主动 probe 的圈套,破坏了 vegas 带宽自适应能力。良性的 vegas 似乎已经是无路由器辅助的算法中 “效能 = 吞吐/时延” 的上限,难再进展。

没有路由器(交换机,基站)协助,端到端拥塞控制就是死胡同,折腾不出什么花样,现在 l4s 都标准化了,还有人迷信精确的闭环端到端算法,不可理喻又匪夷所思。

rfc9330 强调可扩展算法在不随流量变化的时间从拥塞中恢复,但我强调另一面,如果拥塞从不发生,并且稍微排队(再次强调,为获得 vegas 自适应能力),可扩展性意味着排队时延不随流数量而变化。

dctcp 算个可扩展 “拥塞控制” 算法,tcp prague 也算,但结合 l4s 框架的 vegas 是一个 “无拥塞” 的低时延算法。

把 vegas 约束颠倒一下,不再约束 buffer 中保留固定数量报文,而是约束任意报文在 buffer 中滞留固定时间,问题迎刃而解。

只有 1 条流,buffer 中是 a 个报文,2 条流就是 a / 2 个报文,n 条流就是 a / n 个报文,无论多少条流,buffer 中总报文数量都是 a,这就保证了时延是固定的,由于 buffer 中保留了报文,和 vegas 类似,sender 可自动获取退出流出让的带宽,也能动态出让带宽给新流。

如果没有路由器协助,根本无法完成上述过程,因为不知道 n。但有了 l4s 的思路,这件事就很简单:

α n < W ∗ t c u r r − t b a s e t c u r r < β n \dfrac{\alpha}{n}<W*\dfrac{t_{curr}-t_{base}}{t_{curr}}<\dfrac{\beta}{n} nα<Wtcurrtcurrtbase<nβ

在路由器将信息通知给 sender 之前,sender 必须支持非整数 cwnd,比如 cwnd = 3 / 4,可以在 4 个 rtt 中 pacing 3 个报文来处理。

一个简单但不易实现的方法是路由器将 n 告诉 sender,然后 sender 不断调整 alpha,beta。考虑到统计波动,在 n 振幅越过一个合理区间时,比如变化量超过总量 1 / 5 时才播报 n。但由于 l4s 并不支持回传整数给 sender,但 dcn 场景下那些小经理们随意自研的非标方案可考虑。

另一个方案比较容易实现,就是动态平衡,路由器算法如下:

  • 设 i = 0, α \alpha α为该路由器配置的固定(为了保留 vegas 的动态自适应能力)排队数量,固定 3*m 个 queue[3][m],。
  • 每个 packet 根据 5-tuple 被 hash0(tuples, i) 到某个 queue[i%3]。
  • 以 T = 5ms 为周期统计 m 个 queue[i%3] 中报文数量超过 α m \dfrac{\alpha}{m} mα中最长的那个,连续发送 2 个周期 ecn。不足 α m \dfrac{\alpha}{m} mα的 queue 中取最小的那个,连续发 2 个周期的 “不足”(可选)。
  • queue[i%3] 开始发 ecn 的周期,开始将报文 hash1(tuples, i) 进 queue[i%3 + 1]。
  • queue[i%3 + 1] 开始发 ecn 的周期,开始将报文 hash2(tuples, i) 进 queue[i%3 + 2]。
  • i++,重复第 2 步。

sender 端的 vegas 很简单:

  • 连续收到大于 5ms 的 ecn,n += n / 5(或 n / 10,或 n++)。
  • (可选)连续收到大于 5ms 的 “不足”,n -= n / 5(或 n / 10,或 n++)。

sender 可以不响应 ecn,但路由器 aqm 会教它做人,超过一定阈值也会丢包。

就这样摇摇晃晃保证每一条流公平分享瓶颈带宽并保持低时延,这就是可扩展性。当然,T 不 TCP 不重要,我可能会给出新协议以适配 l4s:

  • the Scalable congestion control on the sending host;
  • the AQM at the network bottleneck; and
  • the protocol between them.

下面的摘录,来自 rfc9330:

But first, the main point to grasp is that low latency is not provided by the network; low latency results from the careful behaviour of the Scalable congestion controllers used by L4S senders. The network does have a role, primarily to isolate the low latency of the carefully behaving L4S traffic from the higher queuing delay needed by traffic with preexisting Classic behaviour.

端到端的 vegas 太过谨慎且脆弱,但辅以 l4s,它很容易变得可用。

低延时,可扩展,这才是可控的因素,而高带宽不是。带宽是资源,而低延时和可扩展是调度。l4s + vegas 比 l4s + dctcp ~ tcp prague 更合时宜。

aimd(可由 reno,cubic 等 loss-based 算法等价) 可阻止拥塞崩溃,但它做不到无拥塞,如 vegas 指出( 5.2 Stability)的,它制造拥塞(先污染后治理…):

Up to the point where the window can be greater than one maximum segment size, Vegas is much better than Reno at recognizing and avoiding congestion—we have already seen that Reno does not avoid congestion, on the contrary, it periodically creates congestion.

在窗口可以小于 1 个 mss 后,配合 l4s 网络设施,事情将变得更好。

但标准化依然倾向于 aimd,因为它能确保可用性,公平性和稳定性三大刚需,本文的额外算法只能供经理杂耍

浙江温州皮鞋湿,下雨进水不会胖。文章来源地址https://www.toymoban.com/news/detail-761326.html

到了这里,关于低时延,可扩展的 l4s 拥塞控制算法的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 计算机网络 | 谈谈TCP的流量控制与拥塞控制

    对于滑动窗口,在上面也提到过了,在流量控制这一块,就要利用到这个滑动窗口的机制去实现两个主机之间的通信 [流量控制的目的]: 让发送方的发送速率不要太快,要让接收方来得及接收 然后来说一下很重要的例子,要注意理解,与后面的三次握手紧密度非常之大 首先

    2024年02月03日
    浏览(42)
  • 网络编程(12): TCP重传、滑动窗口、流量控制、拥塞控制

    通过序列号和确认号确保可靠传输,当发送端发送数据给接收到,接收端会返回一个确认号,表示收到消息了 超时重传 :没有在指定时间内收到 ACK 报文 超时重传的两种可能: 数据包丢失 、 确认包丢失 超时重传时间 RTO : RTO 较大:重发就变慢了,丢包之后需要半天才能重

    2024年02月12日
    浏览(53)
  • TCP的拥塞控制如何判断当前网络情况

    TCP的拥塞控制就像你在高速公路上开车一样。你通过观察交通情况来判断道路是否拥堵,然后做出相应调整以保持稳定的行驶速度。 在TCP中,发送方将数据发送到网络上。如果网络出现拥堵,数据包可能会丢失或延迟到达。为了判断当前网络情况,TCP使用一些方法: 丢包事

    2024年02月16日
    浏览(38)
  • 【网络】传输层——TCP(滑动窗口&&流量控制&&拥塞控制&&延迟应答&&捎带应答)

    🐱作者:一只大喵咪1201 🐱专栏:《网络》 🔥格言: 你只管努力,剩下的交给时间! 上篇文章对TCP可靠性机制讲解了一部分,这篇文章接着继续讲解。 在上篇文章中,本喵讲解了TCP的确认应答机制: 如上图所示,主机A每发送一个数据段,主机B都要给一个 ACK 确认应答,

    2024年02月12日
    浏览(57)
  • 计算机网络笔记:TCP的拥塞控制方法

    TCP的拥塞控制算法有四种,分别是慢开始、拥塞避免、快重传和快恢复。 拥塞窗口 : 基本概念 :发送方维持一个叫做拥塞窗口的状态变量。拥塞窗口的大小取决于网络的拥塞程度,并且是动态变化着的。发送方让自己的发送窗口等于拥塞窗口。 发送方控制拥塞窗口的原则

    2024年02月10日
    浏览(47)
  • 【计算机网络笔记】传输层——拥塞控制原理与解决方法

    什么是计算机网络? 什么是网络协议? 计算机网络的结构 数据交换之电路交换 数据交换之报文交换和分组交换 分组交换 vs 电路交换 计算机网络性能(1)——速率、带宽、延迟 计算机网络性能(2)——时延带宽积、丢包率、吞吐量/率 计算机网络体系结构概念 OSI参考模型

    2024年02月05日
    浏览(44)
  • 计算机网络 运输层下 | TCP概述 可靠传输 流量控制 拥塞控制 连接管理

    TCP是面向连接的运输协议 每一条TCP只能有两个端点,点对点 提供可靠的全双工交付 面向字节流,但占用很多资源 不提供广播和多播服务 所以从某种意义来说 UDP是一种更加有效的工作方式 TCP面向流的概念 把字节写入发送缓冲,加上TCP首部构成TCP报文段,从接收缓存读取字

    2024年02月04日
    浏览(55)
  • 网络编程——TCP的特性之自动重传/流量控制/拥塞控制,一篇说清楚

    自动重传请求(Automatic Repeat-reQuest),通过使用确认和超时这两个机制,在不可靠服务的基础上实现可靠的信息传输,其中包括停止等待ARQ协议和连续ARQ协议 1.1 停止等待ARQ 发送窗口大小为1,接收窗口大小也为1 发送方每发送一个数据包,就要等待接收方返回ack包,如果在定

    2024年04月26日
    浏览(49)
  • 论TCP协议中的拥塞控制机制与网络稳定性

    TCP协议中的拥塞控制机制与网络稳定性的深度探讨 随着互联网的快速发展,网络流量呈现爆炸式增长,网络拥塞问题逐渐凸显。为了维护网络的稳定运行,TCP协议中引入了拥塞控制机制。这一机制的主要目的是防止过多的数据注入网络,从而避免网络拥塞。然而,尽管拥塞控

    2024年04月22日
    浏览(44)
  • 哈工大计算机网络课程传输层协议之:拥塞控制原理剖析

    哈工大计算机网络课程传输层协议详解之:可靠数据传输的基本原理 哈工大计算机网络课程传输层协议详解之:流水线机制与滑动窗口协议 哈工大计算机网络课程传输层协议详解之:TCP协议 **拥塞(Congestion)** 非正式定义:“太多发送主机发送了太多数据或者发送速度太快

    2024年02月11日
    浏览(42)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包