近些年来以5G和Wifi6为代表的无线通信技术发展迅速并已经在全世界实现了大规模部署。此外智能手机等移动设备不断迭代更新其网络通信能力也持续演进使得应用同时利用多个不同网卡在多条不同物理链路上如5G和WiFi传输数据成为可能。加之新兴应用对于带宽的需求与日俱增多路径传输技术得到了广泛关注。多路径传输基于不同的传输层协议主要分为多路径TCPMultipath TCPMPTCP[1]和多路径QUIC (Multipath QUICMPQUIC) [2-4] 两类。MPTCP是传输层使用最广泛的多路径技术并已经得到了商用智能手机操作系统如iOS[5]和Android[6]的支持。然而TCP本身存在固有弊端例如其实现在内核级别难以与应用层进行结合且对于应用提供商而言难以进行针对性的性能优化。为解决这一问题MPQUIC利用了QUIC传输协议[7-8]的用户空间特性可以方便地集成并部署到应用中。概述多路径传输领域的学术研究在过去主要针对MPTCP开展。MPQUIC的部分核心设计仍沿用MPTCP不过其基于QUIC和易与应用结合的特性使其能够针对不同应用如点播视频、短视频、低时延实时视频等进行深入优化。多路径的研究内容主要包括[9]数据包调度、多路径耦合拥塞控制、子流/路径管理、能耗[27]、安全性等。其中数据包调度是多路径设计最核心的部分之一。数据包调度器负责确定每个数据包应该由哪个路径子流进行发送致力于解决两个关键问题[10-11]多路径队首阻塞Head-of-Line blocking由在慢子流分配过多数据引起由于多路径传输需保证按序交付快子流必须等待慢子流数据包到达从而导致整体传输性能下降接收缓冲区窗口限制由数据包乱序到达引起慢子流的数据包占据了接收缓冲区导致发送窗口被阻塞影响快子流的充分利用。本文重点梳理多路径传输中数据包调度机制的设计空间与发展历程。有关多路径视频流的相关研究推荐阅读Chorus: Coordinating Mobile Multipath Scheduling and Adaptive Video Streaming - ACM MobiCom 24。相关开源仓库ChorusChorus-Android-Player设计空间多路径数据包调度器可以分为四类相关综述可以参见[9][29-32](1) 简单调度器轮询Round-RobinRR没有优先级按照轮询的顺序将数据包填满各子流的发送窗口不足忽略外部因素拥塞、丢包等对子流传输的影响无法保证数据包按序到达最小往返时延优先Lowest-RTT-FirstLowRTT/MinRTT[10]将子流按RTT大小确定优先级按优先级排序将数据包依次填满子流的发送窗口优势让路径质量好的子流承载更多的数据包有一定负载均衡的效果不足无法保证数据包按序到达存在多路径HoL阻塞和接收窗口限制等问题机会性重传和惩罚opportunistic retransmission and penalizationRP[11]为了补偿不同路径上的时延差异以缓解HoL阻塞机会重传会在其他可用子流重传重注入引发HoL的数据包惩罚机制会将阻塞的子流的拥塞窗口减半以限制其使用不足惩罚机制会减少聚合带宽缓冲区膨胀缓解bufferbloat mitigationBM[12]通过限制传输的数据量拥塞窗口减半来排空网络缓冲区中的队列从而降低RTT不足随机作用不总是有效会反复触发拥塞ReMP[13]为了提高可靠性将数据包冗余发送到所有子流上不足会产生额外的开销eMPTCP[14]在路径管理和数据包调度中考虑多路径的功耗不足主要针对功耗进行设计没有考虑性能提升MPTCP默认调度器用的是MinRTT[10]RP[11]也包含RR与ReMP[13]。(2) 基于路径质量估计的调度器如BLEST[21]ECF[22]MuSher[25]等(3) 基于路径时延差的调度器如DEMS[23]STMS[24]RAVEN[26]等(4) 基于机器学习的调度器如ReLes[27]Peekaboo[28]等其中第二、三类和第四类的大部分工作其设计思想可以统一归为“乱序发生按序到达”。乱序发送按序到达目前主流的数据包调度器采用乱序发送按序到达的思想并非将连续的数据包分别分配到快子流和慢子流上如MinRTT[10]而是为快子流提前预留一部分数据包超出其拥塞窗口以便下一个RTT发送以尽可能多地利用快子流进行传输从而提高多路径传输整体的聚合带宽。其核心思想如下图所示[24]代表性研究工作的发展过程为Westwood SCTP[15]根据RTT与可用带宽估计值估计不同路径上数据包的到达时间据此对每条传输路径进行性能排序并按降序选择路径传输数据包不足当不同路径之间存在显着不同的时延时效果不佳FPSForward Prediction Scheduling[16]估计传输路径上数据包的到达时间以及其他路径非传输路径上的数据传送时间实现所有路径上的数据同时到达不足没有考虑丢包的影响[9]F2P-DPSFine-grained Forward Prediction based Dynamic Packet Scheduling[17]DAPSDelay Aware Packet Scheduling[18-19]有两个版本[18] 在接收buffer受限的环境下为了减少接收buffer的阻塞时间基于子流的转发时延倒数和CWND来确定各子流分配的数据包数量按照时延从小到大的顺序依次为各子流分配数据包确保在各子流转发时延的最小公倍数LCM内所有数据包按序到达[19]针对只有两个子流的场景设计是原始算法[18]的简化及实践扩展提出了最大接收buffer阻塞时间的分析模型不足若子流时延的差异较大LCM较大则调度时间周期较长无法及时对网络变化做出反应使用所有可以发送的子流即使某个子流的贡献非常低慢路径没有考虑使用重注入重传[21]OTIASOut-of-order Transmission for In-order Arrival Scheduling[20]不足没有考虑拥塞窗口的可用性可能会导致不必要的重传[21-22]BLESTBLocking ESTimation[21]为了避免慢子流数据包阻塞发送窗口使用RTT和CWND等参数计算快子流在一个慢子流的RTT内可以发送的数据包数量通过减少不必要的重传次数来最小化HoL阻塞不足会导致部分子流如空闲的快子流[22]未充分利用从而延长较大文件的下载时间ECFEarliest Completion First[22]利用RTT、带宽拥塞窗口大小、发送缓冲区等信息估计数据包传输时间当无待发数据发送缓冲区为空时视情况等待可用快子流而非直接使用慢子流发送尽可能提高快子流的利用率从而提升聚合吞吐量不足在多数时间里大象流的发送缓冲区都是满的ECF只有在流即将结束时尾部数据包才能起到调度作用。 此外ECF在计算流完成时间FCT时没有考虑单向延迟因此无法实现准确的有序到达[24]DEMSDEcoupled Multipath Scheduler[23]感知数据块边界快子流从前向后发送慢子流从后向前发送以此将子流解耦通过估计RTT单向时延OWD和带宽来实现快慢子流传输的同时完成并根据网络情况重注入数据包不足需要一个巨大的缓冲区来存储整个块[24]主要针对两个子流进行设计多路径扩展性不佳[26]STMSSlide Together Multipath Scheduler[24]为了解决链路及接收端缓冲区受限时多路径聚合带宽下降的问题根据数据包被ACK的情况来动态调节快慢子流间数据包序列号的间隔gap以充分利用快子流并实现数据包的按序到达不足调节gap的过程偏启发式可能不是最优策略参考文献Ford A, Raiciu C, Handley M, et al. TCP extensions for multipath operation with multiple addresses[R]. 2013.Olivier Bonaventure. Apple uses Multipath TCP[EB/OL]. [2018-12-15]. http://blog.multipath-tcp.org/blog/html/2018/12/15/apple_and_multipath_tcp.html.Olivier Bonaventure. In Korean, Multipath TCP is pronounced GIGA Path[EB/OL]. [2015-07-24]. http://blog.multipath-tcp.org/blog/html/2015/07/24/korea.html.De Coninck Q, Bonaventure O. Multipath quic: Design and evaluation[C]//Proceedings of the 13th international conference on emerging networking experiments and technologies. 2017: 160-166.Viernickel T, Froemmgen A, Rizk A, et al. Multipath QUIC: A deployable multipath transport protocol[C]//2018 IEEE International Conference on Communications (ICC). IEEE, 2018: 1-7.Liu Y, Ma Y, De Coninck Q, et al. Multipath Extension for QUIC[R]. 2023.Iyengar J, Thomson M. QUIC: A UDP-based multiplexed and secure transport[M]//RFC 9000. Fremont, CA, USA: Internet Engineering Task Force (IETF), 2021.Langley A, Riddoch A, Wilk A, et al. The quic transport protocol: Design and internet-scale deployment[C]//Proceedings of the conference of the ACM special interest group on data communication. 2017: 183-196.薛开平, 陈珂, 倪丹, 等. 基于 MPTCP 的多路径传输优化技术综述[J]. 计算机研究与发展, 2016, 53(11): 2512-2529.Paasch C, Ferlin S, Alay O, et al. Experimental evaluation of multipath TCP schedulers[C]//Proceedings of the 2014 ACM SIGCOMM workshop on Capacity sharing workshop. 2014: 27-32.Raiciu C, Paasch C, Barre S, et al. How hard can it be? designing and implementing a deployable multipath {TCP}[C]//9th USENIX symposium on networked systems design and implementation (NSDI 12). 2012: 399-412.Ferlin-Oliveira S, Dreibholz T, Alay Ö. Tackling the challenge of bufferbloat in multi-path transport over heterogeneous wireless networks[C]//2014 IEEE 22nd International Symposium of Quality of Service (IWQoS). IEEE, 2014: 123-128.Frommgen A, Erbshäußer T, Buchmann A, et al. ReMP TCP: Low latency multipath TCP[C]//2016 IEEE international conference on communications (ICC). IEEE, 2016: 1-7.Lim Y, Chen Y C, Nahum E M, et al. Design, implementation, and evaluation of energy-aware multi-path TCP[C]//Proceedings of the 11th ACM Conference on Emerging Networking Experiments and Technologies. 2015: 1-13.Casetti C, Gaiotto W. Westwood SCTP: load balancing over multipaths using bandwidth-aware source scheduling[C]//IEEE 60th Vehicular Technology Conference, 2004. VTC2004-Fall. 2004. IEEE, 2004, 4: 3025-3029.Mirani F H, Boukhatem N, Tran M A. A>