Homa: A Receiver-Driven Low-Latency Transport Protocol Using Network Priorities（Sigcomm'18） 论文记录

这是一篇讲述如何在低延迟的数据中心网络中通过优先级队列使小流延迟大幅降低（100X )的论文。

作者首先给我们明确了一个事实：虽然针对数据中心的网络协议近些年冒出来很多，有些表现的也不错，但是，很多没有考虑到在数据中心里，小流是占大多数的，很多100KB的数据，在很多协议中算小流，但是在作者这里已经算很大的数据量了。

从此文开始，我开始结合自己的理解来记录论文，从（全篇翻译+简短总结）变为（翻译加理解+简短总结）的方式。

Abstract

Homa是一种针对数据中心的一套协议。给予message优先级，不仅可以避免短流过分排队造成延迟，还可以控制过度负载利用有效带宽，比pFabric, pHost, PIAS在保持高吞吐上做的更好，并且针对短流降低100倍延迟。

Introduction

Homa的这些优点需要交换机支持的优先队列和发送端的动态优先级分配机制来配合。虽然Homa最适用的场景是短流阻塞，但是针对大流的性能他们表示也比TCP之类的表现的好。

作者还讲到他们的策略还允许少量发送端同时发送数据，这使得他们对带宽的利用率更高。

Motivation: Tiny latency for tiny message

说实话，作者连“我为什么要做这个”都讲得贼有逻辑，让你看了觉得这个真的很有必要！

我们的方案可行性？
近些年出现了一些低延迟的网卡和软件，这为Homa的实现提供了可行性

工作的必要性？
作者给出了实测的五种环境下的Message/Flow size：

证明了在实际环境中有很多收发小流的情况。

别人的工作在应用场景是啥？
先言，确实有很多好的面向数据中心的协议。但是，你们面向的场景都是那种大流、拥塞的场景。在你们那里1MB以上的message占了95%以上。

所以按照上面的逻辑：
技术的发展使得现在这个事可以做了->实际上也确实有很多应用场景是有这样的需求的->没有其他人做这个->那么我做的这个就很有意义了

The Design Space

实现Homa有四大原则：

1. 盲目地发送短消息
2. 使用in-network优先级 （这句话的意思应该是数据中心网络中可以分配优先级）
3. 配合接收端的流速控制，在接收端动态地分配优先级
4. 接收端下行链路的受控超量使用

他们的关注点是message Latency而不是packet Latency，因为最终影响应用程序性能的是message Latency。

他们认为解决短消息延迟过长的关键是：消除短消息的排队延迟。 而这个排队延迟主要发生在TOR往接收端的下行链路中。

接下来作者阐述了一下他们认为比较关键的点：
There is no time to schedule every packet,解决排队延迟的技术早有提出，比如说Fastpass,对于每一个message、每一个包都schedule，这样理论上可以完全消除排队延迟。但是实际上这种做法对于短消息来说是非常不适用的，因为处理的事件相对于它传输的时间来说太长了。 所以对于短消息应该transmit blindly without considering。

Buffering is necessary evil,此处作者提出了一个矛盾，如果你盲目地发包，那么当多个sender对应一个receiver的时候，这些包就需要buffering。即使有一些技术尝试解决这个buffering的延迟，但是都不能完全消除其延迟。

In-network priorities are a must,上面说到buffering是必须的，那么在这些buffer里面设置优先级就是必须的了，因为设置优先级以短的消息尽可能先走的方式运行，可以有效降低延迟。（但是这种做法难道不是很多人都可以想到吗？） 确实，这种事很多人做过了，其中做的最好的是SRPT，但是一个是它需要太多的优先级等级，第二它不是针对小流的。

Making best use of limited priorities requires receiver control, 为了只用最少数量的优先级，这个优先级就需要由接收端来决定了。需要根据这个TOR下行链路的情况来决定。pHost就做了类似的事情，pHost的做法是，给每个接收端发送一个短的message，然后根据你回复的速度，给你确定优先级。那么问题就是，一旦静态地确定了优先级，就不再分大流小流了。对于之前的w1~w5，比如说一旦确定了w1的优先级高于w5，那么w1的大流到来的时候，它的优先级也排在了w5的小流前面。

Receivers must allocate priorities dynamically, 两种机制：对于大于RTTbytes的message，发送端会在发送的message中有一个内置的消息，receiver会根据这个消息去和sender配合，动态分配priorities。对于小于RTTbytes的message，虽然不能有这样的消息，但是receiver还是会根据最近的工作负载去返还一个报告。

Receivers must overcommit their downlink in a controlled manner, 如果多个receiver给一个sender发送这种优先级决定的包，可能导致sender就不能马上收到并处理了，那么发送方就不能按照预想地全速发包了，所以带宽就可能用不满了，pHost就有这样的问题，他们的负载大概就在58~73%。所以Homa的用法是超负荷地提交控制包。

然后用了一段说明了一下，短message必须要插队才行，现在有些流控策略没有这种插队，FIFO会导致短message的延时扩大百倍。

那么总结以上的内容就是：
首先大家都能想到的，小包应该先走，如果堵在大包后面就很难受了
->
短包先走而不是见包就走就造成了一定需要buffer,但是你有buffer的话，在buffer这里就会有延迟，所以buffer就不能太长
->
buffer不能太长，然后要延迟也比较短的话，就需要比较多的priority level，这样才能比较好地实现算法，pHost就这么做
->
但是这个优先级也不能太多，而且它不仅不针对小流，而且还是静态地，那后来的大包可能优先级还高于有些小包
->
那我得搞一个分开判断大流和小流的，还要能动态地给你分level
->
但是这样又有一个问题啊：我接收端总是动态地给你发送端发set level的包，你可能处理不过来，然后就没全速发包，这样对带宽利用率不太好
->
所以稍微我给你的任务超负荷一点

在这个key design的后面，作者给了一幅图：

策略就是：sender发的包分为两种，scheduled（RTTbytes packet）和unscheduled，unscheduled的包先于scheduled的先发出去，receiver收到这个unscheduled包之后才会去请求scheduled的包。并且接收端会周期性地返回这个set priority的包，同时接收端按照超负荷的方式来工作。
（以上这段内容是我用比较简洁的话讲出来的，但是看完之后感觉似乎没什么很厉害的地方（可能这就是愚昧之人喷大神吧），这样就是一篇sigcomm？？）

HOMA Design

对具体设计感兴趣的话建议自己去看一下这个Design部分。我看了之后觉得他对上面的key design的补充有：

有四种包的类型：
DATA，就是数据包
GRANT，由接收端发送给发送端，为数据包set priority
RESEND，由接收端发送给发送端，告知发送端重发一段数据
BUSY，由发送端发送给接收端，告诉接收端，你的RESEND指令会诶延后。

Homa是不保存连接状态的，它针对RPCs，请求会携带唯一的RPCid。由于它是连接无状态的，所以如果这个请求又来一次，它会再做一次。
Homa是面向message的，而不是面向Flow的，意思就是说面向的是要发送的这条消息的大小，而不是一个连接中所有的消息。

流控机制是实现在接收端的，如果到来的包过多，那么根据优先级，接收端返回GRANT的时间会延后，也就是一种pull形式，如果包过多，那么就延后一些低优先级的pull。

优先队列作者是设置了P0 ~ P7，其中的P0、P1是给scheduled packets用的，P2 ~ P7 用于unscheduled packets。如果一个相应优先级的包会放到相应地队列中去发送。那么存在一个问题，就是优先级高的队列会不断地有抢占。所以，当低优先级的包到达，想要缓存到buffer中去的时候，他会等高优先级的先缓存，但是当高优先级的一个message缓存完，在下一个message缓存之前，会等一个RTT给低优先级的缓存，这样避免了抢占延迟。

此外Homa利用Incast主要是自身导致的解决了Incast的问题。这个问题时常发生在一个节点向其他多个节点并发产生RFC，并且其他多个节点几乎同时应答时。Homa的做法是设置一个阈值，一旦同时需要处理的message超过了这个阈值，那么就会阻塞大的response，而小的response会直接通过。并且在request中带上这个阻塞信号，使得server在返回response时尽量使用小的unscheduled的包。通过这种方式可以减缓TOR中的buffer的空间利用。

关于丢包，在数据中心里面，丢包主要是由两个原因导致的：1、网路故障；2、缓冲区溢出。由上面的介绍可以看到，Homa很好地利用了缓冲区，所以减少了由于缓冲区溢出导致的丢包。因此作者认为，部署了Homa的数据中心应该很少有丢包情况。所以他们对于丢包做了很简单的操作。

相比于TCP在发送端对于ACK进行判断和丢包恢复，Homa在接收端简单地进行处理，他不是ACK机制，而是仅仅设置一个time-out。1、如果该来的包没在定时器时间内到来，那么定时器超时会导致接收端发送一个RESEND，发送端收到这个RESEND就会对其中指示的位置之后的所有bytes进行重传。2、如果client发送给server的所有关于RPC的所有包都丢了，server也不会知道，这时的重传依然是因为client没有等到server的response而发送RESEND。3、如果没有收到对于RESEND的response，那么对重复发送RESEND。

最少一次的语义
这是作者提到的最后一个特点。传统的RPC协议使得RPC只传输一次，而Homa由于时connectionless的，所以server端并没有这些RPC的信息，即使request再来一次，server也会再执行一次。并且Homa还提供了RESEND机制，所以本身也可以控制Server重新发送。

作者之所以这么做的原因是，这样实现简单，而且允许server丢弃所有和不活跃的clients的信息。但是过多的重复进行会导致性能低下，所以作者的想法是，要么高层的应用允许这个冗余，要么过滤掉它，就像TCP实现一个流控机制一样。

以上是实验部分除外的内容。就我个人而言，此论文给我补了一些背景知识，并且这种短流设置优先级先走的想法也很容易想到，所以对我来说蛮有帮助。但是我还是有点不明他们的工作贡献为何很大，Homa总的代码为3660行C++代码，感觉也不算很大。总结：作者通过设置优先级队列的方式，让小message先走，降低了小message的延迟，而小message在数据中心中占的比例会很大，所以整体延迟有所提高，并且对于buffer也有很大优化，这个小massage先走和通过设置阈值让server回小bytes的response的机制缓解了TOR的buffer压力。