清华大学计算机网络技术前沿研讨会 参会纪要

清华大学计算机网络技术前沿研讨会 参会纪要

参会人：李白杨，马小青

10月24日参加了清华大学计算机系举办的网络技术研讨会暨 “计算未来“ 博硕论坛063期，共有 两位企业嘉宾和七位来自清华计算机系的博士生 分享其工作。会议议题内容整理如下：

附回放地址。

1. 旷视 Brain++ 计算平台体系架构

报告人简介

巩向锋，旷视 Brain++ 计算平台技术负责人，多年云计算、基础架构工作经验，专注于解决人工智能领域的基础设施难题，打造业界领先的AI基础平台。

内容摘要

旷视 Brain++ 是由旷视研究院自主研发的新一代 AI 生产力平台，致力于帮助企业和开发者提升AI开发效率、规范生产流程。Brain++ 的核心能力包括数据梳理、清洗和管理能力，算力的共享、调度和分布式计算的能力，算法的训练、推理及部署能力。

主要内容

报告从Brain++ 架构、技术挑战和相关工作三方面展开。

【Brain++架构】

• Brain++ 以原始数据为起点，支持不同业务场景和训练方式对数据处理标注，通过机器学习、深度学习持续训练优化模型，构建对外提供服务的 AI 能力。通俗的讲，可将其理解为一个非标准/非传统意义上的云平台。

• Brain++ 底层为BIP平台，管理物理设备、网络及内部服务；上层功能服务包含计算、存储、网络/安全等，再往上基于AI Services 集成不同的功能，如数据集管理、标注；模型训练、管理等等。

【技术挑战/对应工作】

1. 算力永远不够

• 采用master/slave 结构，workerspcae master 的任务可以无缝衔接到 worker 运行，程序结束后 worker 自销毁；

• 提供组内优先级功能，临时出现重要任务时优先执行。

2. 数据供需：存储系统难以支持巨大的吞吐量

• 开发 Nori 海量小文件存储系统，需要时对其作加速，系统吞吐可达 4TB/s，约1亿张图片/s；

• 分布式数据供给

• 使用 RDMA，SR-IOV + OVS + HW offload 构建大规模高速网络，高吞吐，低延时

3. 其他：

1. 如何在保证用户体验情况下保证数据安全？网络代理、流量审计；

2. 如何管理成千上万实验？实验管理工具、结果检索比对；

3. 如何存储快速增长的各种数据？自研Overlay；

4. 如何在满足训练基础上又能部署服务？如何同时满足自用商用？

2. 腾讯云网络，构筑新型网络基础设施

报告人简介

王亚晨，腾讯云网络总经理， Linux基金会边缘计算开源社区董事， LoRa联盟董事会董事，中国通信标准化协会CCSA卫星通信技术委员会副主席。现负责腾讯云网络、物联网络，无线网络，5G与边缘计算等领域相关的技术与产品研发工作。

内容摘要

腾讯云网络作为新基建的重要组成部分，也是支撑云计算、大规模数据中心、边缘计算、物联网等领域发展的重要基础。本次分享的内容主要介绍腾讯高可靠、低成本的基础网络，以及腾讯利用SDN/NFV、智能网卡和可编程交换机等，打造腾讯高性能、敏捷灵活、易扩展的云网络系统，同时面向未来5G与卫星互联网的高速发展，腾讯云网络在不断拓展连接边界，实现云网融合等方面的新型网络基础设施平台与技术。

主要内容

主要介绍了腾讯云网络的发展及网络特性。

【基础设施规模】50+数据中心，1M+服务器，100TB+出口带宽储备，15EB存储数据量。

【网络架构演进】

• 1.0 ：万级，商业设备，人工运维；

• 2.0：十万级，商业设备，工具支持；

• 3.0：百万级，定制设备，路由控制；

• 4.0：千万级，开放设备，SDN/NFV，智能网卡/硬件卸载。

【高可靠低成本网络】

• 自研高可靠数据中心交换机，由封闭到开放，故障探测时间 90s 降低到 1s；

• 自研开放光网络，成本降低 25%，功耗降低 50%；

• 自研分布式路由器，支持亿级表项横向扩展；

【高性能高弹性网络】

• 高弹性：控制平台、转发平台、路由平台分离；

• 高性能：智能网卡、可编程交换机、用户网关。

【广覆盖、万物互联】

• 核心网、接入网都在建设中；

• 5G 边缘计算：本地引流降低时延，网络切片保证服务质量，可通过模组管理，LAN 实现安全接入和私网通信。

3. 【论文分享】PBC: Effective Prefix Caching for Fast Name Lookups

报告人简介

张楚文，计算机系2015级博士生，导师刘斌教授，主要研究方向包括内容中心网络、时延敏感网络等。

内容摘要

在这次讲座中，首先介绍相关的背景：为了提高内容中心网络中名字查找的速度，当前若干名字缓存策略的原理和优缺点。然后介绍我们的解决方案：附带位图的缓存策略 PBC。最后展示一下 PBC 性能和下一步的研究方向。

主要内容

分享发表于 2020 IFIP Networking Conference 的工作，主要内容包括以下部分：

1. 命名查找背景；

2. 基本缓存策略；

3. 作者提出的方案和查找更新的过程；

4. 实验结果及结论

【背景：为什么需要name cache？】

• 传统 IP 网络以 IP 地址寻址，内容中心网络和 NDN 中，采用以名字（字符串）作为路由的根据，存在一些问题：

• 例如采用最长前缀匹配的原则带来的复杂问题，名字长度不确定等，名字前缀表项大；

• 提出可以采用 Cache 来加速查找的方案，待解决 前缀依赖性问题 和 主表更新一致性问题。

【当前name cache方案】

• Atomic caching：最基本的方案。每次 cache 一个名字前缀时，会把它所有依赖的前缀都添加进去；每次逐出一个名字前缀时，把依赖于它的所有前缀都逐出；方案问题是缓存的利用率低，也会涉及一些同时加入逐出的问题。

• Leaf-only caching：简单一些 ，只考虑叶子节点。

• Exact caching：不缓存前缀，只缓存精确的名字；比较简单，但没有考虑依赖问题，同时cache利用率低。

• On-the-fly caching：创造新的虚拟的叶子前缀。

• 总结：基于前缀的方案，能够保证cache和前缀表一致性，缓存利用率比较低。

【PBC overview 核心思想+查找流程】

• PBC 方案：是否能在保留一个前缀的时候，把它以来的一些前缀用比较精简的叙事结构表示出来。即每保留一个前缀的时候，在每一个节点都会用一个 bitmap(bloom filter) 来保存一跳的字前缀的信息；同时保证了依赖性和利用率。

【PBC 问题：false cache miss】

• 引发原因与解决思路：

• bloom filter自身存在的 flase positive问题->增加 bitmap 长度，多采用 hash functions；

• 无法保证一定会有更长的前缀下使用了one-hot信息->使用更多跳的信息来存储它依赖的前缀信息。

【PBC 更新流程】

• 四类主表更新时，快速保证cache更新。包括：

• 修改名字前缀；

• 插入新的前缀；

• 杀出中间（non-leaf）前缀；

• 删除叶子前缀。

【实验设置+结论】

• 采用两个前缀表（一个直接的表和一个虚拟的表），采用一定局部性的流量进行冲击；

• cache hit ratio with cache size：PBC 保持最高的 cache hit ration；

• cache hit ratio with intermediate prefix ratio：PBC不受影响，保持稳定；

• cache hit ratio with suffic set size：PBC 没有变化，不受影响。

【总结】

• 利用了很小的 bitmap 去避免前缀之间的依赖情况；

• 可以提高cache utiliztion 和 cache hit ratio；

• 更新的操作简单，保证 cache 一致性；

• 实验结果表明，加入 PBC 的速度提高比率是最高的。

4.【论文分享】T-cache: Dependency-free Ternary Rule Cache for Policy-based Forwarding

报告人简介

万颖，清华大学计算机系2016级博士生，导师刘斌教授。研究方向是 SDN 数据平面的快速更新和查找。

内容摘要

首先介绍可编程网络中数据片面所存在的问题和面临的挑战，然后详细介绍我们提出的解决方案，可编程网络的高速查找引擎，最后会介绍我们在未来的工作计划。

主要内容

首先介绍了背景和相关工作，转发策略在不同网络中表现形式有所差异。高带宽、大规模、多匹配域的 SDN 网络中快速查找流表存在挑战。高速查找可分为软硬件两种解决方案。工业界多采用硬件查找的实现方式 TCAM 为标准。制约 TCAM 的因素有价格高、功耗大、更新速率慢等。解决方法包括将 TCAM 作为 cache 使用、优化更新算法。

接着介绍了主要工作，基于 TCAM 的高速规则查找。规则依赖化是问题的根源，需要在保证命中率的同时解决更新效率。规则独立化是大流驱动，需要检测出网络中的大流。作者采用了哈希桶的方式，同时添加时间戳以保证连续性。T-cache 整体架构图可参考 paper。

之后介绍了性能评价，作者采用了命中率和时间消耗作为指标。T-Cache 优于相比较的其他算法。

最后对工作进行了总结，通过规则独立化实现 TCAM 高命中率，同时简化了 TCAM 更新问题。后续会在可编程交换机上部署。

5.【论文分享】Abusing CDNs for Fun and Profit: Security Issues in CDNs' Origin Validation

报告人简介

郭润，计算机系博士生，从事网络安全方面的研究，侧重于对于Content Delivery Network平台的测量和安全性分析。

内容摘要

CDN 平台是互联网中的核心基础设施，通过全球部署其为网站提供了访问加速和 DDoS 防护。我们发现，CDN 提供了丰富的网站部署策略，但是却并未对源站进行所有权验证，这意味着一个 CDN 用户可以将第三方网站部署在 CDN 中。结合 CDN 的提供的丰富配置策略，恶意 CDN 用户可以利用 CDN 全球海量节点作为代理，进行一系列网络滥用，诸如端口扫描、绕过 IP 封锁和 DoS 攻击等。

主要内容

介绍发表于2018年IEEE SRDS 的工作：利用 CDN 服务在配置上的缺陷，滥用 CDN 服务。

【背景】

• 众多厂商提供CDN服务，CDN IP节点资源在全球达到数百万的量级；

• 当 CDN 厂商服务过度强调功能多样性和配置的便利性，伴随而来的是安全性的问题。

【CDN服务申请流程】

1. 注册 CDN 账号，申请服务；

2. 配置 CDN 源站 origin option；

3. CDN 给出源站对应的 CDN 子域名；

4. 配置 CNAME，配置 DNS 映射；

5. 用户访问域名，重定向到 CDN 节点；

6. CDN 作为一个代理，去源站取回访问内容；

存在的问题：CDN 没有验证申请者是否真的拥有origin option，可能会存在恶意 CDN用户（攻击者）滥用 CDN 服务的情况。

【不同CDN厂商的验证策略】

具体每个 CDN 服务提供商在源站的配置选项上有区别的：

• 有的 CDN 可以填任意的 IP 或者域名；

• 有的 CDN 意识到了该问题（Baidu，Cloudflare 要求不能填私有 IP），Cloudflare 还做了禁止填写的域名的黑名单

• 但大部分 CDN 不检测，攻击者有机可乘，把 CDN 作为一个代理池滥用。

【CND 滥用分类】

1. CDN 选项利用：CDN 服务提供了丰富的配置选项

• 构造 CDN 链，修改 HTTP 首部

• HTTP 首部重置

• HTTP 头部纂改

• 滥用端口设置：CDN可配置非80/443端口，借助 CDN 发起端口扫描/ 资源消耗攻击

2. CDN 代理功能利用

• 滥用转发功能：以 CDN 转发躲避网络审查

• 滥用 TCP 分段：利用 CDN 发起 DDoS 攻击

3. CDN 分布利用：借助广泛分布的 CDN 节点绕过站点封锁。

【滥用攻击特点及防御】

• 普通代理网络进行恶意行为，ISP 可以封禁，可利用 CDN 逃逸；

• 注册成本低，很少要求使用信用卡，即便需要往往作为注册验证；

• 建议 CDN 配置时提供申请者拥有域名/IP 的证明。

6. 【论文分享】Lies in the Air: Characterizing Fake-base-station Spam Ecosystem in China

报告人简介

张一铭，清华大学计算机系博士生，研究方向为网络空间安全，研究课题集中于数据驱动的安全研究以及网络协议安全研究，目前已在CCS、IJCAI、EuroS&P 等多个会议及期刊发表学术论文。

内容摘要

本次报告介绍针对伪基站诈骗短信生态系统的研究进展。通过采集真实世界中的伪基站短信数据集，从宏观层面揭示伪基站的短信发送特征，从微观层面研究了伪基站短信生态系统的组织结构，以及其诱捕用户、逃逸检测的策略。

主要内容

介绍发表在 CCS'20 的研究工作。

首先介绍伪基站及其工作原理。问题根源在于，GSM（2G）网络在设计时缺乏身份验证机制，而终端设备需要兼容 2G 网络，攻击者在发起攻击时只需将受害者终端降级到 2G 网络便可实施攻击。前人的研究工作集中在检测伪基站设备，但对于背后的生态系统（多少人使用伪基站、使用伪基站做了什么）缺乏研究和测量。

然后介绍了主要工作，从真实世界收集的伪基站数据集（与360手机卫士合作，主要针对短信内容）分析内容（做了什么）以及对垃圾短信 Campaigns 做迭代聚类分析。通过对数据内容的分析，作者发现：

• 伪基站发送短信内容和短信网关内容相比恶意性明显提高；

• 伪基站 Spammers 工作辛苦，不分工作日和周末；

• 国内主要集中在成都和广州；

• 在数据采集时间范围内（97 days），国内超过 10w 移动设备收到伪基站短信，观察到3000+恶意域名。

对 Campaigns 的观察，作者发现：

• 大部分存活时间短，灵活使用逃逸策略；

• 分工不同，有服务外包等行为，不同 Campaign 间可能会共用模板。

最后，给安全社区提出了建议，希望研究能够引起重视并改进应对策略。

7.【论文分享】A Unified Architecture for Accelerating Distributed DNN Training in Heterogeneous GPU/CPU Clusters

报告人简介

江逸敏，计算机系网络所五年级博士生，导师是崔勇教授。研究方向是分布式机器学习，主要研究成果发表在 OSDI，TON，ICDCS，ICNP 等国际会议和期刊。

内容摘要

介绍一种面向异构集群的分布式深度学习训练架构，通过机器间、机器内以及CPU瓶颈优化等设计上的创新，大幅度提升现有深度学习分布式训练的性能，在256 GPU 的规模下，相比于业界广泛使用的 All-reduce 架构，能够实现高达84%的加速效果。

主要内容

介绍发表于2020年 OSDI 的工作，面向异构集群特性的分布式训练加速。

【背景：DNN 与问题陈述】

• 从ResNet，到 BERT，再到 GPT-3，在效果提升的同时，面临着模型参数越来越大导致训练时间越来越长的问题。采用分布式训练非常必要；

• 分布式训练一般采用 Data-parallel 方式：每张卡针对不同的数据有一个完整的模型，在 FP 和 BP 过程中，卡与卡之间进行同步梯度的通信，用更新之后的梯度去进行自己参数的更新；

• 关注：通信阶段，参数更新阶段。

【基于Data-parallel的两种主要模式】

• All-reduce：all workers同构，使用collective communication去交换梯度；

• Parameter Server（PS）：CPU 与 GPU 的异构二部图，GPU workers+CPU servers，worker push gradients+ pull parameters；

【存在问题及解决方案】

1. Sub-optimal Inter-machine Communication，机器间

• 对于异构集群，GPU Machines 使用all-reduce->cannot leverage CPU machines；

• GPU Machines使用PS->may create traffic hotspot when CPU not enough；

• 现有架构对异构集群的特性没有做很好的支持。

  BytePS 解决方案：提出了一个最优的机器间的通信策略，可以统一 all-reduce和PS两种架构。

2. Sub-optimal Intra-machine Communication，机器内

   BytePS 解决方案：机器内部进行优化，加速机器内部的多卡通信。

• 尽管网卡带宽不断提升，但现有解决方案会产生内部PCIe的竞争，使得无法很好地利用网卡的带宽；

3. The CPU Bottleneck，CPU瓶颈问题：CPU不能满足网络速率

   BytePS 解决方案：提出 Summation Service，把梯度聚合放在CPUs上，把参数更新放在GPUs上。

【应用与部署】

支持TensorFlow，PyTorch，mxnet，易于使用；与字节有合作应用。

【效果验证】

多个 CV 和 NLP 模型中，远超过 all-reduce 和 PS。

8.【论文分享】NetView: Towards On-Demand Network-Wide Telemetry in the Data Center

报告人简介

林耘森箫，2017级直博生，研究方向是数据中心网络遥测技术。读博期间累计发表6篇论文（其中，在清华列表里的一作长文有3篇），目前正在与互联网公司合作，推进网络遥测相关学术成果在工业界落地，有一项发明专利已进入实审阶段，读博阶段获得过人民网奖学金、博士生暑期实践奖学金。

内容摘要

首先介绍网络遥测的基本概念、研究背景和研究现状。然后，分享已发表的一篇网络遥测研究工作，详细介绍该工作的设计思想、技术细节、以及实验结果。

主要内容

介绍发表于2020年Computer Networks 的工作。学术界和工业界为了寻求更强大的网络中心测量技术，提出了一种新型、细粒度、实时、自动化的测量技术，网络遥测。

【背景】

• 数据中心管理员为了进行网络遥测，需要对网络进行持续的监控，特别是全网范围内的监控；

• 网络监控需要持续的测量和分析，其作用包括：诊断网络性能下降，网络运维，故障排查，网络规划，攻击检测等；

• 随着业务需求的多样化和网络新技术的出现，数据中心网络日益复杂，网络中心host number，bandwidth和switch number迅速增长；使得数据中心中进行网络测量和运维愈发困难；

• 传统网络运维方法（ping, traceroute, SNMP, iperf, tcpdump, netflow) 测量粒度粗，开销大，覆盖范围有限，无法满足增长的网络运维需求。

【现有网络遥测分类与各自不足】

Passive network telemetry (Switch-based)：依赖于数据包携带遥测数据，或者由交换机上传遥测数据，可以提供业务流量的监控信息；无法获取细粒度的全网范围视图or产生海量遥测数据造成巨大带宽开销。

Proactive telemetry (Endpoint-based)：通过端系统主动发送探针来获取遥测数据；仅支持专门的遥测应用、需要大量服务器生成探针。

【动机】

• 传统方法数据冗余且无法满足管理员的遥测需求；

• 设计需求

1. 按需网络遥测框架：管理员按照自顶向下的模式来描述遥测需求，遥测系统将管理员的意图转换为底层的网络探针，使得上传的遥测数据是管理员需求的网络数据；

2. 遥测系统满足full coverage；

3. 遥测系统满足high scalability。

【NetView 框架】

针对上述需求，作者提出了新型主动网络遥测框架 NetView，包括四个部分：遥测服务提供器，遥测协调器，遥测收发器，遥测分析器。

具体流程为：

• 遥测应用通过遥测服务器包容的API进行各种遥测查询；

• 遥测服务提供器转换成相应的探针，随后遥测收发器发送和接受探针；

• 遥测应用通过遥测服务提供器获取遥测报告。

【其他设计】

• 提供遥测 API，简化管理员的遥测意图表达；

• 提出了新型的探针设计以及相应的交换机操作，支持可编程数据平面；

• 设置遥测对象、转发对象阈值，保证探针能够返回遥测服务器；

• 总结数据中心网络拓扑共性，确定最优探针路线规划；

• 提出三个探针更新的算法以满足实际需求。

【实验验证】

• 覆盖范围广：NetView 只需要一台遥测服务器即可为拥有上千台交换机的数据中心网络实现全覆盖遥测；

• 高拓展性：与其他主动遥测相关工作相对比，NetView 将带宽的占用减少了两个数量级；

• 高效扫描：NetView 只需要几秒钟时间就可以为大规模数据中心网络生成探针；

• 适当资源消耗：NetView 仅消耗遥测服务器上的少量资源，不会让遥测服务器成为资源瓶颈。

9.【论文分享】MultiLive: Adaptive Bitrate Control for Low-delay Multi-party Interactive Live Streaming

报告人简介

王子逸，清华大学计算机系博士生，主要研究方向是低时延流媒体传输的测量和优化。

内容摘要

介绍一个面向多人互动直播的自适应码率调节算法。通过对多人互动直播场景下主播端的码率合理调节，统筹考虑各种约束条件，最大化主播的用户体验，完成实时的交互。

主要内容

介绍发表在 INFORCOM'20 的工作。

首先介绍了背景，多人直播的用户体验不能让令人满意，自适应码率算法（ABR） 是一个优化用户体验的重要方法，核心思想是根据网络及缓存情况动态选择码率。在多对多的场景，设计一个自适应的码率算法有如下挑战：

1. 接收端的 buffer 需要维持在比较小的范围；

2. 算法同时要决定收发码率，传统的 ABR 算法仅由接收报文端确定；

3. 不同用户间的需求不同，主播和观众需求不同。

接着介绍了多人收发的架构。发送端使用 SVC 可扩展编码，server 端运行自适应算法，接收端可根据情况选择快/慢播。

然后介绍了设计的自适应算法。输入为各主播缓存容量及上下行吞吐的预测值，输出为码流数目及码率值。具体包括非线性规划模块、反馈调节模块和码率聚类模块：

• 非线性规划模块：统筹考虑 buffer 和带宽的约束，优化目标为 QoE，约束包括主播容量、上下行带宽的限制；

• 反馈调节模块：消除测量和建模过程中的系统误差，包括比例控制器和积分控制器用于矫正；

• 码率聚类模块：聚合标准和距离使用 QoE。

最后介绍了算法测量评估，使用了两个数据集，评价指标包括码率、码率抖动、卡顿时长和延迟。对比了5个其他算法，QoE 有明显提升，在保证视频流程播放的前提下能够保证画面质量。