The Road to multipath QUIC: 阿里自研多路径传输技术XLINK

简介: 阿里巴巴淘系技术部淘系架构团队与达摩院XG实验室共同研发的XLINK多路传输技术,相关论文「XLINK: QoE-driven multi-path QUIC transport in large-scale video services」已经被顶级学术会议SIGCOMM 2021正式接收, 这也是SIGCOMM会议历史上第一篇关于多路径QUIC的论文。

原创 XLINK项目组 淘系技术  5月11日

640.gif


阿里巴巴淘系技术部淘系架构团队与达摩院XG实验室共同研发的XLINK多路传输技术,相关论文「XLINK: QoE-driven multi-path QUIC transport in large-scale video services」已经被顶级学术会议SIGCOMM 2021正式接收, 这也是SIGCOMM会议历史上第一篇关于多路径QUIC的论文。



综述

你是否曾经经历过

(1)当你看视频刷剧刷的正嗨,突然发现视频变得很卡, 怎么重连也没有用?(2)当你打着语音电话从商场走向停车场,电话一下子就断了,必须要拨号重连?

(3)当你想要争分夺秒地在高速上办公,但是发现邮件怎么也发不出去?


上述问题的产生都可以归结为一个问题,那就是“弱网”。由于无线网络天生的频谱限制,无线信号的覆盖不足,多用户间的相互竞争资源,高移动场景下频繁的基站切换等等, 都可能导致“弱网”的频发。克服弱网对于用户的体验至关重要。为此, 阿里巴巴淘系技术部淘系架构团队与达摩院XG实验室共同研发了XLINK多路传输技术。XLINK使淘宝的用户可以同时使用多路径(5G/4G,WiFi)进行传输数据, 从根本上解决了由单路径弱网带来的用户体验问题。XLINK基于阿里巴巴提出的IETF多路径Multipath QUIC草案[1],该草案也是目前唯一一个经过大规模实践检验的Multipath QUIC标准草案。


QUIC技术是由Google提出,谷歌于2017年在SIGCOMM会议上发表了QUIC相关论文并引起了业界的巨大反响今年IETF QUIC 1.0标准工作即将正式完成,下一代HTTP协议HTTP3正是基于QUIC来实现的。可以说,QUIC是目前移动互联网中最核心和关键的传输技术,现如今,超过50%的Chrome浏览器流量和75%的Facebook流量都在使用QUIC进行传输。经过过去几年的不懈努力,阿里巴巴从QUIC技术的追随者快速成长为QUIC技术的创新者,并在多路径QUIC技术上取得了突破,XLINK相关论文已经被顶级学术会议SIGCOMM 2021正式接收,这也是SIGCOMM会议历史上第一篇关于多路径QUIC的文章。


XLINK 相关文章论文参考:Zhilong Zheng†, Yunfei Ma†, Yanmei Liu†, Furong Yang, Zhenyu Li, Yuanbo Zhang, Jiuhai Zhang, Wei Shi, Wentao Chen, Ding Li, Qing An, Hai Hong,  Hongqiang Harry Liu, and Ming Zhang, XLINK: QoE-driven multi-path QUIC transport in large-scale video services, to appear in SIGCOMM 2021. (†表示共同一作)



XLINK基于阿里巴巴提出的IETF多路径(Multipath)QUIC草案框架实现,该草案由淘系架构与XG实验室主导、与集团标准化部、中科院计算所,以及原Internet Architecture Board的主席Christian Huitema进行了深度论证与合作,也是目前唯一一个经过大规模实践检验的Multipath QUIC标准草案。



XLINK基于阿里巴巴提出的IETF多路径(Multipath)QUIC草案参考:

Yanmei Liu, Yunfei Ma, Christian Huitema, Qing An, and Zhenyu Li. Multipath Extension for QUIC, Internet Engineering Task Force, December 2020. Work in Progress. https://tools.ietf.org/html/draft-liu-multipath-quic-03


多路径技术:学术界、工业界长达十年的探索


使用两条路径同时传输, 这个想法听起来很简单, 可是做起来却很难。目前业界成功仅有的比较成功部署多路径传输的是Apple的Siri、Apple Music等场景(苹果采用的是MPTCP RFC6824, 该协议于2013年被IETF标准化),这些应用都是音频(Audio)类,它们主要是利用多路径增加传输的鲁棒性。但过去在业界视频应用(Video)或者实时类的音视频类(Real-time Video)应用上,对多路传输技术的大规模应用是极少见的,因为这类场景对于数据的带宽速率和时延都有着非常苛刻的要求。而在无线网络中, 路径质量的变化是很快的, 过去的多路径协议和调度算法在高速变化的场景下会发生明显的失速现象。在XLINK之前,多路径传输在音视频方面迟迟无法得到施展,学术界也为此奋斗了很多年,大家提出了很多基于MPTCP的优化方案, 但是目前没有一个方案可以完全解决存在着如下几个本质缺陷:


  • 内核实现、无法为应用场景提供定制优化:音视频应用有一个特点, 那就是不同应用间的体验目标(QoS)差异非常大,需要的传输协议和算法也很不一样。比如短视频应用(手淘短视频)注重秒开率,高清长视频应用(优酷)对于带宽要求高,视频会议, 直播(钉钉,手淘直播)更在意延迟和流畅度。这些差异巨大的应用场景需求,需要传输算法和协议针对应用自身的QoS需求做特殊优化,可是MPTCP位于操作系统内核的网络协议栈,所有应用都使用同一套算法,这就导致众口难调,同时传输协议和调度算法的优化迭代也非常困难。


  • 异构网络:MPTCP的多路聚合效果并不理想,由于在公网上传输多路径是异构的,5G/LTE和Wi-Fi的时延差异较大,此时就会发生多路径的队头阻塞问题(MP-HOL)[2]。MP-HOL阻塞问题是指,当一部分数据包走慢路径,一部分数据包走快路径的时候,快路径的包会先抵达,但是要等待慢路径包到达以后才能传给应用,造成延迟增加,部分情况下甚至会比两条路径中质量较好的单路更差。更大的挑战在于无线链路的变化很快,因此目前的带宽预测是很难做到十分准确(在无线场景下我们很难预知下一秒的带宽情况)。所以基于带宽预测的调度算法在长尾问题上面频繁的折戟沉沙。


  • 流量成本:为了克服异构网络问题,有一些多路径传输方案选择发送冗余包(将同样的数据包在两条路径上重复发送)去避免多路队头阻塞问题, 但是又引入了两个新问题:1.重复发送数据包会极大的增加额外的数据流量成本。这个对于视频应用来说会带来高额的带宽成本,这也是为什么Apple也只在Siri等对于流量要求不大的音频场景中使用MPTCP。2.冗余数据包也会占用带宽资源,这又降低了整体的带宽利用效率。


其它的多路径方案比如MPUDP和MPRTP目前也有各自的困难与局限。首先UDP不保证数据包传递的可靠性, 因此多路的时延不同会给上层应用带来大量的乱序包, 并且UDP也不对丢包进行恢复, 所以目前几乎很少被使用。MPRTP自提出以来一直没有被真正大规模落地[6],原因是MPRTP在将数据包分配到各个路径时,依赖于各路径的带宽和时延精确估计,可是除非拥有大量物理层信息,LTE信号的预测本身就是一个非常难以解决的问题。


XLINK:用户体验驱动的(QoE-driven)的多路径方案


  为什么叫XLINK?


XLINK(= X+LINK),本意为通过多条路径链接(LINK),其中X代表一个未知数,也代表在阿里巴巴不断探索未知领域。XLINK技术基于QUIC协议在用户态实现了WiFi/LTE/5G的多路径并行传输,有效提升传输带宽, 大幅度降低传输时延与卡顿率,在高移动性场景展现出优秀的传输稳定性。与此同时,XLINK也是全球首个在大规模视频场景部署与验证的多路径QUIC通信协议。XLINK的使用非常方便,XLINK实现在用户态协议栈XQUIC[3]中,支持Android/iOS/Linux等平台部署,对于移动端app开发者来说只需要集成XQUIC协议库便可以使用XLINK技术,对于用户来说只需要升级app就可以享受到多路径传输带来的体验收益[4]


为了突破单路径传输的根本限制,并解决MPTCP等多路径协议在过去实践中遇到的各种落地问题, 我们开发了XLINK。XLINK与之前所有多路径技术最大的不同是,它直接利用应用的QoE信息实现路径的选择、切换与调度策略。从技术角度来说, XLINK突破了传统多路径协议的设计框架,在QUIC用户态特性的基础之上, 提出了Client-Server QoE反馈驱动多传输调度方案, 克服了过去十多年困扰多路径协议(比如MPTCP, MPUDP & MPRTP[5])在实际公网部署的两大难题:

  • 多路队头阻塞问题带来的传输失速和聚合效率降低的问题
  • 冗余数据包发送引入的高昂额外带宽成本与流量开销


XLINK的整体架构如图1所示, 具有以下几个特点:


image.png

Fig.1. XLINK整体方案架构


  1. 用户态部署:XLINK工作在用户态,集成在App当中并在UDP之上实现了数据的可靠传输与拥塞控制。它伴随应用快速部署与迭代,即插即用。XLINK的手机端的应用可以做到以周为单位更新,XLINK服务端的应用和算法更新可做到天或小时为粒度。由于XLINK实现在用户态协议栈中,与app集成在一起,因此XLINK可以直接针对不同的应用做定制化优化。


  1. 高性能:XLINK利用视频应用的QoE反馈作为调度器的控制信号,QoE信号可以包含多种与用户体验相关的参数,通过这个QoE反馈控制调度器, XLINK成功克服了MP-HoL所带来的性能和成本问题, 使多路径技术在大规模视频应用中的使用变得可行。XLINK进行多路径调度时, 并不需要对于路径的带宽和时延作精确的估计, 而是采取了数据包重注入(Reinjection)的自适应补偿方法, 让数据包自适应的在多条路径上实现均衡。此外, XLINK通过对于用户QoE的理解,可以进一步优化用户体验。比如,XLINK可以针对短视频的首帧进行特殊优化,降低用户的首帧下载时间,从而提升用户的秒开率。


  1. 低成本:XLINK的调度算法不仅可以克服MP-HoL所带来的性能问题, 而且几乎不增加额外的数据量,QoE的反馈帮助XLINK调节重注入的力度, 达到最优的性能与成本之间的平衡, 所以码率很高的视频应用也可以放心的大规模使用多路径传输而不用担心其流量成本问题。


  1. 轻量化:XLINK完全基于C语言开发(在XQUIC用户态协议栈中实现),XQUIC总体的包大小只有300+KB,非常适合各种移动终端的使用。


手淘落地效果


XLINK已经集在在手淘完成了大规模灰度验证,测试结果表明,XLINK在弱网下使用可以实现短视频分片平均下载耗时减少15.03%,视频分片下载弱网耗时降低25.28%[5]。此外,在旅途中,XLINK的用户可以同时利用WiFi热点与手机LTE, 在高移动性场景下仍然保持流畅的视频观看体验。


XLINK手淘Demo展示:


下面的视频展示了XLINK集成在手淘里的使用效果,左边的应用使用打开了WiFi与LTE的XLINK,右边的应用使用打开了单路径WiFi的QUIC;可以看出XLINK起播更快,而且全程播放流畅,而单路径的case在播放过程中由于WiFi网络抖动,产生了明显卡顿。

image.png

点击查看原视频


展望未来


达摩院XG实验室与淘系技术合作研发的多路径QUIC技术XLINK,该技术不但在手淘短视频等场景有很好的体验优化效果——在弱网条件下短视频下载时间可降低25%以上;今年开始逐步全量手淘短视频和手淘逛逛——而且多路径QUIC草案也在IETF QUIC工作组受到广泛关注。随着XLINK不断在国际舞台被同行认可,可以说XLINK目前在技术领先性、国际标准的制定、内部业务赋能方面,都取得了振奋人心的成绩。

我们处在通往5G与边缘计算的时代的关键节点, 随之而来的网络架构和技术将会产生革命性的变化。5G将进一步加速大数据、人工智能、海量存储等多元化、端计算与边缘计算业务与应用技术的爆发式增长。由此可推断,无线网络作为这些新型业务的入口,势必会再次迎来技术变革,迈向高性能、高稳定、高敏捷的新一代网络,以响应这些新型业务。

同时,伴随着视频应用的不断丰富和视频QoS需求的异构化, 曾经的一套传输层适配所有应用的做法难以达到更好的QoE,以QUIC为代表的用户态协议栈通过与视频应用联合优化,可以实现曾经内核协议栈无法达到的极致的效果。XLINK通过将QoE与多路径结合,证明了这种协同效果的强大威力。后面我们也会进一步推动XLINK相关技术在IETF的标准化,同时也期待XLINK技术可以更好的服务阿里巴巴的用户。


附录


[1] Multipath QUIC草案: https://tools.ietf.org/html/draft-liu-multipath-quic-03

[2] MP-HOL阻塞问题:指Multi-path Head-of-line blocking问题

[3] XQUIC是阿里自研的IETF QUIC标准化协议库

[4] 由用户决定是否开启和关闭

[5] 这里弱网统计指视频分片的p99分位长尾下载耗时

[6] Singh, Varun, Saba Ahsan, and Jörg Ott. "MPRTP: multipath considerations for real-time media."Proceedings of the 4th ACM Multimedia Systems Conference. 2013.

相关文章
|
人工智能 达摩院 算法
Qcon演讲实录 | XQUIC与多路径传输技术Multipath QUIC
大家好,我是阿里巴巴淘系技术部的刘彦梅(花名喵吉),今天给大家介绍的演讲内容是<XQUIC与多路径传输技术>, 下面是我在Qcon 2020上海站大会上的演讲内容,收录于专题<5G+人工智能>。这个演讲内容围绕XQUIC与多路径传输技术Multi-path QUIC,其中面向5G的多路径传输协议,算法和技术由淘系架构团队与达摩院XG实验室/阿里云AIS网络研究团队的研究人员共同研发(XG实验室/网络研究主要参与同学包括:马云飞,郑智隆,刘洪强),之前有一篇介绍XQUIC的相关内容<面向5G的阿里自研标准化协议库XQUIC>,大家有兴趣可以对照阅读。
|
物联网
ZigBee TI ZStack CC2530 4.11 单播通信00-总
(配套源码、软件、开发板等资源,可移步博客同名QQ群/TB店铺:拿破仑940911) (配套源码、软件、开发板等资源,可移步博客同名QQ群/TB店铺:拿破仑940911)
1162 0
|
物联网 网络架构
ZigBee TI ZStack CC2530 4.3 自组网
(配套源码、软件、开发板等资源,可移步博客同名QQ群/TB店铺:拿破仑940911) 一、基本的网络参数配置(参考《Z-Stack Sample Applications.pdf》) 1、Device Types(设备类型) 在ZigBee网络中存在三种逻辑设备类型:Coordinator(协调器)、Router(路由器)和EndDevice(终端设备)。
2232 0
|
物联网
ZigBee TI ZStack CC2530 4.1 三种网络设备类型
(配套源码、软件、开发板等资源,可移步博客同名QQ群/TB店铺:拿破仑940911) (配套源码、软件、开发板等资源,可移步博客同名QQ群/TB店铺:拿破仑940911)
1168 0
|
物联网
ZigBee TI ZStack CC2530 4.16 绑定通信00-总
(配套源码、软件、开发板等资源,可移步博客同名QQ群/TB店铺:拿破仑940911) (配套源码、软件、开发板等资源,可移步博客同名QQ群/TB店铺:拿破仑940911)
1013 0
|
物联网
ZigBee TI ZStack CC2530 4.4 设备地址00-总
(配套源码、软件、开发板等资源,可移步博客同名QQ群/TB店铺:拿破仑940911) (配套源码、软件、开发板等资源,可移步博客同名QQ群/TB店铺:拿破仑940911)
1202 0
|
传感器 物联网 网络架构
ZigBee TI ZStack CC2530 5.1 实例(一)大规模组网实验
(配套源码、软件、开发板等资源,可移步博客同名QQ群/TB店铺:拿破仑940911) 本文中,我们将验证Z-Stack协议栈的中等规模组网实验,看看当ZigBee网络中的节点逐渐增加之后,网络是否依旧稳定。
2627 0
|
物联网
ZigBee TI ZStack CC2530 4.17 绑定通信01-概念介紹
(配套源码、软件、开发板等资源,可移步博客同名QQ群/TB店铺:拿破仑940911) 上一节中,我们详细介绍了ZigBee的第三种无线通信方式——组播;本节中,我们将介绍ZigBee的最后一种,也就是第四种无线通信方式——绑定。
1651 0
|
存储 数据安全/隐私保护 数据中心
揭密Emulex SAN光纤云存储网关的概念
本文讲的是揭密Emulex SAN光纤云存储网关的概念,EMC一位技术顾问DaveGraham最近更新的博客揭示了EmulexSAN光纤云网关的概念。
1528 0