XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记

总结

论文及视频：XLINK: QoE-driven multi-path QUIC transport in large-scale video services

XLINK设计思想：

• 结合MPQUIC与短视频应用——传输层应用层协同
• 通过重注入来解决HoL阻塞以最大化QoE，同时最小化重注入成本

XLINK的核心贡献：

• MPQUIC+短视频大规模部署经验
• 基于播放器buffer的重注入调节策略
• 平衡QoE性能与重注入流量成本

XLINK核心设计：基于播放器buffer水平的重注入

• 方法：双阈值控制
  • buffer < 阈值1：启用重注入
  • buffer > 阈值2：停止重注入
  • 阈值1 ≤ buffer ≤ 阈值2：
    • buffer < 预期剩余传输时间：启用重注入
    • buffer > 预期剩余传输时间：停止重注入
  • *其实就是buffer < 阈值2时才可能启用重注入，而buffer < 阈值1时必定启用重注入
• 选择：重注入 vs. 数据包调度
  • 数据包调度：基于对网络环境的预测，可能不准确
  • 重注入：放弃预测，对性能下降进行快速反应

XLINK特殊设计：

• 基于QUIC stream优先级的重注入
• 基于视频帧优先级的重注入
• 无线感知主路径选择
• 快路径ACK

其他设计：

• 数据包调度：沿用MinRTT
• 拥塞控制：解耦合
• 路径管理（增/删/改/查）：无特殊设计
• 能耗：无特殊设计（单bit耗能与单路径差不多）
• 蜂窝数据流量：无特殊设计（只针对免流用户）
• 网络编码：无

*注：文中“【】”中的内容为个人想法，仅供参考。

---

Abstract

XLINK的两个设计目标：

1. 最大化QoE
2. 最小化服务提供商（CDN）的成本开销

XLINK的两个基础：

1. 用户态协议QUIC
2. 感知QoE

挑战：

1. 多路径head-of-line（HoL）阻塞
2. 网络异构性
3. 链路的快速变化
4. 平衡成本和性能

实验：

• 环境：3百万短视频，安卓APP
• 结果：相对于单路径QUIC
  • 99%视频块请求完成时间减少19%～50%
  • 99%首帧延迟降低32%
  • 减少了23%～67%的卡顿率，仅增加了2.1%的冗余流量

1 Introduction

1.1 背景

96%的消费者表明，短视频对其购物决策有帮助

• Amazon product videos. https://videoreviewlabs.com/amazon-product-videos/, 2020.

“网红经济“的兴起

• Target China. WHAT IS “INTERNET CELEBRITY ECONOMY” IN CHINA. https://targetchina.com.au/article/internet-celebrity, 2020.

两个观察

1. 短视频的卡顿和启动时延严重影响用户满意度
2. 消费者渴望看到更好的细节和更有参与感的需求，推动了短视频朝着更高码率的方向发展

问题：is it practical and worthwhile to bring multi-path QUIC to large-scale video services?

1.2 挑战

直接将多路径应用于大规模视频

• 挑战：实测多路径的性能不如单路径
• 原因：MP-HoL阻塞问题——慢路径的包先发晚到，乱序到达的数据包无法向应用层提交，导致快路径的包需要等待

MP-HoL的传统解决方案：

• 更复杂的包调度算法：依赖于准确的吞吐量预测
• 发送冗余包：带来严重的冗余流量，视频传输无法承受

因此，现有MP技术主要用于音频场景（Apple Siri和Apple Music）

1.3 XLINK介绍

思想&方法

Key idea：

• 用户空间协议QUIC
• 直接通过视频QoE来控制多路径调度和管理

设计机制：

• 基于客户端的QoE反馈，在服务器的调度器中动态控制数据包的重注入（re-injection）行为
  • 思路：基于客户端播放器的buffer水平来控制重注入的数据量，以提升多路径传输性能同时降低冗余流量成本
  • 因为无线链路的不可预测性，不追求准确的网络特征预测
• 为多路并行QUIC流设计，使用基于流优先级的重注入，根据流的紧急性确定发送顺序
  • 思路：优先传输高优先级Stream的重注入数据包，确保QUIC Stream按照其先后顺序（优先级顺序）完成传输
• 为短视频做优化，使用基于视频帧优先级的重注入实现了首帧加速（比流更细粒度的调度）
  • 思路：优先传输首帧的重注入数据包，确保首帧传输不被后续帧阻塞
• 基于QoE感知的路径管理，解决流异构网络下路径时延差距大的问题
  • 主路径选择：基于无线感知的主路径（启动会话的路径）选择
  • ACK_MP路径选择：多路径ACK不局限于同一个子流，可以灵活选择其返回路径，这不同于MPTCP

优势&提升

核心指标

• 性能
  • 视频启动延迟
  • 视频卡顿率
  • 移动性支持
  • CDN流量开销
• 安全性

贡献：

• 展现了生产环境中多路径QUIC视频传输的大规模实验结果
• 提出了解决挑战的关键：利用QUCI作为用户空间协议的特性，并使用QoE进行调度及路径管理
• 揭示了之前的文献较少提及的实际挑战（性能、成本、移动性、兼容性、网络异构性），并分享了解决这些挑战的经验

主要结果：

• 数据量：100K参与者，3百万视频播放
• 对比：单路径QUIC
• 效果（同摘要）：
  • 视频块请求完成时间
  • 首帧延迟
  • 卡顿率

XLINK总结：

• 主要创新：利用远端反馈来控制重注入
• 利用QUIC的能力：基于流优先级和帧优先级的调度
• 感知应用的传输层优化：可以扩展至短视频以外的其他应用，如360°视频、AR、VR等

2 Motivation

2.1 短视频

短视频应用：：TikTok、Reels、Twitter
电子商务公司：阿里、亚马逊、Ebay、Redfin

现状：

• 短视频爆发
• 电子商务引入短视频来展示商品
• 短视频对QoE的要求更高：相对于长视频，观众对短视频的QoE下降的容忍度更低[27]

2.2 QUIC

QUIC是Google提出的用于替换TCP的协议，现已占据Google流量的40%+和Facebook流量的75%+
QUIC相对于TCP的优势：

• 更快
• 更安全
• 协议变更灵活

QUIC的用户态特性，便于其实际MPTCP在克服部署中的问题，如：

• 不理想的性能
• 负载均衡器（LB）的支持
• OS支持
• 中间件的支持

2.3 移动性支持

现状：

• 无线网络下，对于移动性的支持至关重要
• 从Wi-Fi切换至蜂窝数据要么太慢，要么容易失效
• QUIC具有连接迁移（CM）策略
  • 缺陷：迁移后需重置连接的窗口，对于具有高带宽需求的视频流而言可能并不合适

2.4 5G下的多路径

现状：

• 尽管5G提供了更高的带宽，但与LTE相比，由于更多的传播损耗（propagation loss）和更弱的渗透能力（weaker penetration）导致5G信号覆盖范围更小，这为5G满足传输可靠性和QoS保证带来了新的挑战
• Wi-Fi6可能仍将是最高效的室内通信方法

趋势：同时利用5G和Wi-Fi

3 Experience with Vanilla Multi-path QUIC

Vanilla-MP：MPQUIC（CoNEXT’17）

• 数据包调度：MinRTT

多路径性能的两个挑战：

• 移动性（导致路径性能快速变化）
• 路径时延差异：不同无线技术的路径时延差异很大，此外还受跨ISP的时延影响
  • 数据：LTE的时延是Wi-Fi的2.7倍，是5G SA的5.5倍

3.1 Vanilla-MP in 仿真环境

环境：Mahimahi
观察：Vanilla-MP无法快速应对网络突变

• 在Wi-Fi带宽突降时（1.7s），其Inflight依然在增长

3.3 Vanilla-MP in 真实环境

数据采集：一周
对比：Vanilla-MP vs. SP（单路径）
观察：

• Vanilla-MP只能偶尔在RCT（请求完成时间）的中位数和90%分位数上有所提升，有时甚至会导致更差的性能（中位数最多16%）
• Vanilla-MP总在RCT的99%分位数上（长尾部分）导致性能下降（最多28%）
• Vanilla-MP会引起视频卡顿率的增长（34%～96%）
  • 卡顿率：总卡顿时间/视频总播放时间

结论：直接应用于短视频时，Vanilla-MP相对于单路径不一定能取得性能提升

4 XLINK Design Overview

目标：用最少的开销取得最优的QoE（低时延，少卡顿）
思想：跨层网络设计，与视频应用紧密结合

核心：

• 利用QUIC的用户态特性
• 利用客户端的QoE反馈：为QUIC的ACK_MP添加QoE_control_signal字段

MPQUIC草案：MPQUIC（CoNEXT’17）

• PATH_STATUS扩展帧
• ACK_MP扩展帧

XLINK与草案的区别：为ACK_MP帧引入额外的字段，而非使用额外的帧

5 QoE-Driven Scheduling and Path Management

三个组成部分：

• 基于优先级的重注入
• 基于QoE反馈的重注入
• 感知QoE的路径管理

5.1 基于优先级的重注入

在传输层与应用层同时实现

重注入的作用

MP-HoL阻塞的根源：调度器在多个路径分配数据包，使多路径产生耦合

• 图a示例：快路径完成传输，慢路径尾部丢包，则需要等待RTO才能进行重传

重注入：通过另一个路径重传Inflight数据包，将多路径解耦合，以缓解MP-HoL阻塞

• 时机：待发送队列（pkt_send_q）中无数据包
• 图b示例：通过快路径重传Inflight数据包，不需要等待RTO触发丢包恢复，可以提前完成传输

【关于路径耦合我的理解：
指一条路径的传输行为受到另一条路径的影响，无法充分利用带宽。那么所谓解耦合，就是指不管其他路径的环境如何，所有路径在传输数据的全部时间内，都可以打满带宽进行发送。
MinRTT之所以会耦合，是因为慢路径在传输最后一个RTT的数据时，快路径很可能被空闲，导致无法更快地完成传输。而重注入通过利用快路径发送冗余数据包，使得在最后一个慢路径RTT内，快路径仍然以满带宽传输，直至所有数据传输完成。通过重注入，可以将传输尾部的完成时间从慢路径RTT缩短至快路径RTT。】

QUIC优化：基于流优先级的重注入

QUIC特性：Multi Stream
思想：按照Stream的先后顺序进行优先级排序，确保高优先级的Stream优先完成传输
实现：发送某Stream的最后一个数据包后，检查未ACK队列（unacked_q）中是否存在同优先级的数据包，若有，则将其插入至低优先级流未发送的数据包前，优先发送

首帧加速：基于视频帧优先级的重注入

挑战：对于视频帧而言，其传输单元相对较小，帧的传输很容易被慢路径阻塞（图中的pkt3）——需要重注入
问题：基于流级别的重注入粒度太粗（一个流包含多个帧），无法解决视频帧阻塞的问题
思想：识别视频帧的数据，优先完成首帧数据包的传输
实现：stream_send API

• 将包含视频首帧的流设为最高优先级
• 通过设置首帧的位置与大小参数，指示首帧在流中的相对位置
• 发送首帧的最后一个数据包后，检查未ACK队列（unacked_q）中是否存在首帧的数据包，若有，则在发送下一帧数据包前优先注入对应数据包

5.2 基于QoE反馈的重注入控制

重注入的问题：冗余流量成本（直接使用会引入15%的冗余流量）

• 开销：$0.085/GB

解决思路：利用客户端的QoE反馈，控制重注入的数据量

• 播放器有buffer，不需要在任何时候都重注入

QoE反馈：XLINK感知播放器buffer水平

• 实现：ACK_MP帧的QoE_Control_Signal字段
• 信号：
  • 缓存字节数量（ℎ_）
  • 缓存帧数量（ℎ_）
  • 码率（）
  • 帧率 ()

QoE信号采集

播放器结构：

• video pipeline
  • Media Source：分割音视频帧，存储至Source Pipe
  • Source Pipe：将分割后的音视频帧发送至其对应的Decoder；记录缓存帧的数量及字节数（buffer）
  • Decoder：解码，有音视频码率和帧率信息
  • Decoder Pipe
  • Renderer
• MediaCacheService：视频块HTTP请求
• TNET：Android网络SDK，将QoE信号传递给XLINK

QoE反馈采集流程：

• Source Pipe和Decoder将QoE信号周期性发送至TNET
• 当XLINK需要发送QoE反馈时，向TNET查询
• 若QoE信息已更新，TNET响应XLINK的查询
• XLINK将QoE信息封装在ACK_MP帧的QoE_Control_Signal字段中

双阈值控制

重注入控制算法的三个设计目标：

• responsiveness：在急需重注入时快速响应
• cost-efficiency：准确避免任何不必要的重注入
• flexibility：平衡性能与成本

XLINK的重注入控制算法：双阈值控制

• 输入：四种QoE信号（->播放器buffer水平）
• 输出：是否启用重注入
• 步骤：
  • 计算剩余播放时间Δ（buffer水平）
    • 缓存帧数量 / 帧率：VBR编码时
    • 缓存数据量 / 码率：帧率较低时
    • *相关信息更新频率低时，需要估算剩余播放时间
  • buffer vs. 双阈值（ℎ1 < ℎ2）
    • ℎ1（responsiveness）：若buffer小于该值，则立即启用重注入
    • ℎ2（cost-efficiency）：若buffer超过该值，则停止重注入
    • ℎ1 & ℎ2（flexibility）
  • buffer vs. 剩余传输时间（）
    • 当buffer处于[ℎ1, ℎ2]之间时，判断Δ < ，成立时启用重注入，否则停用
    • ：所有包含Inflight的路径的{RTT + 对应路径RTT标准差}的最大值

示例：

• b：MinRTT（无重注入）——严重卡顿
• c：MinRTT+重注入（不限量）——引入过多的冗余流量
• d：XLINK——以最少的流量开销保证播放的流畅性

*注：视频流在start-up阶段重注入的数据量较多，但当buffer稳定以后，重注入较少

性能&成本

• ℎ1：流量开销下限 ≥ ∗ (Δ < ℎ1)
• ℎ2：流量开销上限 ≤ ∗ (Δ < ℎ2),
• ：重注入成本开销，约15%

5.3 感知QoE的路径管理

主路径选择

过去研究表明，由于路径时延差异的存在，主路径选择会影响MPTCP性能

• Wifi, lte,or both? measuring multi-homed wireless internet performance - IMC’14

5G SA增大了路径时延差

• 独立核心网络
• 原生支持边缘计算，使得内容传输更靠近接入网边缘

XLINK的无线感知主路径选择：5G SA > 5G NSA > WiFi > LTE

• 主路径选择影响首帧时间

ACK_MP路径选择

MPTCP：ACK从其原始路径返回
XLINK：ACK从最快路径返回

• 对于CUBIC类拥塞控制而言，ACK的快速返回有助于快路径快速增窗

6 Protocol and Implementation

XLINK基于所提出的MPQUIC草案实现：https://datatracker.ietf.org/doc/html/draft-liu-multipath-quic-02
与之前草案的区别：

• 充分利用现有QUIC的传输层设计，仅仅引入了三个额外的帧类型
• 支持QoE反馈

设计要点：

• 不同路径通过连接ID（CID）来标识，每条路径使用单独的数据包序号（for丢包监测和恢复）
• 保持QUIC协议头部格式不变，避免被中间件禁用
• 一个连接的所有路径共享相同密钥，每个路径可以在AEAD中获取一个单独的nonce
• 引入PATH_STATUS和ACK_MP扩展帧，以支持多路径功能和QoE反馈机制

多路径初始化

QUIC标准草案[34]：https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-33

实现：

• 初始化主路径：同单路径QUIC，差异在于，在第一次握手时，客户端发送_ℎ，若服务器返回_ℎ，则双端启用多路径，否则回退到单路径
• 初始化新路径：
  • 初始化前：客户端与服务器各自需要至少提供一个未使用的CID（如上图中的C1和S2）
    • 客户端先检查双端是否有可用CID，并选择一个可用的CID（如S2）作为新路径的目标CID
  • 初始化中：客户端选择S2作为新路径的目标CID（DCID），完成新路径设置
    • 通过QUIC的__帧交换CID
    • 为避免路径欺骗攻击，XLINK使用_和_帧
  • 初始化后：使用ACK_MP帧替代普通的ACK帧

帧扩展

三个扩展帧：

• PATH_STATUS：多路径管理。将路径的当前状态通知给对端，对端应根据可用信息发送数据包
  • CID：使用对端CID的序列号，描述发送方的路径ID
  • 可用值：Abandon(0)、Standby(1) 和 Available(2)
• ACK_MP：通过引入Path Index字段（CID序列号），进行丢包检测与恢复
  • XLINK引入__字段来反馈QoE
• QOE_CONTROL_SIGNAL：QoE反馈。可以独立发送，不受ACK频率限制

路径关闭

服务器与客户端通过发送PATH_STATUS帧来关闭Path Identifier对应的路径

• 当路径被标记为Abandon(0)时，可以释放与该路径相关的资源

通过检测网络环境变化，客户端和服务器可以立即关闭路径

• 例如：客户端关闭4G/Wi-Fi；Wi-Fi信号衰减至阈值；RTT或丢包率变差

路径保护（安全性）

QUIC安全性的一般原则不变：设置数据包保护密钥、初始化加密、头部保护、0-RTT密钥等

对于1-RTT数据包使用的multiple number spaces，需要改变AEAD的使用
【这部分看不懂，暂略】

负载均衡支持

负载均衡器（LB）需实现QUIC-LB草案[44]中指定的路由算法
对于LB中的CID使用相同的hash，以确保将多路径数据包路由到相同的真实服务器

• 真实服务器需要在发给客户端的CID中编码其服务器ID

Android APP客户端集成

XLINK客户端基于XQUIC（IETF QUIC的C语言实现），并集成至手淘Android客户端APP，测试包可以每周发布

CDN服务器部署

XLINK服务器同样基于XQUIC，部署于CDN服务器
对程序的进程ICD使用相同的hash，以确保将多路径数据包传递给保存QUIC连接上下文的进程

• 在CID的保留字节中编码进程ID

XLINK通过配置项添加其算法参数，可在几小时内更新

7 Evaluation

实验环境：

• 真实上线
  • 双阈值参数选择
  • XLINK vs. 单路径
• 可控实验
  • XLINK vs. 其他多路径机制
  • 能耗

7.1 双阈值控制参数选择

根据buffer水平的分布来确定双阈值控制参数

• 在start-up阶段结束后，开始统计buffer水平
• 图表示在不同参数设置下，相对于单路径的buffer水平提升
  • 参数（横坐标）：X-Y表明两个阈值的buffer水平分位数，如95-80即95%的buffer水平超过阈值1，80%的buffer水平超过阈值2

观察：

• 对于性能而言，重注入是必要的。若不启用重注入，buffer水平相对于单路径会有严重下降
• 对于成本而言，双阈值控制是必要的。若不控制重注入的数据量（1-1），流量开销会达到15%
• 开销下界*(1−)，上界*(1−)，其中=15%
  • 【可见X越小，即阈值1对应的buffer水平越高，开销下界越大；对应地，Y越小，开销上界越高。因此图中从左到右的开销是递增的】
• 相对保守的阈值（如95-80）即可取得不错的性能，更为激进的重注入策略会导致边际效益递减
• 与预期传输时间进一步对比，有助于在开销上界较高时有效控制成本，比如90-80与90-60的对比

相对单路径，XLINK降低了buffer<50ms的比例（此时很可能引发卡顿）

最终参数：95-80，产生2.1%的冗余数据开销

7.2 大规模A/B测试

传输指标：请求完成时间

连续两周的线上测试表明，对于中位数、尾部请求完成时间（RCT），XLINK可以稳定优于单路径，因为它有效地解决了MP-HoL问题

• 中位数 / 95%分位数 / 99%分位数分别提升：2.3%～8.9 / 9.4%～34% / 19%～50%

QoE指标1：卡顿率

卡顿率下降：23.8%～67.6%

• 卡顿率：sum(rebuffer time)/sum(play time)，即总卡顿时间/视频总播放时间

QoE指标2：首帧时延

观察：

• 无首帧加速时，XLINK性能不如单路径（14%的99分位下降），这是由慢路径的巨大时延引起的
• 首帧加速将视频启动时延限界至快路径性能内（32%的99分位提升）
  • 长尾部分的提升更明显，因为长尾部分的路径时延差很大

7.3 极限移动性

环境：Mahimahi仿真+真实网络采集的Trace
对比对象：

• SP（单路径）
• Vanilla-MP
• MPTCP
• QUIC CM（connection migration，连接迁移）

实验观察（RCT的中位数与最大值）：

• SP表现最差，因为不支持移动性
• CM相对单路径表现更优，但在极端场景下，迁移到的新路径同样可能面临性能问题，此时CM不一定有效，甚至可能性能更差；此外，路径的CWND在连接迁移后会被重置，需要几个RTT重新探测带宽，对于快速的网络环境变化（如hand-off）反应迟缓
• MPTCP和Vanilla-MP表现相对较好，不过因为MP-HoL阻塞问题，在某些情况下也有性能下降

7.4 能耗

实验环境：3个安卓5G手机下载不同大小（10MB～50MB）的文件
记录信息：时间戳，瞬时电流，电压，WiFi RSSI，cellular RSSI
控制变量：清后台，开关飞行模式，保持屏幕亮度相同

结论：使用多路径会提升瞬时能耗（power），但不一定会提升每bit能耗（energy）

• energy = power × 时间，使用多路径的传输时间会变短

观察：

• 吞吐量：Wi-Fi+LTE、Wi-Fi+NR均比多路径有提升
• energy per bit：
  • 引入Wi-Fi作为多路径后降低了单独使用蜂窝数据网络（4G LTE、5G NR）的能耗
  • 单路径Wi-Fi的能耗最低，但吞吐量也远低于XLINK
  • XLINK更适用于对高带宽和时延有需求的应用（如视频）

8 Related Work

MPQUIC

QUIC的多路径扩展方案：

• MPQUIC草案
• MPQUIC - CoNEXT’17
• MPQUIC - ICC’18
• PQUIC - SIGCOMM’19

现有方案的缺陷：对于可部署性和收益的问题缺乏大规模实验研究（ https://mailarchive.ietf.org/arch/browse/quic/）

XLINK验证了MPQUIC在商业大规模短视频服务中作为端到端服务的可行性、可部署性和优势

MPTCP

MPTCP在2013年实现标准化，却极少在移动操作系统中应用，原因：

• 部署困难
• MP-HoL阻塞等引发的性能问题
• 成本

大规模实验室可控环境实验表明，MPTCP对于单路径的性能提升受到许多因素影响，如下载数据量、路径时延差等

本文认为不同路径对于多路径能力的需求有所不同，因此多路径需要与应用协同

多路径数据包调度

MPTCP默认：MinRTT + opportunistic retransmission and penalization

• 惩罚机制会影响聚合带宽

基于网络预测的方法（解决惩罚影响性能的问题）：ECF、BLEST、Musher

• 移动场景下很难得到准确的预测

乱序发送按序到达类方法：STMS、DEMS

低时延MPTCP：RAVEN

• 通过大量冗余数据降低时延，没有应用于视频服务

XLINK：以视频应用为中心，考虑可扩展性和部署性，通过QoE反馈的重注入来解决HoL拥塞问题，平衡性能与成本

跨层视频优化

跨层视频QoE提升技术（单路径）：

• DASH：BBA、MPC、Pensieve
• RTC：Salsify、Concerto

多路径方案：

• MP-DASH：MPTCP+DASH
  • MPTCP在内核中，不易与应用结合
  • 使用粗粒度的决策来决定是否启用子流
• Cross-layer scheduler（MMSys’16）：
  • 粗粒度
  • 只是对MPTCP的视频数据包进行优先级排序

XLINK：

• 用QoE反馈控制多路径策略
• 细粒度（几百ms）框架

9 Discussion and Limitations

蜂窝数据流量成本

解决方案：

• 手淘APP免流策略
• 手淘APP中附加XLINK开关

拥塞控制公平性

XLINK采用解耦合拥塞控制，与MP-DASH一致
原因：现有Wi-Fi和蜂窝数据网络（甚至是5G NSA）不太可能共享瓶颈链路（last mile）
limitation：随着5G SA的部署，瓶颈链路很可能从last mile转移，这种情况下应选择耦合拥塞控制策略