HotNets 2022系列论文解读——互联网再思考

第21届HotNets于2022年11月14日-11月15日在美国得克萨斯州奥斯汀召开。本次会议共收到104篇投稿，接收32篇论文，录取率为30.77%。

厦门大学SNG的同学们按照会议日程对论文内容进行了分期评述，本期介绍session2的论文。

Session2： Rethinking the Internet

The Case for an Internet Primitive for Fault Localization

William Sussman （MIT）; Emily Marx （UC Berkeley）; Venkat Arun （MIT）; Akshay Narayan （UC Berkeley）， Mohammad Alizadeh， Hari Balakrishnan （MIT）; Aurojit Panda （New York University）; Scott Shenker （ICSI and UC Berkeley）

＞背景

现代分布式应用程序基本都部署运行在云数据中心中的众多微服务和组件上，使用共享的云服务进行计算和存储。一个分布式服务可能需要多个分布式应用、各种网络交换传输设备、以及不同网络层上的网络协议共同协作来完成。而今天的大规模应用程序是由数千个软件组件组成的，通常作为微服务运行。这些微服务运行在云数据中心的虚拟机中，并通过虚拟交换机和网络功能使用物理网络。应用程序组件可以分布在全球不同的数据中心和云提供商之间，并在边缘位置和客户端端点上使用在内容分发网络（CDNs）中运行的组件。这也是为什么当观察到一个网络问题时，很难识别哪个组件有故障。在这些组件中的任何一个环节都有可能出现错误导致网络问题：比如无数的交换机、防火墙、网络路由器和连接它们的链路故障。本文提出了一种具有简单、标准化的互联网信息接口的跨层、跨域、跨应用的故障定位原语WTF来实现网络事故的检测定位。

＞WTF核心设计

利用health bits作为原语来表示网络组件自身的网络状态，里面携带的是有关网络故障的信息，网络事故可以通过追溯一系列的health bits来进行错误定位。

把网络系统看作一个（巨大的）图，图上最小的单位是元素，每个元素可以是影响分布式应用程序的观察行为的任何组件、系统服务、网络功能或设备。而一个图上的节点指在其中运行一个或多个元素的服务器或虚拟机。

图上的边表示元素间的交互关系，所以每个节点（包含多个元素）只知道自己域内的组件状态和相连的邻居节点的某些元素状态，即每个节点只有局部视图。

节点只能定义自身的health bits的语义和邻居节点的health bits状态而不知道邻居节点的具体语义，但通过这些观测到的状态就可以定位错误。

考虑到各种网络组件的差异性（包括软硬件复杂程度、性能情况），WTF不指定health bits该如何定义以及如何维护及利用，只提供了一种health bits可以传输用于错误定位的机制来探讨跨协议跨域跨应用的网络事故检测方法。

＞WTF用例

考虑下图的例子，这是一个多人游戏应用程序，有两个玩家（player 1和player 2），且需将他们的游戏直播给观众。Player 1在一个由云游戏服务提供的实例上运行游戏，而Player 2则在本地运行游戏。两个玩家都被连接到一个多人游戏服务器。玩家1的云游戏实例也连接到流媒体服务器，流媒体服务器为用户转换游戏视频和音频。如果玩家在执行一个动作和其效果对其他玩家可见之间有明显的延迟，玩家可能会报告网络问题。如果视频流滞后或质量较低，观众可能会报告网络问题。如例子中，观众报告了视频卡顿的问题，于是相应的网络组件（元素）开始收集属于视频流区域的元素的health bits（子图c），之后进一步分析这些组件的网络状态来定位错误，快速返回给开发者（子图e）。

＞个人观点

任何网络运行都可以抽象成一个连通图，如本文所述，图上节点是网络组件，节点/链路的故障情况会导致图的某些属性违反（比如连通性、min-cut、和最大最小流性质），这些性质的改变就是产生网络事故的原因。传统的网络事故诊断更像是在故障显示起点（如延迟过大的客户端）开展广度优先遍历来找根因节点/链路（因为不知道全局视图，即未知除了自己外的任一节点/链路是否有错），而health bits的做法好比是运行时周期性地让各个域维护自己的错误性状态并让邻居也知道，虽然仍不知全局视图，但这样在事故发生时可以提供一些先验知识来深度优先遍历网络图从而找到最可能导致错误的子树。

Tango or Square Dance？ How Tightly Should we Integrate Network Functionality in Browsers？

A. Davidson（Brave Software） M. Frei（ETH Zurich） M. Gartner（OVGU Magdeburg） H. Haddadi（Imperial College London） A. Perrig（ETH Zurich） J. Subirà Nieto（ETH Zurich） P. Winter（Brave Software） F. Wirz（ETH Zurich）

随着路径感知网络（PAN）的出现，应用程序如何利用新的网络特性的问题也随之出现。传统上，网络功能要么放在核心网络、中间件中，要么放在操作系统中。在新兴的路径感知网络技术的背景下，出现了一个有趣的问题：哪一层应该处理新的特性？本文作者认为，浏览器正在成为网络创新的强大平台，它可以承载各种复杂的服务，即使这些服务与具体业务高度相关。基于这样的想法，作者基于SCION路径感知网络体系结构实现了一个浏览器扩展原型，在不引入任何显著性能开销的情况下，证明了地理隔离浏览的可行性。

＞背景

SCION是一种自2009年开发的面向安全和路径感知的网络架构。SCION提供了对两个端点之间的多个路径转发的支持以及安全性的保障。基于SCION网络架构的特性以及其提供的服务，我们可以选择不同的路径进行数据传输，比如延迟最低路径、带宽最高路径、丢包率最低路径等等。也就是说，这些路径可以是不同属性要求下的最优路径，同时，我们也可以利用SCION的路径感知能力提供地理隔离等服务。本文针对SCION所提供的能力应该在哪一层进行应用进行了讨论，首先分析了路径感知能力在不同载体上（操作系统，App，用户）的使用针对不同指标的合适程度，如下图所示：

＞创新

浏览器是人们与Internet交互的主要媒介。2021年，有50亿人将网络浏览器作为桌面或移动的使用的一部分，其中32亿人使用Google Chrome，浏览器在PC端和手机端有着巨大使用规模，所以作者认为，在浏览器中使用SCION的路径感知能力是一个很自然的想法。作者认为：在Web浏览器中部署新技术可以最大限度地减少新手用户所需的配置和安装工作量。出于这种想法，作者在Brave浏览器中实现了一个基于路径感知网络的路径选择插件原型。

＞实现

如下图所示，在本文中，插件的设计可以同时支持BGP/IP网络和SCION网络。在用户使用BGP/IP网络时，浏览器插件不对用户请求进行拦截，当用户使用SCION网络时，则浏览器插件将请求转至一个轻量级的QUIC代理进行发送。

由于SCION网络并没有广泛部署，当用户开启了SCION网络选项时，如果用户同时开启了严格模式，则所有请求将通过SCION网络进行传输，如果目标地不支持该模式，则浏览器不加载该资源。在非严格模式下，不支持SCION网络的资源将会通过BGP/IP网络进行加载。

＞ 评估

从评估结果中可以看出，当添加拓展后，即使使用SCION网络进行网络资源的加载，也只额外消耗了很少的时间（大约30ms），但是却获得了路径选择的权利。

＞个人观点

利用浏览器使用路径感知网络的特性是一个有趣的尝试，虽然对用户来说，更加在意的一般都是延迟和带宽，但对于ISP和网页提供者来说，利用路径感知，路径选择，地理隔离等相关功能可能会产生许多好处（环保、经济价值）。值得一提的是，路径感知网络中的各项指标测量可能并不准确，但这并不妨碍它存在的价值和意义。

Sidecar： In-Network Performance Enhancements in the Age of Paranoid Transport Protocols

Gina Yuan（Stanford University）， David K.Zhang（Stanford University）， Matthew Sotoudeh（Stanford University）， Michael Welzl（University of Oslo）， Keith Winstein（Stanford University）

＞背景

对于高延迟卫星链路、具有大量ACK和频繁重新排序的Wi-Fi或蜂窝WWAn的路径，重复使用有线网络的超时重传或拥塞控制方案并不理想。许多网络通过在部署性能增强代理（PEP）加速TCP连接。在TCP连接的中间加入PEP可以更改特定子路径上的网络行为。然而，如QUIC这样的传输协议需要加密、验证报头和有效载荷，对中间件不透明，使得性能增强代理（PEP）无法提供与以前相同的帮助。

本文提出一种与现有底层协议松耦合的sidecar协议，适用于QUIC这样对中间件不透明的协议。sidecar协议的关键挑战是如何有效地表示底层连接的数据包，同时避免PEP存在的协议僵化问题。本文采用一种简明的数字表示——quACK（快速ACK），用于有效解码sidecar协议接收到的随机加密数据包标识符。文章实现了quACK，并讨论了quACK的三个应用：拥塞控制拆分、ACK减少以及在有损子路径上PEP到PEP的重传。

＞quACK设计

发送方发送集合（集合中的每个元素为数据包的标识符）到接收方，接收方收到集合，。接收方通过构造quACK，发送方解码quACK推断出，即丢失包的标识符。文章使用 straggler identification方法，将quACK的解码问题转换为幂和多项式求解。

＞应用

1）拥塞控制拆分

将端到端连接拆分为多个段使得PEP能够更好地调整其发送速率或在每个段上实施不同类型的拥塞控制方案。然而，PEP无法应用于端到端加密协议。quACK使得即使是端到端加密协议，也可以通过sidecar协议执行如PEP的连接拆分以进行拥塞控制。

客户端向代理发送quACK，代理向服务器发送quACK，每个段上以固定间隔（例如每RTT一次）发送quACK。每个段上的发送方能够准确地确定自上次quACK以来尚未接收到哪些数据包。Sidecar协议使用从quACK解码出的信息来调整下游段上的发送速率。例如，如果代理检测到大量数据包尚未接收，则可以以较慢的速率发送缓冲区中未转发的QUIC数据包。

2）ACK减少

使用quACK可以为端到端加密协议提供累计序列号ACK的功能，quACK不知道协议级别的序列号，但可以简洁地表示接收到的数据包。sidecar协议将quACK视为客户端ACK。代理不需要读取或修改QUIC包内容，客户端也无需参与sidecar协议。该协议可以使服务器更快地向前移动其发送窗口，而不是等待来自客户端的ACK。客户端还可以使用QUIC中提出的ACK频率扩展来发送更少的ACK，从而减少网络拥塞。

尽管这些quACK通常取代来自客户端的ACK，但端到端ACK具有sidecar协议无法实现的某些特殊功能。例如，端到端ACK可以传送显式拥塞通知（ECN）信息。此外，quACK不会反馈从代理发送到客户端过程中丢失的数据包。因此，服务器在大多数情况下仍然可以依赖quACK，并在需要重传时使用不太频繁的端到端ACK。

3）网内重传

两个路由器上的sidecar实例被静态配置为在它们之间的路径段上发生数据包丢失的情况下重新发送数据包。当两个路由器之间的RTT显著小于端到端RTT时，网络内重传可能是有益的。左侧的接收方代理向右侧的发送方代理发送quACK。发送方代理不需要读取或修改数据包内容，只需将数据包缓存在缓冲区中，以防需要重传。接收方代理生成和发送quACK的间隔是灵活的，理想情况下取决于丢包率。

＞评估

在一个quACK表示1000个已发送数据包的情况下，最多丢失20个数据包。其中，每个数据包使用32位标识符表示，一个quACK大小为82B，需要106us来构造，61us来解码。使用32位标识符时，数据包具有0.000023%的冲突概率（一个标识符映射到多个数据包的概率）。

＞个人观点

当前网络中以加密流量为主，加密协议QUIC是HTTP3协议中的重要协议之一，传统PEP不适用于加密场景。文章提出的sidecar协议解决了加密流量传输的性能增强问题，所提出的quACK构造和解码方法对加密数据包的识别具有启发性。quACK方法可以有效识别丢失数据包却不能完全替代ACK，协议不可知情况下是否还有可用于性能增强的其他信息值得进一步探索。

DIP:Unifying Network Layer Innovatios using Shared L3 Core Functions

Ziqiang Wang（Southeast University）， Zhuotao Liu（Tsinghua University and Zhongguancun Laboratory）， Xiaoliang Wang（Capital Normal University）， Songtao Fu（Tsinghua University）， Ke Xu（Tsinghua University and Zhongguancun Laboratory）

＞背景

IP协议为互联网的发展做出了巨大贡献，但是IP协议的固定分组处理阻碍了互联网的功能扩展。IP协议的广泛应用导致了目前的互联网架构单一且固定（只能使用IP协议），无法适应核心机制的创新，例如无法动态部署更适合移动场景的寻址模型（移动场景更适合非IP的寻址模式）。为了解决互联网的协议僵化问题，网络社区提出了各种新的L3协议，以更好地支持网络层的各种网络功能。本文提出了一种新L3协议DIP（Dynamic Internet Protocol，动态互联网协议）。DIP基于新L3功能原语Field Operation（FN），构建L3协议共享的通用网络功能核心。每个独立的L3协议可以被分解为多个FN的组合，同时可以组合各种FN来实现新的L3协议。

＞设计

DIP的基本头由四个字段组成：NextHdr、FN_Num、HopL和Packet Parameter。FN_Num表示数据包中定义的FN数量。每个FN由包头中的三个字段指定：FieldLoc、FieldLen和Operation_Key。FN读取和写入的实际数据包位置定义为 FN Locations（FieldLoc，FieldLoc：FieldLen）。Operation_Key表示需要对FN Locations进行的操作。

＞评估

本文在 Barefoot Tofino可编程交换机上实现了DIP原型，并对IP、NDN、OPT和NDN +OPT协议数据包的处理时间和开销进行了评估。

1）包处理时间

对于IP、NDN、OPT和NDN +OPT协议数据包，在包大小为128字节、768字节和1500字节三种情况下测试处理时间。以IPv4和IPv6报文的转发时间为基准。评估结果如下图所示。结果表明，DIP报文的处理时间接近于基线。由于MAC操作比较昂贵，所以OPT和NDN+OPT包需要更多的处理时间。

2）包头大小开销

DIP包头开销略大于基准协议， 如下图所示

＞个人观点

DIP利用网络可编程设备的发展，为网络功能的使用和定制提供了新的设计空间。这种思想就好像面向对象编程中的抽象类，报头规定了字段和字段处理函数的抽象。需要实现具体的协议时，就将字段和字段处理函数实例化，大大增加了网络协议的灵活性。

审核编辑 ：李倩