核心贡献

BufScope，一个高覆盖率的请求事件监测系统，其目的是在请求的端到端数据路径中以一致的请求级语义捕获大多数与请求延迟异常（RLA）相关的事件。
缓冲区建模：BufScope将请求的数据路径建模为一个缓冲区链。并根据缓冲区的不同属性来定义RLA相关的事件，实现端到端（跨缓冲区）。
为了实现捕获事件的一致语义，BufScope设计了一个简洁的请求级语义注入机制，使网络中捕获的事件具有受害者请求的ID（在数据包头的末尾插入第一个请求头（如果它在有效载荷中）的偏移量）。offload到智能网卡上，以降低开销。

背景

现有的性能或延迟监测工具远远不能满足前面诊断RLA的要求。具体来说，尽管分布式应用性能跟踪工具[9-16]可以提供任何请求级的时序数据，但它们不能捕获应用层以下的请求事件；网络性能监测工具[8, 17-25]可以捕获发生在网络堆栈或底层网络的流级事件，如延迟ACK、丢包和路径改变，但捕获的事件没有请求级的信息，因此在应用和网络中捕获的事件不能被关联。

BufScope的主要思想是将大多数RLA转化为缓冲区相关的异常事件，监控请求端到端数据路径中的所有缓冲区，并以一致的请求级语义捕获所有缓冲区相关的异常事件。

RLA会严重影响应用性能的原因是，一旦逻辑处理RPC的速度慢于网卡带宽（本实验中为50Gbps），大量的数据包就会堵塞网卡缓冲区并被丢弃，导致网络堆栈重新传输大量数据包并放慢速度，从而导致性能严重下降。

buffer chain建模

挑战：将各种Layer-7框架的数据通路建模为统一的缓冲区组成。建模为：

host buffer：维护来自/到应用程序的消息，以及分解消息形成的数据包（或将被构建成消息的数据包）。此外，一些应用程序也有缓冲区，如MessageQueue
nic buffer：发送端网卡缓冲区保持从传输层交付的数据包，并定期将数据包排入网络。同时，接收端网卡缓冲区经常存储来自网络的数据包，并等待终端主机网络堆栈拉取数据包或主动将数据包写进主机内存
switch buffer：网络交换机缓冲区保留数据包进行交换，一旦数据包不能即时转发，即数据包将在连接所选下一跳的端口的出口队列中被缓冲或丢弃。

事件定义和生成

挑战：如何彻底分析所有类型的缓冲区，并分别为它们定义事件。虽然存在各种类型的缓冲区，但它们可以根据三个关键属性进行分类：priority awareness、order sensitivity和enqueue feature。

priority contention：一个具有多个队列的缓冲区，是否在不同的队列中保持严格的优先级。低优先级队列中的数据包将不得不等待高优先级队列的耗尽。否则，数据包的排队遵循FIFO原则（即优先级无意识）。
order sensitivity：缓冲区在弹出数据包进行后续处理之前，是否保持到达数据包的强顺序。
enqueue feature：主要是对后续数据包的处理上。有损和无损缓冲区的Enqueue feature是不同的，一个丢掉了后续包，另一个会暂停上游交换机。

定义了几种事件，这些事件并不是相互排斥的

优先权争夺。这种类型的事件在优先级感知缓冲区（即多级优先级队列）中被触发，当较高优先级队列的长度超过一定的阈值，长时间阻塞低优先级队列的数据包。不适当的优先权分配可能会导致RLA[46]。相反，FIFO缓冲区总是先转发较早到达的数据包，不会出现这种事件。
失序。这种类型的事件是在顺序敏感的缓冲区中触发的，如TCP接收缓冲区。数据包必须按照发送时的顺序传递给应用程序。也就是说，顺序敏感缓冲区已经收到的数据包必须在收到先前发送的数据包之前被延迟。相比之下，对顺序不敏感的缓冲区没有失序的事件。
丢弃。这个事件发生在有损缓冲区，当队列即将满员或已经满员时。数据包掉落会招致数据包重传，并可能导致RLA。
暂停。这种类型的事件发生在无损缓冲区。一旦下游交换机的缓冲区占用率超过一个特定的阈值，那么下游交换机就会向上游交换机发送一个暂停信号。后者将暂停数据包的转发，直到收到RESUME信号。这增加了暂停的数据包的延迟。
拥塞。这种类型的事件可能发生在任何种类的缓冲区。拥塞被定义为排队延迟超过阈值的情况，而不是由于PAUSE。这可能是由上游和下游处理或传输速率不匹配造成的。

事件的生成：主动监测

在终端主机和SmartNIC中，软件中的事件检测是直接的。为了减少事件检测对应用性能的影响，BufScope的代理守护进程以异步方式执行磁盘写入。然后，代理守护进程将事件日志批量发送给事件收集器。
在可编程交换机中，事件检测需要完全在数据平面中实现。遇到暂停或丢弃的数据包分别在入口管道和MMU中检测。对于优先权争夺和拥堵，我们通过INT（带内网络遥测）[47]记录队列的长度、入口和出口的时间戳，并判断数据包的排队延迟和长度是否超过阈值。在检测到受害者数据包后，出口代理利用绽放过滤器将其汇总为请求级事件，以流量的5元组和请求ID（第3.4节）作为关键。然后，请求事件通过数据平面生成的数据包被发送到交换机控制平面。最后，控制平面将消除收到的事件中的假阳性，并将它们批量报告给事件收集器。数据平面中事件生成的大部分设计是在NetSeer[8]中提出的，我们只是将监测事件的粒度从流量改为请求。我们在此并不要求有什么新意。

request-level的语义注入

因为请求和数据包的拆分/合并关系，请求头可能在数据包有效载荷的任何地方，这使得商品交换机无法解析请求ID。

我们利用了请求ID和长度已经被打包在请求头中的事实。因此，我们选择在数据包有效载荷的开头插入第一个完整请求头的偏移字段（2字节）

此外，有效载荷的第一个数据段，即图4中的Req#1数据段，可能在当前数据包中没有相应的头，因为大的请求可能由多个数据包承载。因此，我们也应该保持Req#1数据的标识符。为此，我们总是在数据包有效载荷的开头插入ID字段（8字节），记录Req#1的ID。这要求我们保持一个有状态的变量，记录最近请求的ID。

诊断

首先，BufScope通过请求ID对事件进行关联，并向运营商报告开始和结束事件（可能是有罪的）。然后，由于阻塞时间也被记录在事件中，操作人员可以清楚地看到哪个事件是罪魁祸首，即使一个请求经历了多个事件。我们还阐述了应用程序如何从这些请求事件中获益。

优先权争夺。这种类型的事件表明RLA直接发生在当前的缓冲区。它表明具有较高优先级的队列被堵塞了。为了缓解这种类型的RLA，应用程序所有者可以提升其请求的优先级，或者尝试减少进入高优先级队列的其他应用程序的流量。
失序。这种类型的事件表明，数据包在以前的缓冲区或逻辑中被丢弃或迂回。例如，网络丢包和路径改变可能导致TCP接收缓冲区的失序。应用程序所有者可以向网络运营商寻求帮助，以调试网络去副故障、黑洞或随机丢包。另外，如果伴有丢包事件，请参考下一项。
丢弃。丢弃事件导致耗时的重传，这可能直接导致RLA。MMU掉线通常是由突发和乱发引起的。应用程序所有者可以考虑通过调度来优化流量模式，以减少TCP incast或拥堵的可能性。
暂停和拥堵。这些事件的发生是由于当前缓冲区或下游缓冲区的数据包调度缓慢。在这种情况下，BufScope可以识别对拥堵贡献最大的请求，即重度请求，因为重度请求会经历更多的拥堵事件。然后，云提供商需要评估网络结构和应用混合模型。