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

文章目录

  • 总结
  • Abstract
  • 1 Introduction
    • 1.1 背景
    • 1.2 挑战
    • 1.3 XLINK介绍
      • 思想&方法
      • 优势&提升
  • 2 Motivation
    • 2.1 短视频
    • 2.2 QUIC
    • 2.3 移动性支持
    • 2.4 5G下的多路径
  • 3 Experience with Vanilla Multi-path QUIC
    • 3.1 Vanilla-MP in 仿真环境
    • 3.3 Vanilla-MP in 真实环境
  • 4 XLINK Design Overview
  • 5 QoE-Driven Scheduling and Path Management
    • 5.1 基于优先级的重注入
      • 重注入的作用
      • QUIC优化:基于流优先级的重注入
      • 首帧加速:基于视频帧优先级的重注入
    • 5.2 基于QoE反馈的重注入控制
      • QoE信号采集
      • 双阈值控制
    • 5.3 感知QoE的路径管理
      • 主路径选择
      • ACK_MP路径选择
  • 6 Protocol and Implementation
    • 多路径初始化
    • 帧扩展
    • 路径关闭
    • 路径保护(安全性)
    • 负载均衡支持
    • Android APP客户端集成
    • CDN服务器部署
  • 7 Evaluation
    • 7.1 双阈值控制参数选择
    • 7.2 大规模A/B测试
    • 7.3 极限移动性
    • 7.4 能耗
  • 8 Related Work
    • MPQUIC
    • MPTCP
    • 多路径数据包调度
    • 跨层视频优化
  • 9 Discussion and Limitations
    • 蜂窝数据流量成本
    • 拥塞控制公平性

总结

论文及视频: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倍

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第1张图片

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

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第2张图片
目标:用最少的开销取得最优的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 基于优先级的重注入

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

重注入的作用

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第3张图片
MP-HoL阻塞的根源:调度器在多个路径分配数据包,使多路径产生耦合

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

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

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

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

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

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第4张图片
QUIC特性:Multi Stream
思想:按照Stream的先后顺序进行优先级排序,确保高优先级的Stream优先完成传输
实现:发送某Stream的最后一个数据包后,检查未ACK队列(unacked_q)中是否存在同优先级的数据包,若有,则将其插入至低优先级流未发送的数据包前,优先发送

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

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第5张图片
挑战:对于视频帧而言,其传输单元相对较小,帧的传输很容易被慢路径阻塞(图中的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信号采集

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第6张图片
播放器结构:

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

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第7张图片
QoE反馈采集流程:

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

双阈值控制

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

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

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第8张图片
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标准差}的最大值

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第9张图片
示例:

  • 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 (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第10张图片
XLINK的无线感知主路径选择:5G SA > 5G NSA > WiFi > LTE

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

ACK_MP路径选择

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第11张图片
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反馈机制

多路径初始化

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第12张图片
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 双阈值控制参数选择

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第13张图片

根据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的比例(此时很可能引发卡顿)
XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第14张图片

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

7.2 大规模A/B测试

传输指标:请求完成时间
XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第15张图片
连续两周的线上测试表明,对于中位数、尾部请求完成时间(RCT),XLINK可以稳定优于单路径,因为它有效地解决了MP-HoL问题

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

QoE指标1:卡顿率
XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第16张图片
卡顿率下降:23.8%~67.6%

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

QoE指标2:首帧时延
XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第17张图片
观察:

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

7.3 极限移动性

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

  • SP(单路径)
  • Vanilla-MP
  • MPTCP
  • QUIC CM(connection migration,连接迁移)

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第18张图片
实验观察(RCT的中位数与最大值):

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

7.4 能耗

XLINK (SIGCOMM ‘21) MPQUIC多路径传输论文阅读笔记_第19张图片
实验环境: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转移,这种情况下应选择耦合拥塞控制策略

你可能感兴趣的:(论文阅读笔记,#,多路径传输,论文阅读,笔记,多路径传输,MPQUIC,QUIC)