Sigcomm‘2018 Homa: A Receiver-Driven Low-Latency Transport Protocol Using Network Priorities论文读书笔记

Introduction

这篇文章是Sigcomm2018年的文章Homa。

Homa是基于pHost接收端驱动进行改进的。设计的主要动机是为了提升小流的吞吐量，降低尾部延时。
设计的要点是

• 接收端驱动，
• 动态调整优先级，
• Overcomitment。

Homa主要对pHost存在的两个问题进行了改进：第一个问题是新流到达时不能够进行快速抢占，需要等待一个RTT才能调整调度策略，对短流不够友好。第二个问题是发送端与多个接受端通信时部分带宽会被浪费的问题。

Motivation

这里介绍为什么针对短流来设计协议是必要的。
作者给出了实测的五种环境下的流量大小累计分布，来自有谷歌脸书和微软。在图中可以看到，在W1和W2中超过95%的message小于1000字节。而W3，W4小于一千字节的cumulative message也占了很大一部分。那么既然有需求的话，做这个针对短流的数据中心协议就很有意义了。

首先论文明确一个事实，如果想要降低短流的完成时间，那么排队是不可避免的。因为在空负载网络中如果想获得最佳延迟，那么用线速开始发包是最好的选择。但是一旦有多个发送端对应一个接收端的情况，那么出现排队情况之后反而会增加短流的等待时间。
考虑到排队是不可避免的，为了尽可能减少排队带来的影响，设置优先级实现最短优先作业就是必须的了。像图中所示，红色的流优先级别更低，所以绿色的流发送完毕之后才能轮到它。

论文中认为接收端附近是分配优先级的最佳位置。因为在当今的数据中心网络中，排队主要发生在接收器附近的TOR上，而数据中心网络的核心上具有足够的带宽，很少发生拥塞。

Homa Design

这里看到Homa的具体设计。首先接收端驱动的包调度机制。这个机制类似于pHost或者NDP，目标是为接受去获取尽可能多的调度能力。每个发送端将消息分为两个部分：

• 不按计划部分，
• 按计划部分。

不按计划的部分，也就是小流，发送端收到就开始用线速发包。而按计划的部分发送端只在接收到GRANT之后才被允许发送。这么做解决了pHost中总是会浪费第一个RTT的问题。在一个接收端一个发送端的情况下，这样的作法可以达到最佳延迟。
这种包调度的优势在于可以让接收方控制到底是哪个发送方来发送数据。就拿图中的例子来举例，当接收方意识到发送方2正在发送一条较短的消息时，停止授予发送方1的授予，并为发送方2发送授予，然后在完全授予发送方时恢复向发送方1发送授予。

但是仅仅把所有的流区分为两种也是不够的。这样的机制是没有办法控制不按计划部分的包的，这些unscheduled packets中间同样会存在排队延迟。

为了解决这个问题，Homa将所有的包分为最多8个优先级。其中最低的两个用先级用于scheduled packets，剩下的六个优先级用于unscheduled packets。Homa根据不同的流量累计分布函数（CDF）计算阈值，尽可能让unscheduled packets的六个优先级中的包的数量相等，减少尾部延时。
而优先级P0与P1的区分方法类似于PIAS，发的包超过了阈值就认为它可能是一个大流。

这里讲pHost接收端驱动中的第二个问题，当一个接收端对应多个发送端时，接收端下行链路的带宽浪费的问题。这里可以看到，m1和m3要从不同的链路发送到接收端R1。通过判断优先级，R1更倾向于让发送端S1发包，于是向S1发送Grants。但是此时在发送端S1上面，m2的优先级比m1更高，于时S2向R2发送m2。这个链路的带宽就被浪费了。

这个问题的解决办法就是接收方向所有向它请求都同时发送Grants，让发送方把包先发出来，在接收端再进行优先级排序。

Discussion

18年发表在电子科技大学科学报上的期刊“数据中心网络中一种基于ECN的TCP慢启动拥塞控制策略”中提到了这样的一个问题——慢启动机制带来的指数增加式的发送速率上升会导致incast问题，最终导致效率奔溃。

Homa中认为对于unscheduled packets，对它们应该使用线速盲目地发送，然后在接收方对它们进行调度从而达到减少小流完成时间的目的。这比慢启动机制更加激进，无疑会引起更严重的incast问题。更糟糕的是，我认为这个问题在Homa中是不能够被解决的，因为减少小流的完成时间是这篇文章的核心买点。