OSDI18 Networking Session 工作简介

本次参加OSDI18负责的是第十个Session，该Session与网络相关。
本文简要介绍本Session的相关工作，其包括三篇论文，分别描述了将计算向数据中心迁移、利用有限的带宽结合DNN模型做高分辨率的视频传输 以及 将计算向网卡迁移的相关工作。

Splinter: Bare-Metal Extensions for Multi-Tenant Low-Latency Storage

Chinmay Kulkarni, Sara Moore, Mazhar Naqvi, Tian Zhang, Robert Ricci, and Ryan Stutsman, University of Utah

背景、动机与主要工作

在云存储领域，将计算和存储分离的方法已经有较为深入的研究，进一步提升性能遇到了瓶颈。这是因为传统的存储端只支持简单的查询与更新，而在服务器端进一步提升性能只能在极小粒度的操作上挖掘，这在目前单次操作耗费周期已经很小的基础上，提升空间非常有限。将存储服务器上的操作切分的很小虽然能通过优化大幅度提升吞吐率，但是会带来以下问题：

• 在 客户端 与 存储设备 之间有很多无用的数据传输
• 客户端有些计算（如图遍历）必须等待来回的数据传输，才能进一步处理数据
  Splinter则是将计算向存储设备迁移，希望通过此解决冗余的数据传输的问题，从而提供不受网络带宽限制的服务质量。总的来说Splinter拥有以下特点：
• 功能上：多用户可以动态的上传并安装不受服务器信任的扩展程序到服务器，然后在进行调用。
• 性能上：服务器提供不损害性能的软件层面的隔离，并大幅减少没有必要的round-trip，提供良好的吞吐率与延迟的保证。

从几个问题介绍Splinter的具体工作

下面通过几个问题，初步介绍Splinter的各种特性：

Q: 客户端怎么将扩展的代码发送到服务器端，如何进行远程调用执行？
A: Splinter的流程如下：

1. 用户发送利用Splinter支持的语言（RUST的subset）所写的源代码到服务器端。
2. 服务器安装（包括静态分析，保证各种安全性）代码，编译至服务器能运行的native code。
3. 用户发送请求，调用之前已经安装的扩展代码。
4. 服务器执行代码，并在结束后向用户发送处理结果。

Q: Splinter是如何使用最低的成本来隔离不用用户的扩展代码？
A: Splinter使用RUST在静态分析的时候进行隔离。若使用硬件隔离，则会由于服务器频繁地上下文切换导致性能下降。而由于Splinter在用户态运行，为了避免陷入内核态产生上下文切换，Splinter使用了Kernel-bypass的DPDK来避开陷入内核，而键值对的存储与操作由于本身是in-memory的数据库，不需要陷入内核态操作。

Q: Splinter如何在服务器端运行代码？

A: Splinter整体只有一个进程，共享一个地址空间。所有的用户安装的扩展程序都以一种轻量级的线程（generator task）的形式运行。
而每个核心运行了一个worker thread，该线程充当了调度器的角色。
除此之外，单独有一个dispatch task来从接收队列来创建对应的generator task处理请求调用的扩展的程序。
generator task作为轻量级线程，本身没有自己单独的栈，而是使用worker thread的栈进一步削减切换函数栈的开销，再加上本身只有一个地址空间，不存在切页表，所以在不同的generator task之间切换的开销非常的小。

Q: Splinter如何进行调度？
A: 调度由每核心的worker thread进行处理。Splinter采用非抢占式调度，当扩展中调用了存储操作API后会自动yield，其他情况下需要等待其主动完成后让出核心。针对耗时较长，或者恶意的extension，有一套watch dog机制来保证不会出现一直占有CPU的情况。其主要方法如下：

1. 将此任务迁移到一个单独用于运行耗时较长任务的核心上继续运行。
2. 重新在之前的核心上新起一个worker thread，并从之前的任务队列中将剩余的任务拿回来继续执行。
3. 被迁移的任务执行完慢的任务后，主动终结此进程。

Q: Splinter如何进行存取？
A: Splinter为内存中的键值对数据库，其提供了一系列存储的API，用户书写的扩展程序可以通过API来进行对KV数据库的存取操作。

Q: Splinter的routing策略如何保证本地性地同时避免出现hot-point？
A: Splinter 采用较为直接的routing策略：

• 通过NIC直接将来自特定的客户端的请求分发到特定的核上。
• 空闲的核心将从周围的核心偷任务放到自己的核心上来运行。

Splinter还有针对存取过程的优化等内容，详细见论文。

Splinter小结

Splinter的一个亮点就是避免了网络传输等瓶颈，避免了不必要的数据传输，将瓶颈放到了服务器的性能上。通过增加服务器数量以及服务器的处理能力即可改善Splinter的性能，相较于提高带宽或进一步优化服务器对单一操作的优化，简单提升服务器的数量以及性能为更简单的解决方案。
而Splinter也需要对应用进行修改，比较适合对数据进行图遍历，或简单数据处理的程序。对单一的查询程序，Splinter将不会带来任何好处。

Neural Adaptive Content-aware Internet Video Delivery

Hyunho Yeo, Youngmok Jung, Jaehong Kim, Jinwoo Shin, and Dongsu Han, KAIST

背景、动机与主要工作

传统改善网络串流传输质量的方法有一部分是在带宽上下功夫，找到符合当前网络状况的视频质量，从而更加有效地使用现有的带宽。使用该种方法视频质量提升的上限局限于网络带宽。
而另一部分使用各种压缩、解压缩算法，可以一定程度绕开带宽的限制，提供更好的服务。传统的压缩与解压也有一定的局限性，如针对视频这一类非结构化数据，在压缩到一定程度后不一定能准确地传输视频内容。
本篇论文的工作主要使用服务器训练了针对具体视频内容从低分辨率映射到高分辨率的DNN，从而达到仅传输低分辨率与DNN模型，最终实现播放高分辨率的效果。
使用DNN来做低分辨率到高分辨率的映射的理论基础是，在一个视频中，有很多元素是重复的，从而可以找到一个从低分辨率的该元素映射到高分辨率的特征。

系统主要设计

为了实现上述功能，该系统有一些关键设计。在下面将简要描述该系统设计中的几个关键点以及采用这种设计的用途等。

内容相关的DNN

在该系统中采用内容感知的DNN的具体原因上面提到过，在同一个视频中，重复的元素更多，更加有利于训练出，能准确地将低分辨率的该元素转换为高分辨率的该元素的模型。
而采用这种策略时，服务器会由于需要针对每个视频内容训练对应的DNN模型，这将会消耗大量的时间与服务器的资源。
该系统采用的解决方法是先训练一个通用的的DNN模型，然后再针对不同的视频内容训练不同的内容感知的DNN模型。这样会大大减少训练单独的模型所需要的时间。

可扩展DNN模型

为了应对客户端不同的计算能力，同时保证能在开始传输时，能尽使用视频加强的效果，该工作提供了一种可扩展的DNN模型设计。这种设计中最主要的思路是将不同layer的DNN划分到不同的块，每个块都可以直接将结果转到输出。客户端可以选择经过哪些块的处理，同时在刚开始传数据的时候，仅仅需要几个块就可以开始感受到DNN增强的效果。

上图为可扩展DNN模型设计的一个示意图，其中将480p转换到1080p的DNN如上图中黑框内所示。其中虚线的是DNN-model的第一个块，包含了基本的DNN-模型，而中间的均为不同数量layer组成的DNN-block，可以选择其中一些进行处理。使用的block越多，最后得到的效果越好。

Quality enhancement-aware ABR

而该系统面临的另一个问题是，在某一个时间点，该选择下载视频内容块还是DNN模型块能够使得当前提供的服务质量得到最大的收益。
该工作选择采用加强学习的方法来在这两个之间进行选择。

从一个例子描述该系统的工作流程

选用论文中的一个例子来解释一次视频传输增强的流程 (client-side only) 。

该流程如下：

1. 客户端将先下载服务器对于此段视频的DNN manifest文件。该文件中记录了服务器所能提供的各种DNN的相关参数。
2. 客户端将根据manifest提供的相关参数，在DNN处理器中生成各种模拟相应大小的模型，并执行test-run，来判断当前DNN处理器的处理能力，选择出适合当前计算能力的模型待后续下载。
3. 开始下载，客户端的RL bitrate-adaptive算法会选择当前下载Video chunk还是DNN-model chunk。
4. 一旦DNN-model中的第一个chunk下载好了，由于采用了scale-DNN的设计，DNN处理器可以利用该chunk开始进行低分辨率向高分辨率的转换。
5. 后续下载更多的DNN-model会进一步提升视频增强的效果。

该工作优势、缺陷与作者回应

该工作在技术上的创新点不多，其本质上是一个利用DNN对有一定模式的内容进行压缩的探索，在会场询问作者关于具体压缩率，作者回答大约在70%左右。
但是该工作利用有限的带宽传输高质量的视频内容的想法非常有趣，特别是在当今还没有网络带宽能够满足已经非常普遍的4k电视的视频串流。但是这个工作的主要瓶颈是其本质上是在客户端计算与网络带宽的使用上的一个trade-off，在节省带宽与消耗用户端资源与能耗中进行选择。很遗憾，在poster环节与作者交流时，他们并没有做任何功耗相关的工作，而功耗对于手机这个看视频需求最大的平台往往是最为重要的。
所以总的来说，这是一个比较有商业价值的工作，不过还需要很多工作将其变得可用。

Floem: A Programming System for NIC-Accelerated Network Applications

Phitchaya Mangpo Phothilimthana, University of California, Berkeley; Ming Liu and Antoine Kaufmann, University of Washington; Simon Peter, The University of Texas at Austin; Rastislav Bodik and Thomas Anderson, University of Washington

背景、动机与主要工作

最后一个工作主要是提供了一个新的编程模型，使得开发者能够方便地利用网卡空闲的计算能力，将一部分计算任务分配到网卡运行。
而这个工作主要动机是有以下观察：

• NIC的性能越来越强，可以将一部分计算负担分到NIC上进行
• 传统手工进行划分编程难度高，实现复杂
  本工作提出了一个新的编程模型Floem，其希望通过提供一个灵活的编程模型，将数据处理拆分成对数据流的多阶段操作，从而达到以下目的：
• 更易挖掘并行性，并且允许开发者灵活地分配运行位置
• 通过更方便地尝试不同组合，最终利用NIC达到最佳的性能

Floem编程模型的主要设计

Floem主要其由如下几个部分组成

• Element：数据流处理的基本单元
  数据流处理的一个步骤，需要定义输入、输出与处理过程。Element可以在CPU或NIC上运行。
• Segment：调度的基本单元
  组成程序的一个阶段，由多个Element串行组成。Segment 是迁移与并行的最小单位。如上图中，不同的Segment可以运行在CPU或者NIC上。而同一个Segment可以有多个实例，处理不同的pkt，从而并行化。

  1. Segment最终如何在CPU或NIC上执行？

     Fleom的Compiler会将这种针对数据流的应用程序编译为针对CPU以及针对NIC可以运行的的代码。对于原来的一个Segment中的一系列的Elements，会被编译成一系列的function call。编译器将原来连接到下一个Element的output port置换为一个function call。

  2. Segment如何进行划分？

     Segment的划分最终交给开发者决定。实现同样的功能可以使用不同的划分，最终可以尝试不同类型的调度方法。

• Shared state：提供全局对数据的访问抽象
  不同的Element之间可以通过Shared state共享一些变量。Floem只允许一个device上面共享变量，而不同device上面，还是需要通过队列来进行传递。
• Queue：在不同的Segment之间通讯。
  连接不同Segment的桥梁，不同的Segment通过Queue传输中间数据。而Floeam中的Queue是逻辑上的队列，在该层下面最终利用DMA处理NIC和CPU之间的信息传递，如下图所示：
  
  上图中Synchronization层提供了buffer，然后再异步同步到Host的memory中，从而避免阻塞。而为了维护这个buffer的一致性，提供了NIC上的一套机制，来保证NIC上的queue与Host memory中的queue的一致性。最后通过DMA与Host的memory进行同步。因此在NIC可以看到与CPU相同的queue，queue的主体存储在Host的内存，而NIC本地的内存可以用于cache这些queue，最终通过DMA来维持与Host内存中的一致性。

总结与作者回应

Floem提供了一种针对CPU和NIC合作的抽象与编程模型，能够让使用者轻松地在不同的搭配与策略中自由切换而无需改动大量代码。针对不同类型的程序，作者使用Floem将一部分计算放到NIC上执行，得出以下结论：

1. 对于存储密集型的应用，将NIC作为Cache能够显著提升性能。但是作者测试使用的NIC内存较大，而将NIC作为Cache在NIC内存较小的硬件上最终不会有很大收益。
2. 对于计算密集型的应用，则是将分配管理工作分到NIC上，尽量保持CPU上进行有效的复杂计算
3. 由于在NIC与CPU之间通讯的开销较大，需要尽可能避免两者之间通讯。
   另外在会场有人询问是否能够将TCP/IP协议栈offload到NIC上实现，作者表示这是一个非常有趣的future work，但是由于目前的NIC性能局限性与功耗的因素，效果不是非常好，还需要进一步尝试。
   总之，Floem提供的编程模型使得开发者能够轻易地在这些不同的策略中尝试，找到能使得性能最大化的配置。

更多与OSDI18相关论文介绍与会议相关信息，请关注公众号查看。