Latency Optimization in Real-Time Multimedia Transmission: Architecture, Progress and the Future
-
摘要:
实时多媒体传输是互联网最重要的应用之一，其系统对于传输延迟提出了很高的需求. 其中，延迟波动是延迟优化中最具有挑战性的问题. 然而，传统的尽力而为的传输服务在很多情况下无法满足实时多媒体传输对延迟波动的要求. 首先，阐述了实时多媒体传输面临的主要挑战. 其次，分析了如果要优化实时多媒体传输的延迟亟需解决的关键问题. 基于上述问题归纳了实时多媒体传输系统架构中的2个关键通路、5个核心组件. 围绕各个组件涉及的技术，梳理了代表性研究成果. 在此基础上，总结了面向实时多媒体传输及低延迟应用的研究分支，并对各研究分支优化算法与应用进行综述. 通过分析发现，延迟的尾部波动是实时多媒体延迟优化应关注的主要目标. 最后，提出了未来可能的研究方向.
Abstract:Real-time multimedia transmission is one of the most important applications of the Internet, with the applications such as videoconferencing, cloud gaming, virtual reality and so on. In the same time, the real-time multimedia transmission systems therefore demand high requirements for the end-to-end transmission latency. Among them, latency fluctuation is the most challenging problem in latency optimization. However, traditional ‘best-effort’ transmission services in the Internet cannot meet the requirements of latency fluctuations for real-time multimedia transmission in many cases. We firstly elaborates the main challenges faced by real-time multimedia transmission. Secondly, we analyze the key issues that need to be addressed to optimize the latency of real-time multimedia transmission. Based on these issues, two key paths (control path and data path) and five core components in the architecture of real-time multimedia transmission system are summarized. Around the technologies involved in each component, representative research results are summarized and discussed, especially for the research efforts in the recent years. Based on the analysis above, the research branches for real-time multimedia transmission and low-latency applications are summarized, and the optimization algorithms and applications for each research branch are reviewed. A key finding in this paper is that the fluctuation of latency is the key metric that research needs to work on. Finally, we also discuss and propose possible future research directions for the readers.
-
网络处理器（network processor，NP）是网络领域专用可编程芯片，提供高性能分组转发处理能力，广泛应用于路由器、中间盒、智能网卡等网络设备完成网络通信领域的各种任务，如分组处理、协议解析、路由查找、声音/数据汇聚、防火墙、QoS（quality of service）等[1]. NP是一种功能面向网络领域设计的集成电路. 与通用CPU类似，NP通常是软件可编程的，以提供高性能分组转发处理能力，可应用于多种网络设备和系统.
在5G、物联网、云计算等新技术发展的驱动下，新型网络应用，如虚拟现实、自动驾驶、网络直播等不断涌现. 这些应用导致互联网流量爆炸式增长，也使得NP的应用场景日趋复杂多样，要求NP芯片必须不断迭代，才能满足多样化网络应用在性能、灵活性以及服务质量保证等方面的差异化需求.
传统单片NP内置大量处理器核、高速缓存、加速器等异构处理资源，通常采用可配置的接口控制器，如以太网、SATA（serial advanced technology attachment）、PCIe（peripheral component interconnect express），以及复用高速串行总线口SerDes（serializer and deserializer），以提高控制器利用率和节省资源面积，为多样化应用场景提供敏捷可定制能力. 如恩智浦的LX2160A[2]，集成16个Arm®Cortex®-A72核以及针对L2/L3分组处理、50 Gbps的安全引擎、100 Gbps的压缩/解压缩引擎、流量管理和服务质量优化的数据通路加速单元，支持116 Gbps L2层以太网交换和支持100 Gbps速率的以太网控制器. LX2160A的24个SerDes通道可以配置为100 GbE/40 GbE/25 GbE/10 GbE速率. 然而SerDes设计常伴有各种串扰，如噪声、抖动等问题，影响流片成功率. 相对于通用多核而言，硬件加速器部分专用性高、应用难度大，同样需要多次流片才能成熟. 这些因素造成NP设计复杂、对工艺要求高、流片成本高、迭代周期长，难以与设备和应用需求的演进速度保持同步，敏捷可定制能力较弱.
随着摩尔定律、登纳德缩放定律失效问题逐渐凸显，以及芯片制程演进放缓，导致芯片设计难度更高、流程更加复杂、全流程设计成本大幅度增加. 国际商务战略公司调查数据显示，22 nm制程之后的每一代技术设计成本（包括EDA、设计验证、IP核、流片等）增加均超过50%，7 nm总设计成本约3亿美元，预计3nm工艺成本将增加5倍，达到15亿美元. 与此同时，NP相比于一般单片集成电路，设计更加复杂，设计、验证和管理成本的增加给片上系统（system on chip，SoC）的规模带来巨大压力，研制周期通常需要5年或者更长时间. 例如，博通公司的XLPNP，由于设计复杂、投片7次，投入近1亿美元. 由此可见，传统单片NP芯片研制在研发周期、成本、创新迭代等方面面临巨大挑战，越来越难以为继.
学术界和工业界的工作表明，通过使用先进的封装技术，即芯粒（Chiplet）技术，将多个异构芯粒在封装级紧密集成，如CPU，FPGA（field programmable gate array），是解决摩尔定律和登纳德定律失效的一种有效途径. 通过这种方式，开发团队可以将芯片功能和技术发展路线解耦，使用最先进的技术持续交付产品. Chiplet技术通过将一块完整芯片的复杂功能进行分解，异构集成多个模块化芯粒. 其中，这些芯粒可以由不同厂家、不同工艺的制程制造. 模块化集成方式可以有效提高芯片的研发速度、降低研发成本和芯片研制门槛，使得芯片研发聚焦于算法和核心技术，提高行业整体创新水平和能力. 脸书等公司推动的开放计算项目（open computer project，OCP）在2018年末积极启动了开放领域特定架构（open domain-specific architecture，ODSA）研究[3]，试图开发完整Chiplet体系结构的接口堆栈，创建一个Chiplet的开放市场. ODSA构建兼容网络堆栈的每一层都有多个选项，以便根据所连接的芯粒类型与现有技术兼容，通过定义开放的标准化互连接口，使得Chiplet芯片集成的裸片可以互操作，支持不同供应商的裸片自由组合，以构建灵活的芯片系统. Chiplet技术在芯片涉及的研发周期、成本、性能、灵活等多个维度提供可定制性和可优化性，为NP研制提供了一条可行的技术路线. ODSA面向通用计算，资源种类丰富，但未考虑高性能网络处理在加速、互连、耦合处理等方面的特殊需求. 目前尚未有基于Chiplet的NP架构研究工作.
本文提出采用Chiplet技术构建新型敏捷可定制NP架构——ChipletNP，利用Chiplet技术将网络处理所需的异质资源解耦，可使用成熟芯片产品及工艺，通过多个芯粒组合，采用先进封装工艺快速定制NP芯片，满足不同场景下NP快速定制和演化发展需求.
首先，分析NP异质资源需求，抽象网络处理各类功能及常用各类硬件资源，提出基于交换、处理、加速耦合等芯粒的ChipletNP体系结构. 其次，提出实现芯粒间统一互连的敏捷交换技术，支持多匹配动作分组处理模型以及级联扩展. 再次，基于敏捷交换技术设计并流片实现了的敏捷交换芯粒，相较于同级商用芯片能效比提升2倍以上，延迟控制在2.82 µs以内，可有效支持面向NP的Chiplet统一通信与集成. 最后，基于ChipletNP架构设计实现了一款NP芯片——银河衡芯敏捷（YHHX-NP），该芯片集成商用CPU、FPGA和自研敏捷交换芯粒，并对其开展相关功能验证和实验评估. 实验结果表明，基于ChipletNP架构可实现NP的敏捷定制，能够有效协同片内异质芯粒资源实现复杂的网络处理，具有强大的可编程能力，能够承载SRv6（segment routing over IPv6）等新型网络协议与网络功能的部署.
1. 相关工作
本节从NP技术、Chiplet技术、可编程交换芯片技术和专用硬件加速技术4个方面展开.
1.1 NP技术
传统NP根据采用的指令集类型，可以分为专用指令集和通用指令集2类多核NP. 专用指令集多核NP，如思科nPower X1[1]、迈络思NPS-400[4]、博通XLP900[5]、美满技术HX4100[6]，大多采用某种裁剪后的RISC指令集作为基本指令，并根据报文处理的特点拓展专用指令，集成度高，可获得与ASIC相媲美的处理性能，但存在微码编程、调试难度大的缺陷. 通用多核处理器采用完整的RISC或者CISC指令集，如恩智浦T系列[2]、凯为CN8000系列[7]、恩智浦LS2088A[8]、高通IPQ8069[9]，编译开发环境成熟、调试难度小，但受限于通用处理器的缺陷，存在吞吐率低、访存瓶颈和报文处理延时高且波动大的不足. Netronome提出采用逻辑块（功能组件）敏捷构建其系列化的单片NP，在2014—2018年快速推出了4款不同配置的NP. 然而，该方式仍难以解决单片集成电路面临的问题和挑战.
为满足高性能和灵活应用场景的各项要求，学术界[10-11]提出了各类提升灵活性、部署效率、处理性能、功耗的下一代NP. 例如，因特尔公司的Crystal Forest处理器采用多核+片外QuickAssist加速器[12]的协处理模型，并将深度报文检测、加解密、解压缩等常用的分组处理功能卸载到QuickAssist加速器中. 现有的工作还提出针对通用多核处理器实现报文处理的优化技术，如DPDK（data plane development kit）[11-12]，VPP（vector packet processing）[13]，能够比较有效地提升通用多核处理报文的吞吐量并降低处理延时. Li等人[14]提出基于FPGA加速平台的高柔性和高性能架构——clickNP，利用FPGA良好的可编程性和处理性能，可获得200 MPPS（million packets per second）的处理性能.
传统NP在单颗芯片上集成大量处理器核、加速器等部件，设计复杂、研发周期长、成本高，难以依据设备和应用需求推进速度同步、快速的迭代，敏捷可定制能力较弱.
1.2 Chiplet技术
Chiplet（又称小芯片或芯粒），试图通过将多个可模块化芯片（主要形态为裸片（die））通过内部互连技术集成在一个封装内，构成专用功能异构芯片，从而解决芯片研制涉及的规模、研制成本以及周期等方面的问题[15]. 通过采用2.5D，3D等高级封装技术，Chiplet可以实现高性能多芯片片上互连，提高芯片系统集成度，扩展其性能、功耗优化空间. 例如，AMD使用多达4个齐柏林飞艇（Zeppelin）芯片[16]构建第1代EPYC处理器（那不勒斯），使用中央IO芯片来实现具有无限架构的系统级互连. 英特尔公司提出了它们的异质芯片集成计划，可编程交换芯片Tofino2[17]采用Chiplet技术，将网络芯片高速SerDes IO模块与核心逻辑分离，提供更多针对功耗优化的布局选择.
脸书等公司推动的OCP也在2018年末积极启动了ODSA研究，试图开发完整体系结构的接口栈来创建一个Chiplet的开放市场，通过定义开放的标准化接口，使得Chiplet芯片中集成的裸片可以互操作，以支持不同供应商的裸片自由组合，构建更为灵活的芯片系统. ODSA提倡通用化架构和强调兼容性，而NP在延迟、带宽、处理模型方面，对资源种类和连接方式有特殊要求. 英特尔、AMD、高通、ARM、三星、台积电、日月光等大厂，以及谷歌云、微软等公司于2022年3月2日宣布了一项新技术标准UCIe（universal Chiplet interconnect express）. 但其仅针对物理层通信制定的标准，且与工艺、功耗以及性能紧密相关，尚未提出链路层及以上接口及协议，依赖沿用并扩展已有如PCIe标准接口与协议. 使用特定领域加速器和芯片的好处包括减少成本和上市时间、减少电路板面积和功耗，且加速器可以用于组装集成多种系统.
近几年演化出的Chiplet网络处理芯片、英特尔（原Barefoot）Tofino 2（12.8 Tbps）交换芯片采用交换逻辑芯片与高速SerDes接口模块芯片组合的Chiplet方式实现. 但其仅基于Chiplet技术将网络芯片高速SerDes IO模块与核心逻辑分离，未充分解耦资源，尚未形成Chiplet架构.
Chiplet为NP设计提供了新的解决思路. 相较于芯粒的通用处理器设计，在NP中应用Chiplet技术时，需要考虑到网络应用处理延时、吞吐率的差异化需求，同时需设计相关处理模型简化网络应用的开发和部署.
1.3 可编程交换芯片技术
与传统固定功能的交换芯片不同，可编程交换芯片将报文处理抽象为匹配和动作2种操作. 其中，匹配可根据用户需求配置待匹配的关键字，如源/目的IP地址、五元组信息等，以及待查找的规则内容；动作则是根据匹配结果执行报文处理. 例如，博通的BCM56000系列以及美满技术的Teralynx系列，将报文交换拆分成固定处理逻辑（如L2层交换）、ACL过滤，以及自定义处理逻辑. 并在自定义处理逻辑中设置3态内容寻址存储器（ternary content addressable memory，TCAM）以支持模糊匹配，以及通过PCIe连接ARM A72处理器支持复杂处理动作.
为更大限度地提升传统NP的处理性能且保持良好的灵活性，协议无关的可编程交换芯片应运而生. 可编程交换模型，如可重构匹配表（reconfigurable match table，RMT）[17]、分解的可重构匹配表（disaggregated reconfigurable match table，dRMT）[18]，其思想是将报文处理抽象为“匹配-动作表”（match-action table，MAT），匹配阶段输入的关键字是从报文头提取的任意字段，而执行的处理动作由命中的规则决定. 允许在不需要修改硬件处理逻辑条件下，通过配置匹配-动作规则表，实现用户定制的报文处理功能.
与博通、美满技术等公司的可编程交换芯片不同，Barefoot Tofino交换芯片包含可编程解析器，识别报文类型并提取关键字组成元数据（metadata），并设置由执行超长字执行单元组成的动作处理部件，可以组合支持大量复杂的报文处理功能.
但由于可编程交换芯片针对L2层交换（或Openflow协议），报文处理逻辑相对单一，仅采用匹配-动作处理抽象，难以支持多样化网络应用需求，例如，TCP重放攻击检测需要维护TCP连接、序列号等状态信息.
因此，现有商用网络交换芯片面向数据中心、园区网、企业网等大规模固定网络交换需求，支持大规模、高性能的网络交换，支持百万级流量的转发、交换管理，难以满足ChipletNP高能效、低功耗的集成需求.
现有的商用可编程交换芯片往往采用RMT多级匹配-动作架构，强调动作的丰富可编程性，但其匹配部分能力较弱，不支持超宽匹配，不能满足流量精细控制以及能效需求. 与可编程交换芯片的应用场景不同，NP更强调软件的可编程性，分组处理动作大多部署在耦合加速芯粒或CPU芯粒上处理，因此需要强调匹配部分的能力，弱化动作的丰富性，因此可编程交换芯片也难以作为敏捷交换芯粒实现最优选择.
1.4 网络加速技术
为提升网络处理吞吐率和降低通信延时，学术界和产业界提出了专用网络处理加速器/芯片. 例如，微软公司将基于FPGA的智能网卡（AccelNet）[19]应用在数据中心，可将端到端通信延时控制在微秒级. 英伟达公司网络的CX5系列智能网卡[20]，支持ASAP2加速，可以把网络相关工作（快速分组处理路径）卸载到eSwitch，而慢速分组处理路径及控制面仍然由主机端CPU处理. 数据中心也使用一些基于NP的智能网卡（如美满技术公司的LiquidIO II[21]系列、华为公司的IN300[22]系列），用于加速原先在通用多核上部署的网络功能.
但由于传统智能网卡将消耗大量宝贵的CPU内核来进行流量的分类、跟踪和控制. 这些昂贵的CPU内核是为通用应用程序而设计的，而并非为了网络数据包的查找和管理. 英伟达公司提出新一代智能网卡DPU（data processing unit）[23]，将更多原先在软件中实现的处理功能，如协议栈，卸载到网卡上实现，并可以旁路CPU直接将数据送给GPU，从而实现不同GPU节点间低延时数据传输，使多节点并行计算效率更高.
因特尔公司也提出了自己的下一代智能网卡IPU（infrastructure processing unit）[24]. 与DPU着重关注数据处理不同，IPU更偏向于将用户业务负载和云厂商基础负载分离，将基础负载的一些工作迁移到IPU上实现，并发布了基于因特尔公司的Agilex FPGA和Xeon-D片上处理器的IPU，即Oak Springs Canyon[25]，以及基于ASIC第2款IPU，即Mount Evans.
DPU、智能网卡、IPU用于卸载端侧网络应用，对灵活性的需求相对较强以适应不同类型的应用需求，但对处理能力的需求相对较弱[26]. 同时，相关技术还未采用Chiplet技术，集成大量处理单元带来极大的开发难度和成本，且往往采用单一或者少数集中处理资源，难以兼顾各类网络应用处理需求.
2. ChipletNP架构与处理模型
Chiplet技术通过将多个模块化的异构芯粒进行组合，采用先进的多芯片封装工艺形成一块具有完整功能的芯片. 这些芯粒可由不同厂家、不同工艺的制程制造，模块化集成方式可以有效提高芯片的研发速度、降低研发成本和芯片研制门槛，使得芯片研发聚焦于算法和核心技术，提高行业整体创新水平和能力.
虽然ODSA已提出通用可供参考的芯粒资源集成方案，但考虑到NP芯片有其特殊的领域特性和资源需求特性，主要面向网络处理领域. 因此，在NP中应用Chiplet技术时，不仅需要考虑带宽，更需要侧重考虑网络处理资源连接对于延迟、堆叠、统一互连的要求，以支撑网络应用的精细部署. 芯粒化的NP相较于普通异质芯粒资源互连侧重考虑高带宽，NP的芯粒间互连基于专用敏捷交换芯粒，作为NP的互连核心，实现高带宽、低延迟，支持网络处理低延时和分组流量的精细部署，实现各异质芯粒之间分组和中间处理结果的统一互连与通信，同时承载网络处理的快速路径实现交换堆叠，是NP获得极高处理性能的关键.
另一方面，基于异质芯粒构建的NP，需支持高效的分组处理模型，才能实现异质资源的一体化处理和有效部署网络功能.
本文提出新型敏捷可定制NP架构ChipletNP，基于Chiplet技术解耦异质资源，分析NP的异质资源组成，充分利用成熟芯片产品及工艺，设计专用敏捷交换芯粒实现多芯粒互连. 同时，提出基于ChipletNP的多匹配动作增强模型，满足不同应用场景下NP的快速定制和演化发展需求.
2.1 NP资源集成
首先针对传统单片NP以及工业界和学术界的NP集成异质资源展开分析，为ChipletNP组成架构设计提供支撑.
2.1.1 传统单片NP集成资源
商用高性能NP架构，以典型芯片LX2160A为例，如图1所示，集成了16个运行频率达2.2 GHz的Arm Cortex-A72 CPU内核，8 MB 2级缓存，共享8 MB片上缓存；集成支持130 Gbps L2层以太网交换模块，最多16个以太网端口；复用的24个SerDes通道可以配置为100 GbE/40 GbE/25 GbE/10 GbE端口；集成加速引擎模块，包括50 Gbps安全加速器、100 Gbps数据压缩/解压缩引擎；集成多种外设接口包括SD，eMMC等；集成支持ECC的2个72 b DDR4可通过通用多核间的报文级并行、通用多核内部指令级并行、通用多核和以太网交换单元与加速引擎模块的任务级并行以保证高性能，面向L2，L3层处理，可根据应用场景处理性能需求，提供12核（LX2120A）和8核（LX2080A）版本.
由此可见，传统单片NP通常集成通用多核处理模块、以太网交换模块、可配置高速接口、加速引擎4大部分，通过内部系统高性能总线互连，新型网络协议和功能只能部署到通用多核上执行，处理性能和支撑能力较弱.
2.1.2 可编程网络处理平台集成资源
现有可编程网络处理平台存在多种异质资源集成形式，表1给出这些平台的特性对比.
表 1 网络处理平台体系结构的特征对比Table 1. Features Comparison of Network Processing Platform Architechture实现架构 吞吐率 延迟 可扩展性 编程语言 OS 功耗 多核CPU（+ASIC） 低 高 好 C/C++等 支持 高 专用CPU（+ASIC） 高 高 好 汇编/C 支持 高 可编程ASIC 高 低 较差 P4 不支持 低 FPGA（+CPU） 较高 低 好 Verilog/
VHDL等部分支持 较低 1）多核CPU（+ASIC）加速器. 典型代表有凯为CN8000，该加速器通过集成ASIC专用硬件加速器或扩展专用分组处理指令，能够极大地提升报文处理性能，但由于ASIC具有繁杂的设计、开发、调试流程，难以满足灵活部署新网络功能或者加速各类网络应用的需求. 随着摩尔定律的失效，通过堆积CPU核数扩展性能的方式已难以满足网络流量的增长速率，需要采用新的分组处理架构.
2）专用CPU（+ASIC）. 典型代表有迈络思NPS400. 专用CPU能够大大提升吞吐率，然而专用CPU编程能力欠佳，往往采用基于汇编指令的微码编程，依旧存在处理延迟高的通病.
3）可编程ASIC. 典型代表有RMT，其基于动态可配置流水线模型，不需要修改硬件处理逻辑. 通过配置匹配-动作规则表，可灵活定制报文处理功能. 但其仍存在2点不足：一是流水线均匀分配资源不符合实际需求，存在资源浪费；二是针对L4层及L4层以下的无状态分组处理功能，无法支持复杂的有状态处理.
4）FPGA（+CPU）. 典型代表有SwitchBlade[27]，动态可重构流水线可支持在线重组基本硬件模块来构造所需的分组处理功能. 这种架构虽然能够提升灵活性以及避免综合硬件逻辑的时间开销，但仍存在2点不足：一是通用基本硬件模块的动作类型较少，导致可以组合获得的处理动作有限；二是不同的网络功能所需的分组处理模块可能分布不均，如果同时部署这些网络功能，则存在空闲模块造成资源浪费而公共模块出现性能瓶颈的问题.
综上所述，上述处理平台及资源通常面向具体网络应用领域构建，缺乏统一的互连架构以及处理模型，ChipletNP设计考虑并借鉴上述异质资源集成特点，并提供统一的互连架构和分组处理模型.
2.2 ChipletNP体系架构
综合考虑NP在性能、可编程性、可扩展性以及QoS等方面的需求，ChipletNP集成异质芯粒，以协同完成网络分组处理业务，如图2所示.
1）敏捷交换芯粒
Chiplet系统集成的核心——敏捷交换芯粒支持NP实现高密度和高带宽线速处理能力，完成网络功能的加速和卸载，实现异构芯粒资源互连和承载芯粒内交换网络，将分组流量优化部署到异构芯粒相应的处理资源上以提供芯粒异构资源的统一连接. 同时实现网络功能的快速路径，具有多个SerDes端口支持交换堆叠，是NP获得极高处理性能的关键.
现有的交换芯片，仅作为网络处理的快速路径以加速芯片，并未针对芯粒间的互连进行优化设计，不利于芯粒集成. 因此，需基于交换芯片实现网络加速处理的同时，提供统一的互连接口承载芯粒内敏捷交换网络，才能为实现芯粒内异构资源负载均衡和芯粒资源的Chiplet系统集成提供基础支撑.
2）耦合加速芯粒
基于DPU，NetDAM（network directly attached memory），FPGA等实现网络功能紧耦合与加速处理. 耦合加速芯粒承担如网络切片、SRv6等新业务的升级、应用加速的卸载、流量负载均衡，实现网络编程，弥补可配置交换芯片ASIC灵活性差、无法根据用户需求重构处理逻辑，以及通用多核处理器芯片CPU处理性能低的不足.
3）通用CPU芯粒
通用多核处理器阵列芯粒支持NP的灵活可编程性以实现深度处理. 通用多核处理器芯粒基于商用货架可独立演化，一般采用以太网和PCIe用作芯片间接口.
通用多核处理器既可以配置成流水线（pipeline）处理模式，即每个核实现一种网络功能，不同核之间按照功能服务链编排；也可以配置成RTC（run to complete）模式，即每个核均独自运行所有网络功能，无需核间的数据交互. 此外，CPU阵列可用于下发报文处理规则到耦合加速芯粒或可配置交换芯粒，避免后续可以在交换芯粒或者加速芯粒中处理的报文继续送给CPU整列处理，以提升处理性能.
4）领域加速芯粒
用于实现领域特定加速逻辑，包括分组处理的定制加速器（正则表达式、加解密等）以及定制处理器（低延迟处理器（NanoPU））等，可面向领域应用进行Chiplet集成.
上述芯粒可根据业务应用需求，通过SIP（system in package），MCM（multi-chip module）等多芯片封装技术封装在公共基板上，形成系统级NP解决方案.
ChipletNP基于Chiplet可组合思想，融合处理、加速、互连等异质资源，通过标准化网络接口互连通信，协同完成分组处理业务. 一方面，可以有效支持资源灵活配置需求，根据不同应用领域对性能、功耗的差异化需求配置资源类型和数量，以快速定制NP芯片；另一方面，支持商用成熟资源的集成，允许各资源独立演化、升级，提供更大的体系结构设计空间.
值得注意的是，敏捷交换芯粒作为ChipletNP的核心互连芯粒，需要支持芯粒间交互分组数据和中间处理结果，实现各处理平面之间的统一互连与通信.
2.3 ChipletNP分组处理模型
ChipletNP的分组处理采用多匹配动作（multiple matches & action，MMA）增强模型（multiple matches & action+，MMA+），综合了可编程交换芯片RMT流水处理模型与传统NP的RTC模型的优点.
如图3所示，MMA模型映射到敏捷交换芯片上，有状态的增强处理（action+，A+）可映射到耦合交换芯粒和CPU芯粒上. MMA+模型将分组处理数据平面划分为3个子平面，包括快速交换、在线加速以及深度处理，并使用DMID（destination module identifier）实现软硬件模块间的数据交互.
1）快速交换子平面
快速交换子平面基于敏捷交换芯粒实现，该平面由一系列被抽象为协议无关的流水阶段组成，采用协议无关的MMA抽象能够实现分类、转发、调度等各类无状态报文处理功能，具有高吞吐和低延迟的特点. 多级匹配阶段实现关键字匹配功能，支持精确匹配和掩码匹配2种类型；动作阶段则是根据匹配结果执行分组处理. 基于敏捷交换芯粒多级查表和多表冗余的流水线架构，能够实现细粒度流分类和查表. 所有报文均先经过敏捷交换芯粒匹配查询，然后根据匹配结果决定是否需要上送给在线加速子平面或深度处理子平面处理. 从而将不同类型内容的流量精细控制和部署到芯粒内异构资源上，实现更多的有状态增强处理，为芯粒内异构资源负载均衡等提供基础支撑. 此外，敏捷交换芯粒流水线头部是敏捷交换可编程解析器，其识别报文类型并提取关键字组成元数据. 流水线的尾部是敏捷交换协议（agile switch protocol，ASP）处理模块，可将查表结果元数据随分组一同输出.
2）在线加速子平面
在线加速子平面基于耦合加速芯粒实现，该平面利用其可编程或可重构特性来加速新业务、新协议等专用报文处理，兼备良好的处理性能和灵活性. 实现2部分功能：一是与芯粒间通信相关的处理逻辑，屏蔽底层连接实现，完成与其他异构处理资源的数据、控制消息交互；二是支持快速部署网络功能的重构和支持网络功能服务链的编排，为用户提供与底层硬件无关的信号接口，允许开发者插入、删除或替换应用相关处理逻辑以快速重构新的网络功能和支持各类新协议，加速各种定制报文处理功能.
3）深度处理子平面
深度处理子平面基于通用多核处理器芯粒实现，该平面面向多样化应用场景，集成通用多核处理器（可按需配置CUP核数）及大容量的存储资源，用于实现应用层协议识别、深度报文处理功能，具有极高的灵活性.
MMA+模型实现的3个分组处理数据子平面，可配合实现RMT流水处理以及RTC两种处理模式. 若采用RMT流水处理模式，这3个子平面紧耦合的映射执行分组处理的部分功能，通过定义标准的数据、控制消息，每个报文附加额外元数据用于3个处理平面的分组处理结果，以实现数据交互和共享. 若采用RTC处理模式，3个子平面可解耦独立处理各自映射的流量. 因此，MMA+模型可以支持同时部署2种处理模式来开发的网络功能，支持3类资源的灵活组合配置.
3. ChipletNP敏捷交换技术
ChipletNP敏捷交换技术在不同应用场景和数据传输带宽、延迟、能效等方面具有不同需求，要求ChipletNP敏捷交换芯粒能够实现统一、可扩展和高能效的互连，支持芯粒资源的按需配置与集成，从而实现面向应用敏捷定制NP.
具体地，敏捷交换芯粒应具有5种能力：1）具有芯粒间统一、标准数据交换，且能够广泛兼容连接各类异质商用芯粒能力；2）具有面向应用支持细粒度的芯粒间分组转发控制能力，将分组流量精细优化部署到芯粒相应的处理资源上；3）具有芯粒分组转发卸载加速能力，有效减轻通用多核阵列负载，实现分组快速转发；4）具有高能效、低功耗交换能力，以满足ChipletNP在设计空间、散热等方面的要求；5）具有堆叠扩展能力，提供异质芯粒资源可扩展能力.
如图4所示，敏捷交换芯粒采用标准以太网交换协议. 这是因为以太网是目前应用最为广泛的交换协议，其性能高、成本低，且CPU等各类处理、加速等芯片广泛集成有以太网接口.
![]()
图 4 基于敏捷交换芯粒的异质芯粒资源堆叠扩展Figure 4. Stack expansion of heterogeneous Chiplet resources based on agile switching Chiplet现有商用网络交换芯片，如博通、盛科等，面向数据中心、园区网、企业网等大规模固定网络交换需求，出于市场与成本考虑，更强调实现丰富的功能协议集合，支持大规模、高性能的网络交换，支持百万级流量的转发、交换管理，难以满足上述高能效、低功耗等敏捷交换需求. 商用可编程交换芯片通常采用RMT多级匹配-动作架构提升芯片对分组处理的可编程灵活性. 由于该芯片更强调动作的丰富可编程性，匹配能力相对较弱，难以满足敏捷交换细粒度流量控制的需求.
与可编程交换芯片的应用场景不同，NP更强调软件可编程性，依据MMA+模型，ChipletNP分组处理动作大多部署在耦合加速芯粒或CPU芯粒上处理. 此外，考虑到流量精细控制以及能效需求，可编程交换芯片也难以作为敏捷交换芯粒实现最优选择.
敏捷交换芯粒的实现采用MMA架构，如图5所示，主要部件包括可配置高速接口模块、敏捷交换可编程解析与封装模块、协议无关匹配-动作流水线3部分.
1）可配置高速接口模块. 芯片内置可配置高速接口模块，采用内置SerDes通道的集成化设计，基于灵活的端口配置模式、复用的SerDes通道来灵活支持多种速率的以太网端口，更好地支撑敏捷交换间的堆叠扩展，从而提供多样化芯粒资源集成能力.
2）敏捷交换可编程解析与封装模块. 该模块为ChipletNP架构提供了芯粒间的转发平面协同处理能力. 前级芯粒可通过元数据随分组一同输出的方式将内部的查表结果随原始报文分组一同输出，后级芯粒解析该报文即可获取前级查表信息，由此通过芯粒级联即可有效扩展报文分组处理流水线的长度和复杂度等功能处理能力，充分发挥异构资源芯粒互连优势. 敏捷交换可编程解析能够识别标准以太网报文或带有元数据的报文，识别报文类型并提取关键字组成元数据，与分组一同进入协议无关匹配-动作流水线中. 封装模块可灵活配置输出报文为标准以太网报文或带有元数据的报文，广泛兼容各类商用芯粒.
3）协议无关匹配-动作流水线. 该部分采用超宽字节掩码匹配模型提供兼容OpenFlow模型的可编程转发平面处理能力，通过配置可支持灵活的匹配粒度调节，多级匹配表提供了丰富的正交表项组合. 64 B报文+32 B查表信息，能够广泛支持当前L2~L7各种已有协议及用户自定义协议帧的转发，实现面向应用的细粒度分组转发控制能力，从而支持流量的精细化部署. 支持软件定义交换，通过配置流表可构建不同堆叠拓扑. 基于SBV（stride bit vector）算法代替TCAM实现的掩码匹配可支持并行全流水. 除基本转发动作外，协议无关匹配-动作流水线还集成了QoS流限速、L2层报文头（目的MAC，源MAC，VLAN）修改等功能，以减少报文分组的处理路径延时和对其他芯粒资源的占用，提供芯粒分组转发卸载加速能力.
4. 银河衡芯敏捷网络处理器（YHHX-NP）
针对新型网络技术部署等应用场景，基于ChipletNP架构敏捷定制了YHHX-NP. 新型网络技术部署更强调NP的可编程性和可定制性，意图在性能、灵活性、功耗等多方面实现最优的定制设计.
如图6（a）所示，YHHX-NP采用全国产基板设计和封装工艺实现，基于多芯片封装技术集成整合通用CPU芯粒（某国产通用多核CPU）、耦合加速FPGA芯粒（复旦微JFM7K325T）以及敏捷交换芯粒（自研HX-DS160交换芯片28 nm工艺）. 值得注意的是，由于基于ChipletNP敏捷可定制架构，YHHX-NP研制周期仅为6个月，远少于单芯片NP芯片研制时间.
![]()
图 6 基于ChipletNP设计的网络处理器芯片Figure 6. Network processor chips designed based on ChipletNP1）敏捷交换芯粒
其中自研敏捷交换芯粒HX-DS160，如图6（b）所示，是一款面向ChipletNP集成设计的高带宽、低功耗敏捷交换芯片,该芯片也可作为高效能以太网交换以及智能网络接口芯片独立应用，独立应用封装尺寸为27 mm×27 mm的BGA676. 芯片采用自主设计方式，依托28 nm工艺节点流片，具有160 Gbps交换性能（单向），提供16个万兆以太网接口，外部接口可配置为2×40 Gbps+8×10 Gbps＋8×1Gbps；支持全端口线速转发交换处理，典型功耗仅8.5 W；支持堆叠扩展模式. 与应用广泛的某国产120 Gbps以太网交换芯片相比，性能功耗比提升2倍以上（从7.5 Gbps/W提升至18.8 Gbps/W）.
HX-DS160采用可编程的协议无关MMA交换架构，以及采用超宽比特搜索匹配引擎，支持宽度768 b的关键字搜索. HX-DS160可通过40 Gbps/10 Gbps/1 Gbps数据接口进行带内配置，也支持SPI（serial peripheral interface）和IIC（inter-integrated circuit）接口进行轻量化管理配置，提供无管理CPU的集成方式以满足敏捷定制需求.
2）耦合加速芯粒
ChipletNP耦合加速芯粒基于国产高性能FPGA（复旦微JFM7K325T）实现. 为提升网络处理吞吐率和降低通信延时，常用的耦合加速芯粒资源有DPU，IPU，FPGA等，相较于DPU与IPU，ChipletNP的优势体现在2方面：一是DPU与IPU受限于网络设备应用场景，这两者用于卸载端侧网络应用，适应不同类型的应用需求，处理性能相对较弱；二是用户定制能力方面，FPGA具有良好的可重构性，有利于提高整个NP的敏捷定制能力. 因此基于高性能FPGA实现的ChipletNP耦合加速芯粒，能够兼备良好的处理性能和灵活性.
ChipletNP耦合加速芯粒实现2部分功能：一是与芯粒间通信相关的处理逻辑FPGA OS，屏蔽底层连接实现，完成FPGA-CPU数据、控制消息交互功能. 交互部件可以基于PCIe总线，FPGA向上提供数据收发API（application interface），实现FPGA与CPU交换报文和元数据，是FPGA-CPU协同处理的基础. 由于与芯粒间耦合协同优化设计相关性较小，此处不做详述. 二是实现可重构分组流水线，这也是耦合加速芯粒体现耦合性的重要部分，是支持ChipletNP MMA+分组处理模型的关键. 采用模块化设计框架，基于可编程模块索引机制，可将报文处理流水线抽象为一系列具有相同接口的功能模块，实现网络功能服务链的编排以构建所需的网络功能. 同时，为NP用户提供一组与底层硬件无关的信号接口，允许开发者插入、删除或替换应用相关处理逻辑以快速重构新的网络功能，从而支持各类新协议实现加速各种定制报文处理功能，可重构分组处理流水线.
基于FPGA实现的可重构分组处理流水线的支持调度包含FPGA硬件功能模块、敏捷交换芯粒硬件功能模块和通用CPU的软件进程3部分. 其中硬件功能模块采用串行组织，即图3中的M1，M2，…，MN, MP, MQ, MR. 软件进程则运行软件功能模块，即图3中的MV, MP, MQ, MR并支持动态加载和移除，其中MV为配置模块.
可重构分组处理流水线处理报文的流程为4步： ①网络端口接收报文，并送给敏捷交换硬件流水线的第1个模块M1，然后再依次经过后续的匹配模块进行匹配，查表匹配结果随分组一同输出，即为每个报文附加额外的元数据，方便模块间共享中间处理结果，元数据中携带DMID，用于指示处理当前报文的下一个模块. 根据查表匹配结果，将流量送达基于耦合加速芯粒实现的可重构分组处理流水线中完成硬件部分的处理. ②基于耦合加速芯粒实现的可重构分组处理流水线会根据DMID的数值判断是将报文直接从网络接口输出还是送软件模块MX（即DMID=x）或 MY，MZ进行深度处理. ③每个软件模块在完成报文处理后，均会将报文继续送回基于耦合加速芯粒实现的可重构分组处理流水线中. ④报文可再次经过所有硬件模块处理，或者根据DMID直接跳到敏捷交换芯粒硬件最后一个功能模块MN，然后根据输出端口转发.
ChipletNP可重构分组处理流水线为用户提供清晰的软硬件开发接口来屏蔽底层的设计细节，例如，可以屏蔽报文收发、软硬件报文交互等设计细节，从而降低软硬件功能的开发难度. 用户开发网络功能时，需要遵循3类相关的开发接口规范，详见附录A. 用户不但可以根据需求动态增加或删除软件功能模块，而且可以通过离线加载的方式重组硬件功能模块，满足了用户对网络功能灵活可扩展的需求.
5. 实验评估与功能验证
5.1 性能测试
为了测试YHHX-NP性能，搭建实验环境，对NP原型芯片相关性能进行测试. 图7所示为YHHX-NP芯片性能测试平台. 芯片验证板通过串口连接测试PC，10 Gbps/40 Gbps以太网接口通过光纤连接网络测试仪，并在通用多核CPU芯粒上运行操作系统. 基于该性能测试平台，对NP原型芯片的网络分组转发性能、处理延迟等能力进行验证.
针对不同大小报文的吞吐率测试结果表明，如图8（a）所示，NP芯片可满足10 Gbps/40 Gbps以太网接口IPv4，IPv6转发报文线速处理需求. 如图8（b）所示，处理延迟实验表明，随着报文尺寸的增大，交换转发处理延迟有所增加，但最大不超过2.82 µs. 查表中关键字通常不超过96 B（64 B+32 B），查表结果不超过32 B. 根据延迟测试结果，交换转发处理延迟通常可控制在1.2 µs延迟以内（报文长度在256 B以内）. 大报文分组在40 Gbps速率下转发延迟优于10 Gbps，原因在于40 Gbps链路传输速率更快，而小报文则反之，原因在于40 Gbps的报文分组处理逻辑更长，处理小报文分组转发时，分组数据在更长的处理逻辑路径上执行，延迟稍大.
5.2 典型业务部署验证
5.2.1 SRv6功能映射
ChipletNP架构能够对各类新型网络协议提供快速部署的支持. 以SRv6为例，通过对SRv6的处理流程进行抽象并对功能进行模块化解耦，可将SRv6的功能实现完全映射到YHHX-NP芯片中. 本节将演示基于YHHX-NP的SRv6显示路由功能.
SRv6路由器是通过SRv6技术实现可配置路由路径和可编程网络的IPv6路由器. 基于YHHX-NP实现SRv6处理引擎功能设计，及实现显式路径，SRv6路由器具有2个功能：
1）支持普通IPv6报文的路由转发.
2）支持SRv6引流（源节点压入SRH（segment routing head））、SRH解析和处理（如转发节点将SID（segment identifier）填入目的IP）、SRH弹出（末端转发节点删除SRH）等SRv6相关功能.
为支持SRv6网络协议的快速部署，数据平面需完成分组分类、流分类、SID分类、路由转发、SRv6 SRH源端压入、SRv6 SID解析和处理、目的MAC地址替换、最大跳数限制（hop limit）判断和修改、段剩余值SL（segment left）判断和修改、ICMP（Internet control message protocol）代理、统计计数、动作处理等功能. 控制平面需完成生成分组分类表、流分类表、SID分类表、SRH压入表、转发表、邻居表，完成对数据平面的配置功能，如图9所示. 数据平面的报文处理按功能模块解耦后的流程描述见附录B.
![]()
图 9 SRv6在YHHX-NP原型芯片上的功能部署Figure 9. Function deployment of SRv6 on YHHX-NP prototype chip图9中敏捷交换芯粒上的映射实现分类查表及简单动作的处理，包括分组分类、流分类、SID分类、路由转发、目的MAC地址替换、动作处理等功能模块；耦合加速芯粒上执行需要定制更新报文头字段等较为复杂的动作处理，包括普通IPv6处理、报文解析、SRv6源端压入SRH、SRv6中间处理和末端SRH弹出处理、报文汇聚等功能模块. 在通用多核CPU阵列芯粒上执行实现ICMP代理和规则配置等软件功能模块. 各模块的具体功能描述见附录C.
5.2.2 SRv6功能验证
3台基于YHHX-NP芯片实现的路由器R1，R2，R3组成一个环形网络，各路由器之间通过以太网口3和以太网口4互连. 每台路由器的以太网口1分别连接1台主机用于收发用户流量. 同时，为了便于观察路由器之间的报文内容，将路由器的以太网口2作为以太网口3和以太网口4口的镜像端口，连接到主机的另外一个外置网口上. 主机1、主机2、主机3的IP地址均不在同一网段. 主机PC1的网口连接到YHHX-NP路由器R1的以太网口，且这2个网口在同一网段，具体拓扑连接如图10所示.
按照网络拓扑实现主机之间通信，普通IPv6报文经过2跳路由转发即可. 如主机1→路由器1→路由器3→主机3. 为了验证基于YHFT-NP成功部署SRv6显示路由，本文规划了相应的SRv6引流策略和SRv6转发路径，从而实现主机1发给主机3的报文经过路由器1、路由器2、路由器3的指定路径，主机3发给主机1的报文会经过路由器3、路由器2、路由器1的指定路径. 本文测试使用抓包软件Wireshark、串口连接工具SecureCRT、网络性能测试软件Iperf3.
如图11可以看出路由器1收到目的IP地址为主机3（2001:3:1::2）的ICMPv6回应请求报文后，根据SRv6引流策略，成功在报文扩展头中压入段路由头，段路由携带的段路由列表（SID）为{路由器2（2001:2:3::1）→路由器3（2001:3:4::1）→主机3（2001:3:1::2）}. 此时路由器1作为源节点，根据压入SRH中段的剩余值找到相应段路由列表，即路由器2的IP，替换IPv6目的地址，并根据新IPv6目的地址进行路由转发，从而将报文发给下一跳路由器2.
路由器2收到报文后，检查SRH头中的SL>1作为中间节点，根据SRH中SL减1后找到相应段路由列表，即路由器3的IP地址替换IPv6的目的地址，如图12所示，同时将SL−1根据新IPv6目的地址进行路由转发，从而将报文发给路由器3. 路由器3收到报文后，检查SRH头中的SL=1作为尾节点，获取下一跳为主机3，并将SRH从报文中弹出，从而将原始报文发送给主机3.
结果表明，原型芯片能够成功部署SRv6功能，支持主机1发与主机3之间的报文按照SRv6指定路径进行路由转发，实现加SRH头和去SRH头. 通过修改SRH的段路由列表实现修改报文转发路径，能够按需进行新业务的逻辑编程.
5.2.3 资源评估
在本文实验中，使用国产FPGA综合工具评估了 映射在耦合芯粒中的关键模块硬件资源利用率，包括芯粒间通信相关的处理逻辑FPGA OS、可重构分组处理流水线2大部分. 表2列出了耦合芯粒中实现的功能模块.
表 2 耦合芯粒中功能模块资源评估Table 2. Resource Evaluation of Functional Modules in Coupled ChipletSRv6功能模块 资源 LUT FF BRAM 普通IPv6处理 158 142 0 SRv6源端处理 2 132 878 5 SRv6中间处理 1 827 1 213 10 SRv6末端处理 1 912 1 300 10 解析与汇聚逻辑 3 834 2 932 52 SRv6功能模块总和 9 863 6 465 77 FPGA OS 15 160 8 461 44 FPGA OS模块总和 145 016 217 524 526 工作在125 MHz时钟频率下. 硬件资源使用情况，包括查找表（lookup table，LUT）资源，即逻辑处理资源；触发器（flip flop，FF）资源；块存储（block memory，BRAM）资源. 从表2中可以看出，在耦合芯粒上部署SRv6功能模块，SRv6功能逻辑资源占比约6.8%，寄存器资源占比约2.97%；FPGA OS功能逻辑资源仅占比约10.5%，寄存器资源占比约3.89%，可以有效支持新耦合加速功能的部署.
6. 结 论
本文提出新型敏捷可定制NP架构ChipletNP，提出了基于Chiplet技术解耦异质资源和交换，处理、加速耦合等芯粒的ChipletNP架构以及分组处理和控制模型，定义并设计实现了面向芯粒间统一互连的敏捷交换网络；提出面向网络应用的耦合加速技术，并设计开发了一款集成商用CPU、FPGA和自研敏捷交换芯粒的银河衡芯敏捷NP芯片YHHX-NP，基于该芯片的应用部署与实验结果表明，ChipletNP可支持NP的快速敏捷定制，可以有效承载SRv6等新型网络协议与网络功能部署以满足不同的应用及部署场景，能够支持NP的快速定制和演化发展需求.
作者贡献声明：李韬和杨惠提出了架构设计思路和撰写论文；杨惠提出实验方法并修改全文；厉俊男负责撰写论文部分内容；刘汝霖负责完成实验；孙志刚提出指导意见.李韬和杨惠为共同第一作者.
-
![]()
图 2 一个在可用带宽下降时控制通路延迟的例子
Figure 2. An example of the control path delay when the available bandwidth drops
表 1 应用层的实时多媒体优化相关工作
Table 1 Related Work in Real-Time Multimedia Optimization from the Application Layer
学界/业界方案 解决途径 主要思路 Swift (NSDI’22) [28]
CGEncoder (MMSys’20) [29]
NAS (OSDI’18) [30]
LiveNAS (SIGCOMM’20) [31]
VP9 (Google’13) [32]实时编解码器 通过更新编解码设计
在弱网等情况下依然
保证内容解码BB (SIGCOMM’14) [33]
Pensieve (SIGCOMM’17) [22]
Puffer (NSDI’20) [34]
AFR (NSDI’23) [10]自适应码率算法 通过让码率适配带宽
来降低卡顿RTP/RTCP (RFC8888) [35]
RTSP (RFC7826) [36]
DTP (ICNP’21) [37]多媒体传输协议 通过协议设计来传递
应用需要的信息
下载: 导出CSV
表 2 传输层的实时多媒体优化相关工作
Table 2 Related Work in Real-Time Multimedia Optimization from the Transport Layer
下载: 导出CSV
表 3 网络层的实时多媒体优化相关工作
Table 3 Related Work in Real-Time Multimedia Optimization from the Network Layer
下载: 导出CSV
-
[1] Cisco. VNI complete forecast highlights[EB/OL]. 2018[2023-08-10].https://www.cisco.com/c/dam/m/en_us/solutions/service-provider/vni-forecast-highlights/pdf/Global_Device_Growth_Traffic_Profiles.pdf
[2] Livingood J. Working latency — The next QoE frontier[EB/OL]. 2021[2023-08-10].https://blog.apnic.net/2021/12/02/working-latency-the-next-qoe-frontier/
[3] Mohan N, Corneo L, Zavodovski A, et al. Pruning edge research with latency shears[C]//Proc of the 19th ACM Workshop on Hot Topics in Networks. New York: ACM, 2020: 182−189
[4] Meng Zili, Guo Yaning, Sun Chen, et al. Achieving consistent low latency for wireless real-time communications with the shortest control loop[C]//Proc of the 36th ACM SIGCOMM Conf. New York: ACM, 2022: 193−206
[5] Kämäräinen T, Siekkinen M, Ylä-Jääski A, et al. A measurement study on achieving imperceptible latency in mobile cloud gaming[C]//Proc of the 8th ACM Multimedia Systems Conf. New York: ACM, 2017: 88−99
[6] Shi Shu, Cheng-Hsin H, Nahrstedt K, et al. Using graphics rendering contexts to enhance the real-time video coding for mobile cloud gaming[C]//Proc of the 19th ACM Int Conf on Multimedia. New York: ACM, 2011: 103−112
[7] Wimmer R, Schmid A, Bockes F. On the latency of USB-connected input devices[C]//Proc of the 37th ACM CHI Conf. New York: ACM, 2019: 420−431
[8] Slivar I, Skorin-Kapov L, Suznjevic M. Cloud gaming QoE models for deriving video encoding adaptation strategies[C]//Proc of the 7th ACM Multimedia Systems Conf. New York: ACM, 2016: 185−196
[9] Li Tong, Zheng Kai, Xu Ke, et al. Tack: Improving wireless transport performance by taming acknowledgments[C]//Proc of the 34th ACM SIGCOMM 2020 Conf. New York: ACM, 2020: 15−30
[10] Meng Zili, Wang Tingfeng, Shen Yixin, et al. Enabling high quality real-time communications with adaptive frame-rate[C]//Proc of the 20th USENIX NSDI 2023 Conf. Berkeley, CA: USENIX Association, 2023: 1429−1450
[11] Wu Dapeng, Hou Yiwei Thomas, Zhang Yaqin. Transporting real-time video over the Internet: Challenges and approaches[J]. Proceedings of the IEEE, 2000, 88(12): 1855−1877 doi: 10.1109/5.899055
[12] Wu Dapeng, Hou Yiwei Thomas, Zhu Wenwu, et al. Streaming video over the Internet: Approaches and directions[J]. IEEE Transactions on Circuits and Systems for Video Technology, 2001, 11(3): 282−300 doi: 10.1109/76.911156
[13] Huo Yongkai, Hellge C, Wiegand T, et al. A tutorial and review on inter-layer FEC coded layered video streaming[J]. IEEE Communications Surveys & Tutorials, 2015, 17(2): 1166−1207
[14] 张杰良,蒋未芳,王欣,等. 视频会议画面质量评价方法综述[C]//第六届中国指挥控制大会论文集. 北京:电子工业出版社,2018:207−211 Zhang Jieliang, Jiang Weifang, Wang Xin, et al. Survey of video conference image quality assessment[C]//Proc of the 6th Chinese Guidance and Control Conf. Beijing: Publishing House of Electronics Industry, 2018: 207−211(in Chinese)
[15] 胡晓艳,童钟奇,徐恪,等. 命名数据网络中的视频传输研究综述[J]. 计算机研究与发展,2021,58(1):116−136 doi: 10.7544/issn1000-1239.2021.20190697 Hu Xiaoyan, Tong Zhongqi, Xu Ke, et al. Video delivery over named data networking: A survey[J]. Journal of Computer Research and Development, 2021, 58(1): 116−136(in Chinese) doi: 10.7544/issn1000-1239.2021.20190697
[16] Li Yang, Lin Hao, Li Zhenhua, et al. A nationwide study on cellular reliability: Measurement, analysis, and enhancements[C]//Proc of the 35th ACM SIGCOMM Conf. New York: ACM, 2021: 597−609
[17] Yang Xinlei, Lin Hao, Li Zhenhua, et al. Mobile access bandwidth in practice: Measurement, analysis, and implications[C]//Proc of the 36th ACM SIGCOMM Conf. New York: ACM, 2022: 114−128
[18] Yang Xinlei, Wang Xiaolong, Li Zhenhua, et al. Fast and light bandwidth testing for internet users[C]//Proc of the 18th USENIX NSDI Conf. Berkeley, CA: USENIX Association, 2021: 1011−1026
[19] Alizadeh M, Kabbani A, Atikoglu B, et al. Stability analysis of QCN: The averaging principle[C]//Proc of the 39th ACM SIGMETRICS Conf. New York: ACM, 2011: 49−60
[20] Dong Mo, Li Qingxi, Zarchy D, et al. PCC: Re-architecting congestion control for consistent high performance[C]//Proc of the 12th USENIX NSDI Conf. Berkeley, CA: USENIX Association, 2015: 395−408
[21] Abbasloo S, Yen C Y, Chao J. Classic meets modern: A pragmatic learning-based congestion control for the Internet[C]//Proc of the 34th ACM SIGCOMM Conf. New York: ACM, 2020: 632−647
[22] Mao Hongzi, Netravali R, Alizadeh M. Neural adaptive video streaming with pensieve[C]//Proc of the 31st ACM SIGCOMM Conf. New York: ACM, 2017: 197−210
[23] Yin Xiaoqi, Jindal A, Sekar V, et al. A control-theoretic approach for dynamic adaptive video streaming over HTTP[C]//Proc of the 29th ACM SIGCOMM Conf. New York: ACM, 2015: 325−338
[24] Cheng Yuchung, Cardwell N, Dukkipati N, et al. RFC8985: The RACK-TLP loss detection algorithm for TCP[EB/OL]. 2021[2023-08-10].https://datatracker.ietf.org/doc/html/rfc8985
[25] Nichols K, Jacobson V. Controlling queue delay[J]. Communications of the ACM, 2012, 55(7): 42−50 doi: 10.1145/2209249.2209264
[26] Padhye J, Firoiu V, Towsley D F, et al. Modeling TCP Reno performance: A simple model and its empirical validation[J]. IEEE/ACM Transactions on Networking, 2000, 8(2): 133−145 doi: 10.1109/90.842137
[27] Ha S, Rhee I, Xu L. CUBIC: A new TCP-friendly high-speed TCP variant[J]. ACM SIGOPS Operating Systems Review, 2008, 42(5): 64−74 doi: 10.1145/1400097.1400105
[28] Dasari M, Kahatapitiya K, Das S R, et al. Swift: Adaptive video streaming with layered neural codecs[C]//Proc of the 19th USENIX NSDI Conf. Berkeley, CA: USENIX Association, 2022: 103−118
[29] Zadtootaghaj S, Schmidt S, Sabet S S, et al. Quality estimation models for gaming video streaming services using perceptual video quality dimensions[C]//Proc of the 11th ACM Multimedia Systems Conf. New York: ACM, 2020: 213−224
[30] Yeo H, Jung Y, Kim J, et al. Neural adaptive content-aware internet video delivery[C]//Proc of the 15th USENIX NSDI Conf. Berkeley, CA: USENIX Association, 2018: 645−661
[31] Kim J, Jung Y, Yeo H, et al. Neural-enhanced live streaming: Improving live video ingest via online learning[C]//Proc of the 34th ACM SIGCOMM Conf. New York: ACM, 2020: 107−125
[32] Mukherjee D, Bankoski J, Grange A, et al. The latest open-source video codec VP9—An overview and preliminary results[C]//Proc of the 30th Picture Coding Symp (PCS). Piscataway, NJ: IEEE, 2013: 390−393
[33] Huang Teyuan, Johari R, McKeown N, et al. A Buffer-based approach to rate adaptation: Evidence from a large video streaming service[C]//Proc of the 28th ACM SIGCOMM Conf. New York: ACM, 2014: 187−198
[34] Yan F, Ayers H, Zhu Chenzhi, et al. Learning in situ: A randomized experiment in video streaming[C]//Proc of the 17th USENIX NSDI Conf. Berkeley, CA: USENIX Association, 2020: 495−511
[35] Sarker Z, Perkins C, Singh V, et al. RFC8888: RTP control protocol (RTCP) feedback for congestion control[EB/OL]. 2021[2023-08-10].https://datatracker.ietf.org/doc/html/rfc8888
[36] Schulzrinne H, Rao A, Lanphier R, et al. RFC7826: Real-time streaming protocol version 2.0[EB/OL]. 2016[2023-08-10].https://datatracker.ietf.org/doc/html/rfc7826
[37] Zhang Lei, Cui Yong, Pan Junchen, et al. Deadline-aware transmission control for real-time video streaming[C/OL]//Proc of the 29th IEEE ICNP Conf. Piscataway, NJ: IEEE, 2021[2023-08-10].https://ieeexplore.ieee.org/document/9651971
[38] Wang Zhou, Bovik A C, Sheikh H R, et al. Image quality assessment: From error visibility to structural similarity[J]. IEEE Transactions on Image Processing, 2004, 13(4): 600−612 doi: 10.1109/TIP.2003.819861
[39] Hore A, Ziou D. Image quality metrics: PSNR vs SSIM[C]//Proc of the 20th Int Conf on Pattern Recognition. Piscataway, NJ: IEEE, 2010: 2366−2369
[40] Fouladi S, Wahby R S, Shacklett B, et al. Encoding, fast and slow: Low-latency video processing using thousands of tiny threads[C]//Proc of the 14th USENIX NSDI Conf. Berkeley, CA: USENIX Association, 2017: 363−376
[41] Fouladi S, Emmons J, Orbay E, et al. Salsify: Low-latency network video through tighter integration between a video codec and a transport protocol[C]//Proc of the 15th USENIX NSDI Conf. Berkeley, CA: USENIX Association, 2018: 267−282
[42] Yeo H, Chong C J, Jung Y, et al. Nemo: Enabling neural-enhanced video streaming on commodity mobile devices[C]//Proc of the 26th ACM MobiCom Conf. New York: ACM, 2020: 363−376
[43] Spiteri K, Urgaonkar R, Sitaraman R K. BOLA: Near-optimal bitrate adaptation for online videos[C/OL]//Proc of the 35th IEEE INFOCOM 2016 Conf. Piscataway, NJ: IEEE, 2016[2023-08-10].https://ieeexplore.ieee.org/document/7524428
[44] Spiteri K, Sitaraman R, Sparacio D. From theory to practice: Improving bitrate adaptation in the DASH reference player[J]. ACM Transactions on Multimedia Computing, Communications, and Applications, 2019, 15(2): 1−29
[45] Li Zhi, Zhu Xiaoqing, Gahm J, et al. Probe and adapt: Rate adaptation for HTTP video streaming at scale[J]. IEEE Journal on Selected Areas in Communications, 2014, 32(4): 719−733 doi: 10.1109/JSAC.2014.140405
[46] Wang Cong, Rizk A, Zink M. SQUAD: A spectrum-based quality adaptation for dynamic adaptive streaming over HTTP[C]//Proc of the 7th ACM Multimedia Systems. New York: ACM, 2016: 1−12
[47] Sengupta S, Ganguly N, Chakraborty S, et al. HotDASH: Hotspot aware adaptive video streaming using deep reinforcement learning[C]//Proc of the 26th IEEE ICNP Conf. Piscataway, NJ: IEEE, 2018: 165−175
[48] Yi Gang, Yang Dan, Bentaleb A, et al. The ACM multimedia 2019 live video streaming grand challenge[C]//Proc of the 27th ACM Int Conf on Multimedia. New York: ACM, 2019: 2622−2626
[49] Shi Hang, Cui Yong, Qian Feng, et al. Dtp: Deadline-aware transport protocol[C]//Proc of the 3rd Asia-Pacific Workshop on Networking. New York: ACM, 2019: 1−7 Shi Hang,Cui Yong,Qian Feng,et al. Dtp:Deadline-aware transport protocol[C]//Proc of the 3rd Asia-Pacific Workshop on Networking. New York:ACM,2019:1−7
[50] Winstein K, Sivaraman A, Balakrishnan H. Stochastic forecasts achieve high throughput and low delay over cellular networks[C]//Proc of the 10th USENIX NSDI Conf. Berkeley, CA: USENIX Association, 2013: 459−471
[51] Carlucci G, De Cicco L, Holmer S, et al. Analysis and design of the Google congestion control for web real-time communication (WebRTC)[C]//Proc of the 7th ACM Multimedia Systems Conf. New York: ACM, 2016: 133−144
[52] Zhu Xiaoqing, Pan Rong, Ramalho M, et al. RFC8698: Network-assisted dynamic adaptation (NADA): A unified congestion control scheme for real-time media[EB/OL]. 2020[2023-08-10].https://datatracker.ietf.org/doc/html/rfc8698
[53] Johansson I, Sarker Z. RFC8298: Self-clocked rate adaptation for multimedia[EB/OL]. 2017[2023-08-10].https://datatracker.ietf.org/doc/html/rfc8298
[54] Arun V, Balakrishnan H. Copa: Practical delay-based congestion control for the Internet[C]//Proc of the 15th USENIX NSDI Conf. Berkeley, CA: USENIX Association, 2018: 329−342
[55] Dong Mo, Meng Tong, Zarchy D, et al. PCC Vivace: Online-learning congestion control[C]//Proc of the 15th USENIX NSDI Conf. Berkeley, CA: USENIX Association, 2018: 343−356
[56] Holmer S, Shemer M, Paniconi M. Handling packet loss in WebRTC[C]//Proc of the 20th IEEE Int Conf on Image Processing. Piscataway, NJ: IEEE, 2013: 1860−1864
[57] Fong S L, Emara S, Li B, et al. Low-latency network-adaptive error control for interactive streaming[C]//Proc of the 27th ACM Int Conf on Multimedia. New York: ACM, 2019: 438−446
[58] Rudow M, Yan F, Kumar A, et al. StreamMelt: Efficient loss recovery for videoconferencing via streaming codes[C/OL]//Proc of the 20th USENIX NSDI Conf. Berkeley, CA: USENIX Association, 2023: 953−972 Rudow M,Yan F,Kumar A,et al. StreamMelt:Efficient loss recovery for videoconferencing via streaming codes[C/OL]//Proc of the 20th USENIX NSDI Conf. Berkeley,CA:USENIX Association,2023:953−972
[59] Cardwell N, Cheng Yuchung, Gunn C S, et al. BBR: Congestion-based congestion control: Measuring bottleneck bandwidth and round-trip propagation time[J]. Queue, 2016, 14(5): 20−53 doi: 10.1145/3012426.3022184
[60] Zaki Y, Pötsch T, Chen J, et al. Adaptive congestion control for unpredictable cellular networks[C]//Proc of the 29th ACM SIGCOMM Conf. New York: ACM, 2015: 509−522
[61] Sarolahti P, Kojo M, Raatikainen K. F-RTO: An enhanced recovery algorithm for TCP retransmission timeouts[J]. ACM SIGCOMM Computer Communication Review, 2003, 33(2): 51−63 doi: 10.1145/956981.956987
[62] Bolot J C, Fosse-Parisis S, Towsley D. Adaptive FEC-based error control for Internet telephony[C]//Proc of the 39th IEEE INFOCOM Conf. Piscataway, NJ: IEEE, 1999: 1453−1460
[63] Padhye C, Christensen K J, Moreno W. A new adaptive FEC loss control algorithm for voice over IP applications[C]//Proc of the 19th IEEE IPCCC Conf. Piscataway, NJ: IEEE, 2000: 307−313
[64] Chen Ke, Wang Han, Fang Shuwen, et al. RL-AFEC: Adaptive forward error correction for real-time video communication based on reinforcement learning[C]//Proc of the 13th ACM Multimedia Systems Conf. New York: ACM, 2022: 96−108
[65] Fong S L, Khisti A, Li B, et al. Optimal streaming codes for channels with burst and arbitrary erasures[J]. IEEE Transactions on Information Theory, 2019, 65(7): 4274−4292 doi: 10.1109/TIT.2019.2894124
[66] Krishnan M N, Shukla D, Kumar P V. Rate-optimal streaming codes for channels with burst and random erasures[J]. IEEE Transactions on Information Theory, 2020, 66(8): 4869−4891 doi: 10.1109/TIT.2020.2983152
[67] Floyd S, Jacobson V. Random early detection gateways for congestion avoidance[J]. IEEE/ACM Transactions on Networking, 1993, 1(4): 397−413 doi: 10.1109/90.251892
[68] Feng Wuchang, Kandlur D, Saha D, et al. BLUE: A new class of active queue management algorithms[EB/OL]. 1999[2023-08-10].https://www.cse.umich.edu/techreports/cse/99/CSE-TR-387-99.pdf
[69] Feng Wuchang, Kapadia A, Thulasidasan S. GREEN: Proactive queue management over a best-effort network[C]//Proc of the 21st Global Telecommunications Conf. Piscataway, NJ: IEEE, 2002: 1774−1778
[70] Long Chengnian, Zhao Bin, Guan Xinping, et al. The Yellow active queue management algorithm[J]. Computer Networks, 2005, 47(4): 525−550 doi: 10.1016/j.comnet.2004.09.006
[71] Spang B, Arslan S, McKeown N. Updating the theory of buffer sizing[J]. ACM SIGMETRICS Performance Evaluation Review, 2022, 49(3): 55−56 doi: 10.1145/3529113.3529131
[72] Tang Jiaxin, Liu Sen, Xu Yang, et al. ABS: Adaptive buffer sizing via augmented programmability with machine learning[C]//Proc of the 41st IEEE INFOCOM Conf. Piscataway, NJ: IEEE, 2022: 2038−2047
[73] Katabi D, Handley M, Rohrs C. Congestion control for high bandwidth-delay product networks[C]//Proc of the 16th ACM SIGCOMM Conf. New York: ACM, 2002: 89−102
[74] Chia-Hui T, Zhu Jiang, Dukkipati N. Making large scale deployment of RCP practical for real networks[C]//Proc of the 27th IEEE INFOCOM Conf. Piscataway, NJ: IEEE, 2008: 2180−2188
[75] Flores M, Wenzel A, Kuzmanovic A. Enabling router-assisted congestion control on the Internet[C/OL]//Proc of the 24th Int Conf on Network Protocols (ICNP). Piscataway, NJ: IEEE, 2016[2023-08-10].https://ieeexplore.ieee.org/document/7784442
[76] Goyal P, Agarwal A, Netravali R, et al. ABC: A simple explicit congestion controller for wireless networks[C]//Proc of the 17th USENIX NSDI Conf. Berkeley, CA: USENIX Association, 2020: 353−372
[77] De Schepper K, Briscoe B, White G. RFC 9332: Dual-queue coupled active queue management (AQM) for low latency, low loss, and scalable throughput (L4S)[EB/OL]. 2023[2023-08-10].https://datatracker.ietf.org/doc/html/rfc9332
[78] Bai Wei, Chen Li, Chen Kai, et al. Information-agnostic flow scheduling for commodity data centers[C]//Proc of the 12th USENIX NSDI Conf. Berkeley, CA: USENIX Association, 2015: 455−468
[79] Alizadeh M, Yang Shuang, Sharif M, et al. pFabric: Minimal near-optimal datacenter transport[C]//Proc of the 27th ACM SIGCOMM Conf. New York: ACM, 2013: 435−446
[80] Addanki V, Apostolaki M, Ghobadi M, et al. ABM: Active buffer management in datacenters[C]//Proc of the 36th ACM SIGCOMM Conf. New York: ACM, 2022: 36−52
[81] Kwok-Ho C, Babiarz J, Baker F. RFC 4594: Configuration guidelines for diffserv service classes[EB/OL]. 2006[2023-08-10].https://datatracker.ietf.org/doc/html/rfc4594
[82] Appenzeller G, Keslassy I, McKeown N. Sizing router buffers[J]. ACM SIGCOMM Computer Communication Review, 2004, 34(4): 281−292 doi: 10.1145/1030194.1015499
[83] Zhu Yibo, Eran H, Firestone D, et al. Congestion control for large-scale RDMA deployments[C]//Proc of the 29th ACM SIGCOMM Conf. New York: ACM, 2015: 523−536
[84] Li Yuliang, Miao Rui, Liu Hongqiang, et al. HPCC: High precision congestion control[C]//Proc of the 33rd ACM SIGCOMM Conf. New York: ACM, 2019: 44−58
[85] Chen Wei, Ma Liangping, Chien-Chung S. Congestion-aware MAC layer adaptation to improve video teleconferencing over wi-fi[C]//Proc of the 6th ACM Multimedia Systems Conf. New York: ACM, 2015: 130−141
[86] Meng Zili, Chen Jing, Guo Yaning, et al. PiTree: Practical implementation of abr algorithms using decision trees[C]//Proc of the 27th ACM Int Conf on Multimedia. New York: ACM, 2019: 2431−2439
[87] Meng Zili, Guo Yaning, Shen Yixin, et al. Practically deploying heavyweight adaptive bitrate algorithms with teacher-student learning[J]. IEEE/ACM Transactions on Networking, 2021, 29(2): 723−736 doi: 10.1109/TNET.2020.3048666
[88] Meng Zili, Wang Minhu, Bai Jiasong, et al. Interpreting deep learning-based networking systems[C]//Proc of the 34th ACM SIGCOMM Conf. New York: ACM, 2020: 154−171
-
期刊类型引用(1)
1. 林涵越，吴婧雅，卢文岩，钟浪辉，鄢贵海. Neptune：一种通用网络处理器微结构模拟和性能仿真框架. 计算机研究与发展. 2025(05): 1091-1107 . 
本站查看
其他类型引用(0)
计量
- 文章访问数: 330
- HTML全文浏览量: 134
- PDF下载量: 131
- 被引次数: 1
