课程报告：拥塞控制平台的验证

13拥塞控制平台的验证1560000995丁彬彬摘 要: 随着摩尔定律的结束，通用处理器速度和网络链路速率之间的差距正在扩大。这一趋势导致了包括内核旁路软件和新兴的 SmartNIC硬件终端中新的数据包处理的“数据路径”的产生。另外，很多应用程序正在UDP上推出自己的协议（例如，QUIC，WebRTC，Mosh等），形成与传统内核TCP堆栈不同的新数据路径。 所有这些数据路径都需要拥塞控制，但它们必须单独实现，因为不可能重用内核的TCP实现。本文验证了将数据通路中的拥塞控制移动到单独的代理中。这个我们称之为拥塞控制平面（CCP）的代理必须提供一个高性能的拥塞控制API以及一个数据路径设计者实现和部署CCP的规范。关键词:CCP 数据路径 高性能 APIVerification of congestion control platform156000995DingBinbinAbstract: With Moores law ending,the gap between general-purpose process or speeds and network link rates is widening.This trend has led to new packet-processing “datapaths” inendpoints,including kernel bypass software and emerging SmartNIC hardware.Inaddition,several applications are rolling out their own protocols atopUDP (e.g.,QUIC,WebRTC,Mosh,etc.),forming new datapaths different from the traditional kernel TCP stack.All these datapaths require congestion control,but they must implement it separately because it is not possible or euse the kernels TCP implementations.This paper confirms moving congestion control from the datapath into as eparateagent. This agent, which we call th econgestion control plane(CCP), must provide both an expressive congestion control API as well as a specification for datapath designers to implement and deploy CCP.Key words: CCP Datapath Expressive API1 引言传统上，应用程序通过套接字API使用操作系统提供的网络堆栈。然而，最近，由于网卡提供了更多自定义功能，如内核旁路，并且随着应用程序，开发人员需要来自网络的专用功能（指的是为应用程序和网络硬件之间的数据移动提供接口的模块）作为数据路径。数据路径的例子不仅包括内核，而且还有内核旁路和新兴的可编程网卡。数据路径的激增为部署拥塞控制算法带来了重大挑战。对于每个新的数据路径，开发人员必须重新从头开始重新实现他们所需的拥塞控制算法 - 这是一项艰巨且乏味的任务。例如，在英特尔的DPDK上实施TCP是一项重要的任务. 随着新硬件加速器和可编程网卡的出现，这种情况会恶化，因为许多这样的高速数据路径放弃了性能编程的便利性。同时，拥塞控制算法的多样性-传输层的一个关键组成部分继续看到创新和发展 - 使得支持所有数据路径中的所有算法变得更加困难。仅Linux内核就实现了十几个算法，并且仅在过去几年出现了许多新的提议。随着硬件数据路径变得越来越广泛，继续沿着当前路径走下去将会侵蚀拥塞控制算法的丰富生态系统，因为NIC硬件设计师往往只将少数几种方案烧入数据通路。因此，有人认为现在是时候为终端拥塞控制设计一个新的与数据通道无关的架构。他们建议将拥塞控制与数据路径分离，并将其重定位到一个单独的代理，我们称之为拥塞控制平面（CCP）。CCP作为用户空间程序运行，并与数据路径异步通信，以指导拥塞控制决策。他们的目标是确定一个狭窄的拥塞控制API，开发人员可以使用它来指定灵活的拥塞控制逻辑，并且数据路径开发人员可以实现以支持各种拥塞控制方案。这种狭窄的API使拥塞控制算法和数据路径能够独立发展，提供了三个主要优势：1.写一次，到处跑。通过CCP，拥塞控制研究人员将能够编写单一软件并在多个数据路径上运行，包括那些尚未发明的数据路径。此外，数据路径开发人员可以专注于实现一组标准原语（其中许多已经在当前使用），而不必担心持续演进的拥塞控制算法。一旦使用CCP API 实现算法，在新的符合CCP的数据路径上运行将会自动进行。2.算法将使开发和部署新方案变得更容易。 这将缓解实施和评估新算法的过程。此外，算法开发人员可以自由使用强大的用户空间库（例如神经网络），并专注于其方法的细节，而不是学习低级别的数据路径API。3.高性能。随着NIC线路速率稳步上升到100 Gbit / s及更高速度，需要将传输层数据包处理卸载到硬件以节省CPU周期。与在硬件中硬编码拥塞控制算法的解决方案不同，例如，从数据路径中去除拥塞控制将实现更丰富的拥塞控制算法，同时保持快速数据路径的性能。而我所做的主要工作就是根据ANarayan等人的研究报告1验证拥塞控制平台，使用平台中的各种算法。2 相关工作2.1 架构介绍CCP的系统架构（图 1) 由三部分组成：拥塞控制算法，CCP代理和对数据路径的CCP修改。在下面的讨论中，将前两个组件一起称为“CCP”。该架构不会修改它们之间的API 应用程序和数据路径（例如，POSIX套接字）。图1 ccp的系统架构只有在拥有大多数拥塞控制算法所基于的通用基元集以及哪些数据路径可以高效实现时，设计流级CCP CCP才是实用的。在表中1,确定了一组控制动作和数据包测量方法，可以实现各种拥塞控制算法。表1 经典和现代的拥塞控制算法的测量和控制方式因此，对于每个流程，我们都要求数据路径能够维护(1) 一个给定的拥塞窗口;(2) 分组传输的给定速率;(3) 数据包级往返时间的统计数据包，数据包传输速率和数据包丢失以及指定的功能。 实际上，今天存在的许多数据路径在内部实现（或可以实现）这些原语.使CCP符合这种数据通路只涉及使这些原语可由CCP进行外部编程、控制。拥塞控制算法通过以下两种方式之一来指定发送速率：通过直接设置速率或设置拥塞窗口（CWND）或者该窗口限制允许的数据包数量。 2.2 初步评估：（一）CCP是否改变了当前算法的表现？图2将1 Gbps链路上的TCP Cubic的拥塞窗口演变与10毫秒的RTT和1 BDP 的比较.他们两者的表现是相似的。Linux实现的RTT利用率达到了94.4延时为15.8ms，CCP实现的为95.4和16.1ms。(a)CCP Cubic图 （b）Linux Cubic图图2 基于CCP的Cubic实现和Linux内核实现的窗口动态比较（二）CCP是否改变了当前算法的性能？CCP引入batching的潜在缺点是对链接条件变化的反应迟钝。在图中3我们开始了60秒的CCP 或Linux NewReno在时间0流动.20秒后，开始一个相同类型的竞争流。两种实现都表现出类似的收敛动态.(a) CCP NewReno (b) Linux NewReno 图3 基于CCP的NewReno实现和Linux内核实现的反应性比较（三）CCP会浪费CPU周期吗？ CCP可以通过启用数据包的批处理来节省周期。 但是，更值得关注的是IPC开销会消耗额外的CPU周期。 图4显示了在10 Gbps链路上CCP 和Linux内核之间实现吞吐量的差异。正如所料，在启用NIC卸载（分段和接收卸载）的情况下，CPU不是瓶颈，并且两个系统都使NIC饱和。在发送方禁用分段卸载的情况下，CCP比内核实现更高的吞吐量。这是因为CCP通过通用接收卸载（GRO）发送稍大的突发，导致接收器处理更有效率图4 分别启用和禁用网卡卸载（TSO，GRO和GSO）的吞吐量比较3 研究动机该项目主要针对MIT网络研究组提出的拥塞控制平面机制进行验证。4 具体方案4.1 安装步骤4.1.1 内核环境安装第1步：安装内核编译环境，具体如下：sudo apt-get install libncurses5-dev gcc make git exuberant-ctags bc libssl-dev 第2步：下载支持CCP的内核，具体如下：git clone /ngsrinivas/linux-fork.git/注意：内核下载一定要选择“nimbus”分支)第3步：配置内核，此处直接拷贝已有相同内核的配置，具体如下：cp /boot/config-uname -r* .configmake menuconfig/“保存即可”第4步：编译内核，具体如下：make (make -j2)第5步：安装内核，具体如下：sudo make modules_install install (su -c make modules_install install)/注意：安装完成后需要编辑“/etc/default/grub”，注释掉“GRUB_HIDDEN_TIMEOUT_QUIET”，并执行“sudo update-grub2”4.1.2 GO语言环境安装第1步：下载GO语言安装包，直接用下面的链接可直接下载：/doc/install?download=go1.10.1.linux-386.tar.gz第2步：安装GO语言，具体如下：tar -C /usr/local -xzf go1.10.1.linux-386.tar.gz第3步：配置环境变量，Ubuntu修改“/.bashrc”文件，在末尾添加如下内容(根据自己需要配置)：export PATH=$PATH:/usr/local/go/binexport GOPATH=/home/networksim/GO /GO工程的工作目录第4步：更新环境变量使go语言可用source /.bashrc4.1.3 CCP用户代码编译第1步：在“/home/networksim/GO”建立src文件夹，并将CCP的用户代码(/mit-nms/ccp)放入其中第2步：执行如下步骤进行依赖包下载(无法下载的处理见：/zhuxinquan61/article/details/78238592)和CCP编译，具体如下：go get ./.make第3步：运行测试./ccpl -datapath= -congAlg=4.1.4 bug修复第1个bug：修改“tcp_ccp.c”中的下列函数static u64 ewma(u64 old, u64 new) u64 rtn;if (old = 0) return new;rtn = (new * CCP_EWMA_RECENCY) + (old * (CCP_FRAC_DENOM-CCP_EWMA_RECENCY);do_div(rtn,CCP_FRAC_DENOM);return rtn;/return (new * CCP_EWMA_RECENCY) +/(old * (CCP_FRAC_DENOM-CCP_EWMA_RECENCY) / CCP_FRAC_DENOM; 第2个bug：修改用户层代码，ipc目录下的“bench_test.go”中的下列代码：func BenchmarkMeasureMsg(b *testing.B) i,err := testSetup(false)if err != nil b.Error(err)returnoutMsgCh, _ := i.ListenMeasureMsg()for k := 0; k b.N; k+ i.SendMeasureMsg(testNum,testNum,testDuration,testNum,testBigNum,testBigNum,)select case _ = -outMsgCh:continuecase -time.After(time.Second):b.Error(timed out)4.2 测试安装完毕之后，我们需要用到测量带宽的工具iperf3和控制网络状况的工具linux带的traffic control工具。具体测试步骤如下：（1）使用tc工具控制网络的延时或丢包。（2）运行拥塞控制平台脚本。（3）用iperf3测量带宽。5 实验结果从23中下载拥塞控制平台的内核源码和模块源码。按照4中的方式去编译内核。编译定制内核时遇到了各种各样的问题，主要原因是系统版本不匹配，最后选择Ubuntu16.04.3 32位版本后，编译之后的内核却意外是损坏的，经再次编译后才编译出正常的内核。之后编译CCP的模块，装入编译好的模块，并配置所需环境如图5。从5中下载CCP用户空间的内容，编译后得到CCP的运行脚本。由于只在传输端起作用，所以只要在传输方安装CCP即可。双方都装上iperf3。图5 模块安装环境配置图5.1 服务器主机中一台虚拟机成为iperf服务器图6 iperf服务器设置图5.2 在测试主机中如图7先设置网络延时为100ms。图7 网络延时设置图运行BBR算法。图8 BBR算法运行图使用iperf3测得使用BBR算法时两台主机之间的带宽如图9。后面几个算法同理。图9 BBR算法下带宽结果图运行CUBIC算法。图10 CUBIC算法运行图图11 CUBIC算法下带宽结果图运行VEGAS算法。图12 VEGAS算法运行图图13 VEGAS算法下带宽结果图运行CCP算法。图14 CCP算法运行图图15 CCP算法下带宽结果图如图16使用用tc改变网络状态为7%的丢包图16 网络状态转化图再运行各项算法。运行BBR算法。图17 BBR算法下网络带宽图2运行VEGAS算法。图