Paper List

这里收集一些我喜欢的 paper。按照 topic 分类，大概只会简单评价一下我觉得这篇文章有意思的原因，而不是尝试写读后感。

Congestion Control

• Restructuring Endpoint Congestion Control (pdf) 把所有拥塞控制算法归纳为 1) 收集 signal，2) 进行决策，3) 修改发送速率的统一 workflow，并尝试实现拥塞控制算法的 write-once, run anywhere。目标和方法看起来都非常美好，实现方式上我感觉硬拉到用户态进程去做有点没必要。以及 congeston signal cover 的还是不够全，例如 swift 要求的细粒度 RTT，不过 CCP 的框架结构定义得很好，扩展 signal 应该比较容易。
• Towards provably performant congestion control (pdf) 尝试用一个带若干参数的网络模型描述网络的行为，然后将拥塞控制算法描述为“缩小网络模型的参数空间”，很有意思的思考角度。并且做出了一个综合系统，通过网络模型的 spec 生成帕累托最优的拥塞控制算法。还没仔细读，不知道效果如何，但听起来就很 promising。感觉主要的限制（如果有）应该是网络模型不够真实，但我很喜欢这个方法论。
• Toward Formally Verifying Congestion Control Behavior (pdf) 挖坑。上面的文章引用的，应该有一部分 insight 来自这里。

Host Congestion

• Host Congestion Control (pdf) 将主板上的总线也看作一个网络，并且用拥塞控制的视角来看待总线带宽利用不足的问题，指出了非常 insightful 的理解与解决主机拥塞的方向。这篇文章指出 IIO buffer 占用是主机拥塞的一个拥塞信号，并且可以简单地通过 ECN 控制网络应用发送速率，或者通过 memory backpressure 控制其他（非网络）应用的访存速率。这个框架看起来比较初步，并且只在简单的 workload 下测试，但可以进一步扩展其他的拥塞信号和控制手段，看起来方向非常 promising。
• Understanding the Host Network (pdf) 同一个组的工作，对主机网络（主板上的总线构成的网络）进行更细粒度的建模，并且发现了两种全新的主机拥塞模式。有意思的是，某种意义上他们先“解决”了问题，再“理解”了问题。

Network OS

• NetKernel: Making Network Stack Part of the Virtualized Infrastructure (pdf) 通过 patch guest OS 来将 socket 调用传给 host，并通过 host 上另外的 kernel-bypass network stack（例如 mTCP）来处理这些调用，提升性能。这个劫持的位置很好，不用修改上层应用。

• Demikernel (pdf) 这篇文章指出 kernel-bypass I/O 库的现状缺少很多操作系统该做的事情（提供统一接口，提供应用间调度手段），因此需要一个 kernel-bypass OS 来解决 kernel-bypass I/O 库（如 DPDK/SPDK）的几个痛点：1) I/O 代码与设备强绑定，难以用统一接口操作异构设备，2) 没有易用的 zero-copy 接口和 3) 没有提供合理的调度手段，如 DPDK 要求应用独占内核。感觉干的事很重要，但是迁移已有应用的开销有点大，因为整个 I/O 接口都变了，需要重写应用。

• Making Kernel Bypass Practical for the Cloud with Junction (pdf) 扎实到恐怖的工作，无论是解决的问题还是解决的方法都是顶级。目标是支持单机起 4000 个未修改的 Linux 二进制应用而不带来性能下降，另有一篇 arXiv (pdf) 基于 Junction 实现 containerd 的原位替代。这篇文章最震撼我的部分就是它无需修改二进制文件，让我相信他能得到部署。方法是：1) 普通容器技术中多个进程在主机看来也是多个进程并且与主机共享 kernel，而 Junction 做了一个 loader，将同一个 Instance（类似于一个容器）的所有程序加载到同一地址空间内，每个 Instance 在 Host 看来只有一个进程（但可以有多个线程，以利用多核 CPU）；2) 这一 Instance 内跑了一个用户态 kernel 用来管理网卡和调度 Instance 内的多个程序，并且重写了 libc 来将所有的 syscall 重定向到这个用户态 kernel；3) 做了一系列调度的优化和 NIC buffer 的优化来解决 scale 到多 Instance 过程中遇到的挑战。还有一些安全方面的考虑，这里就不赘述了。最终测试了多个未经修改的 Linux 二进制文件，真是太酷了！

  一个有意思的问题是比较 Junction 和 NetKernel 的优劣。它们都实现了二进制兼容，并且都假设二进制文件执行在 Linux 内核上。我简单思考的结论是，两者的区别还是落在了容器和虚拟机的区别上。Junction 更像容器，只要求用户提供要执行的程序的二进制文件，而 NetKernel 针对虚拟机，即用户提供一个完整 kernel 的场景，因此带机量上 Junction 应该能更多（实际上 NetKernel 并没有针对带机量做优化）。直觉上 NetKernel 需要过硬件虚拟化因此更慢，而 Junction 甚至因为同一 Instance 内的程序共享地址空间能省一些 context switch 时的 TLB miss。并且 Junction 对应用语义了解得更全面，因此能做更细粒度、更高效的调度。但同时也可能有 noisy neighbor 问题？总之隔离力度比虚拟机方法弱一些。