核心要点:
- 谷歌 2020 SIGCOM
- 基于delay的AIMD
- 拥塞拆分EC和FC,时延敏感场景优势
- 分别计算EC和FC的wnd(最核心)
- 保障吞吐和低延迟。Swift 因利用延迟的简单性和有效性而闻名
- 包级别的
- 论文:https://dl.acm.org/doi/pdf/10.1145/3387514.3406591
- 论文翻译版:参考附件
其他:
- Swift 是 Google 提出的一种用于数据中心内通信的基于延迟的拥塞控制算法
- 基于delay的拥塞控制算法(不是基于丢包)
- Swift 的发展是由存储工作负载、主机网络堆栈和数据中心交换机的趋势推动的
- 通过AIMD(加性增加乘性减少)控制和在极端拥塞情况下的流量控制来实现端到端的延迟目标
- 拆分拥塞:Swift 将拥塞分为两个部分:NIC-to-NIC (fabric) 延迟(数据中心内不同节点间)、Endpoint 延迟(主机之间的传输延迟)。EC和FC,fabric congeston和endpoint congestion。
- Swift 通过分别计算这两部分的拥塞窗口(ecwnd 和 fcwnd)来控制发送速率
- 传统的研究主要集中在 fabric 拥塞上
- 包级别的CC,perPacket。(其他算法还有QP级别、IP级别等)
- 记录数据包在各个时间戳,包括软件、NIC等收发时间戳
- 时间戳影响点:(参考论文原文图)
- 端侧Tx delay,影响因子Tx queue
- 交换机 Forward delay,影响因子 SW queue
- 端侧Rx delay,影响因子Rx queue
- 广域网和数据中心网络延迟不一样,端侧影响也不一样
- 包含快速恢复机制,拥塞消退时,迅速增加发送速率,以便快速恢复到高效的传输状态。
- 支持QoS,共享网络环境中,在大规模incast流量发生时,保持关键业务流量的性能。
- 在拥塞窗口小于1的情况下,启用流控,计算数据包之间的发送间隔(基于RTT)控制速率。保障在高拥塞情况下维持低延迟和减少丢包。
- 特点:
- 易于部署和维护:使用简单的延迟目标来控制拥塞
- 端到端的RTT分解为网络基础设施(fabric)和主机(host)部分,从而分别对不同原因的拥塞做出响应。
- 能够在每台服务器上维持约100Gbps的吞吐量,同时保持低延迟和接近零的数据包丢失。long RPC场景要吞吐,short RPC要时延都能满足
- 能够有效地处理大规模的incast流量,并且在多租户环境中保持良好的性能。
- 延迟作为拥塞信号简单而有效,Swift的设计从TIMELY演变而来,通过简化绝对目标延迟的使用,提高了性能和鲁棒性。
- 关注主机层面的拥塞,这在处理延迟敏感、IOPS密集型和字节密集型工作负载方面有帮助。
- Swift算法的未来发展方向,包括如何进一步提高在极短传输中的延迟预测能力。
- 优势:
- 低延迟:在网络负载接近100%时仍能保持低延迟。
- 简单:简单,易部署和维护。无需特殊的交换机配置,无需交换机协调
- 端到端控制:独立适应网络和主机(包括NIC和主机网络栈)的拥塞,提供了端到端的拥塞控制,而不仅仅是在网络层面。
- 不足:
- 特定环境:只能数据中心,无法广域网
- 对硬件的依赖:主要是时间戳精度
- 动态调整挑战:快速变化的网络条件时,需要精心设计和调整算法参数。
- 兼容性:混合使用传统TCP和其他拥塞控制算法的环境中需要适配。
- 大规模incast流量的处理:虽然Swift算法设计了处理大规模incast流量的机制,但在实际部署中可能需要额外的策略来确保在极端情况下的性能。
- 高性能:保持高吞吐量的同时,实现低延迟和低丢包率。关键关注点:吞吐、实验、丢包
- 多租支持:为不同的流量类型提供有效的拥塞控制,避免单租大量流量影响其他租户
- 典型拥塞场景支持:
- 多租场景:不会相互干扰。
- 混合流量场景:混合,包括短期、突发流量和长期的、稳定的流量。适应这种多样性,通过动态调整拥塞窗口和目标延迟来优化性能。
- 存储和分析工作负载场景:适合于对存储和分析工作负载进行优化,这些工作负载通常需要高IOPS(输入/输出操作每秒)和低延迟的网络性能。
- 大规模并行计算场景:低延迟和高吞吐
- 网络拓扑变化场景:适应拓扑变化,如节点添加或移除,以及链路速度的变化。通过动态调整目标延迟。
- 网络故障和恢复场景:包含快速恢复机制
- 数据中心网络升级场景:适应速率升级如100G到200G这些变化,调整目标延迟来优化新旧硬件的性能。
- 虚拟化和容器化环境场景:可在虚拟化和容器化环境中工作
- 术语:AIMD英文全称:Additive Increase Multiplicative Decrease。TCP/IP模型中,属于运输层,为了解决拥塞控制的一个方法,即:加性增,乘性减,或者叫做“和式增加,积式减少”。加增乘减
- 论文摘要信息:
- 论文:https://dl.acm.org/doi/pdf/10.1145/3387514.3406591
- 其他
- 行业中闪存的需求是100K+ IOPS的delay在100u (u表示us )
- 行业中NVMe的需求是 1M+ IOPS的delay在 10u,需求来源是如果等太久服务器资源浪费
- 拥塞控制是数据中心系统性能的关键推动因素(或限制因素)
- DCTCP在长尾延迟在ms级别,尤其是大规模时候
- DCTCP 、PFC 、DCQCN 和 HPCC 等协议使用来自交换机的显式反馈ECN来保持网络队列较短和 RPC 完成时间较短。它们可以提供良好的性能,但在大型incase和 IOPS 密集型工作负载下无济于事。原文:
but they do not help under large incasts and IOPS-intensive workloads.
- 核心算法(待进一步研究)
参考:
https://zhuanlan.zhihu.com/p/566563035
https://baike.baidu.com/item/AIMD/10641459?fr=ge_ala