NSDI23 论文阅读

2023-04-20

因为发现看过的论文很多都忘了，决定还是看论文的时候写个笔记，并上传到尘封已久的博客里。

Bolt

Sub RTT的CC

Background

CC的生效延迟有两部分

  1. 反馈延迟
    1. 通知的延迟，如果rsver反馈就算一个RTT，流开始时重要
    2. 未充分利用的延迟，流完成时重要
  2. 观察时间
    1. 大多数CC都是一个RTT内只改一次，为了不对同一拥塞重复触发

Design

packet守恒原则：如果total cwnd比capacity大，就有多余的packet在排队；反之则未充分利用

SRC: Sub-RTT Control

最小化notification：可编程交换机反馈

队列占用大于thresh（MTU），生成反馈SRC，路径上只有一个

SRC记录：当前队列长度、链路容量、原始数据包的时间戳tx_time（用于计算RTT_src）

sender计算RTT_src、reaction_factor（流对拥塞的贡献，流的速度/链路容量）、targetq（队列长度×贡献，大致视为流所占的队列长度，可以理解为额外侵占的部分）；使用RTT_src/targetq作为更新cwnd的弹性间隙（从而一个RTT降低targetq），这样，队列越长，触发越频繁

重传啥的和Swift保持一致

PRU: Proactive Ramp Up

流完成通知sender

当大于一个BDP的流正在发生最后一个cwnd的数据时，包上设立LAST标记，表明下一个RTT内不再有包。第一个cwnd的包设FIRST，因为这期间发生的数据包不是网络所期望的

交换机收到LAST时，不拥塞则增加对应出端口的PRU令牌值

发送端在数据包上标记INC，有PRU令牌或空闲带宽（这里见SM）的交换机保留INC并消耗令牌，否则置零INC。ack携带INC给sender，sender收到后给对应流提速

SM: Supply Matching

cwnd快速更新，从利用率不足中恢复

  1. PRU的分配策略可能会浪费令牌：可能分给速度无法上升的流（线速or瓶颈）
  2. 链路未充分利用而无主动反馈，例如故障、路由更改等

上述此类事件，缓慢探测太久

做法：数据包到达时通过+supply（时间×带宽）-demand（包的大小）累计SM令牌，可以为负，最大为MTU（因为没有浮点运算，做法是一个65536大小的表，大于65微秒就直接设为1MTU）

时间是now - 上次数据包到达时时间

这样，上一个RTT浪费的PRU令牌可以在下一个RTT中被SM找到可用带宽

QoS

附录里提到了两种适配QoS的做法，一是加权增加令牌，二是概率生成SRC反馈

Understanding the impact of host networkingelements on traffic bursts

这篇没看具体实现，只关注结论

Background

自相似性：类似分形这样的概念，例如吞吐量的变化在不同的时间尺度可能具有相同的某些特征

自相似性会影响：

  • 排队性能：对于强自相似性流量，平均队列长度会随着缓冲区的增加而增加，因此需要部署较小的缓冲区
  • 吞吐和延迟的权衡。作者引用了一些，没详细说，以后可能会看看
  • 流量预测。可以用于大时间尺度的流量预测

Hurst指数：0到1的值，衡量自相似性。

  • H>0.5表示长期正自相关，即序列中的较大值之后的可能也是较大值，并且未来一段时间也会表现地较大
  • H=0.5表示序列完全不相关
  • H<0.5表示均值恢复，即序列中较大值之后可能是较小值（振荡）

Findings

本来以为会介绍很多发现并且有些推断，其实只是笼统地介绍了一下，组件会影响突发性、各个CC或者不同的qdisc会影响等等，并没有很多进一步的分析。

Empowering Azure Storage with RDMA

微软Azure的跨数据中心RDMA，经验论文

Background

微软的目标是存算分离场景下，同时为前端流量（计算和存储间）和后端流量（存储内）启用RDMA，前端流量可能位于不同的数据中心

Azure的拓扑图见Figure 2，Fat-tree，T2到RH交换机的长度可达数十公里，DC内RTT微秒，DC间2毫秒，T0和T1的pizza box交换机浅buffer，T2和RH是chassis交换机（机箱交换机？），deep buffer

计算集群里是VM，存储集群里是VHD（虚拟硬盘），存储集群分三层：Frontend（验证外部请求并转发）、Partition（管理所有分区）、Stream（分布式文件系统）

在区域RDMA中丢包的恢复要数百微秒，所以用PFC，区域内的新挑战：不同的NIC、不同的交换机间通信，不同的RTT带来的公平性、长距离对PFC headroom的压力

Azure使用PFC watchdog避免广播风暴

Storage Protocols over RDMA

sU-RDMA

用于后端通信，构建了sU RDMALib的用户空间的库

挑战：

  • RDMA应用程序无法直接写入现有的内存区域（memory regions, MR）时，要么将应用程序缓冲区注册为新的MR，要么将数据复制到现有的MR，都带来很大的延迟损失
  • RDMA的Send和Receive原语，需要接收方预先发布足够的Receive request
  • 发送方和接收方必需就传输的数据大小达成一致

应对：

  • 为了减少注册，维护一个公共缓冲池
    • 预注册、跨多个连接共享
    • 提供API允许应用程序请求和释放注册的缓冲区
  • credit-based flow control，credit表示接收端的可用缓冲区和发布的receive request
  • 没有使用RDMA的Send和Receive发送消息。如果使用，每个请求都有固定的缓冲区大小S，用以传输数据。如果S太大，浪费内存空间；如果S太小，数据碎片开销，因此使用三种传输模式：
    • 小消息：使用RDMA的Send和Receive
    • 中等消息：发送方使用RDMA Write传输，使用Send通知接收端发送完成
    • 大消息：发送方使用Send包含本地数据缓冲区的描述，然后接收端用Read来读，最后接收端用Send告诉发送端读完了

由于RDMA使用DCQCN作为CC，DCQCN不关注inflight，为了提高incast性能，实现了一种静态的流控机制，有固定大小的块，每个连接只允许一个inflight块

sK-RDMA

前端通信，在内核态允许（sU-RDMA在用户态）（应该是为了节省计算节点的CPU）

计算写存储：计算节点Send携带请求，存储节点Read读数据，存储节点Send响应读完了（和sU的大消息一样）

计算读存储（存储写计算）：计算节点Send携带请求，存储节点Write写数据，存储节点Send响应计算节点写完了

响应用的是Send with Invalidate

RDMA Estats

测量工具，帮助判断瓶颈位置

Swith Management

异构性的解决方案：SONiC (Software for Open Networking in the Cloud)。通过统一的软件堆栈管理异构的交换机，它将交换机软件分解为多个容器化组件，网络运营商选择组件，定制SONiC，创建精简的“堆栈”。

SONiC提供部署RDMA所需要的全部功能，例如ECN、PFC、共享缓冲区

Buffer Model on Pizza Box Switches

实现了三个buffer pools：

  • ingress_pool进行入口准入控制，针对所有分组
  • egress_lossy_pool进行出口准入控制，针对有损分组
  • egress_lossless_pool进行出口准入控制，针对无损分组

只对无损流量用入口准入控制（PFC暂停）

只对有损流量用出口准入控制（动态阈值来丢包）

Testing

软件测试是用了API给对应port打“断点”，然后发数据包获得“快照”

硬件测试用了可编程的流量生成器

Congestion Control

Scaling PFC

微软提到需要几个GB的PFC headroom 缓冲

利用了一个pathological case：所有端口同时拥塞、端口的所有ingress queue依次暂停对面，这样的情况很罕见（工程上确实可以这样）

两个方面：

  • 用off-chip DRAM来存，与片上SRAM不同，片外DRAM的带宽略小，所以如果所有端口都线速，就会丢包
  • 为所有入口无损队列分配一个PFC headroom pool（共享这部分）

DCQCN Interoperability

主要问题是不同代的网卡的DCQCN实现细节不一样，这里介绍了工程上具体什么不同，以及相应怎么互操作

Gen1把大部分功能用firmware实现，碍于性能，在一个time window内只会生成最多一个CNP（基于NP的汇聚）。并且有缓存有限带来的性能问题，因此速率限制的粒度应该是per-burst而不是per-packet，从而降低活动QP的数量，减少缓存不足的问题

Gen2和Gen3放在了hardware，并且是基于RP的汇聚：NP每个都发CNP，但是RP在一个时间窗口只削一次。速率限制是per-packet粒度

问题：2/3发1，per-packet粒度太细，导致速度拉慢；1发2/3，NP倾向于发过多的CNP，从而造成降速太快

解决：让2/3像1，首先是从基于RP改为基于NP的汇聚；其次是把粒度也改为per-burst

Tuning DCQCN

通过实验得出结论

  • DCQCN不受RTT不公平的影响，因为基于速率
  • 为了给具有大RTT的DCQCN提供高吞吐，ECN使用大的Kmax-Kmin和小的Pmax
    • 见图
    • 这样可以使ECN标记较为稀疏
  • DCQCN要和缓冲区一起调整（而不是调整PFC），避免PFC在ECN之前被触发

Experience

逐步启用：测试平台→测试集群→生产环境中谨慎增加

在实验拥塞控制时先关闭DCQCN测出最佳的仅PFC性能，然后再用默认的DCQCN（测试环境得出的），然后调整ECN

Lessons and Open Problems

  • RDMA的故障转移非常昂贵
  • 主机网络（PCIe、NVLink等等）和物理网络应该融合
  • Switch buffer越来越重要
  • 云需要统一的行为模式和接口，解决异构
  • 测试很难

Skyplane: Optimizing Transfer Cost and Throughput Using Cloud-Aware Overlays

云只对出口收费，收费只和吞吐量有关，和速度无关；同一片云，去远的DC更贵，其他公司的云，出去价格和物理距离无关

约束条件：价格上限优化带宽，or带宽下限优化价格

假设与总的区域间带宽相比，单个用户批量传输消耗的带宽可以忽略不计

Parallel TCP的不公平：

  1. 用这个很常见
  2. 用户按照带宽付费
  3. 云提供商的流量整形
本文阅读量: