文章目录
总结Abstract1 Introduction1.1 背景1.2 挑战1.3 XLINK介绍思想&方法优势&提升
2 Motivation2.1 短视频2.2 QUIC2.3 移动性支持2.4 5G下的多路径
3 Experience with Vanilla Multi-path QUIC3.1 Vanilla-MP in 仿真环境3.3 Vanilla-MP in 真实环境
4 XLINK Design Overview5 QoE-Driven Scheduling and Path Management5.1 基于优先级的重注入重注入的作用QUIC优化：基于流优先级的重注入首帧加速：基于视频帧优先级的重注入
5.2 基于QoE反馈的重注入控制QoE信号采集双阈值控制
5.3 感知QoE的路径管理主路径选择ACK_MP路径选择
6 Protocol and Implementation多路径初始化帧扩展路径关闭路径保护（安全性）负载均衡支持Android APP客户端集成CDN服务器部署
7 Evaluation7.1 双阈值控制参数选择7.2 大规模A/B测试7.3 极限移动性7.4 能耗
8 Related WorkMPQUICMPTCP多路径数据包调度跨层视频优化
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耗能与单路径差不多）蜂窝数据流量：无特殊设计（只针对免流用户）网络编码：无
*注：
关于多路径数据包调度相关介绍，可参阅：多路径传输（MPTCP&MPQUIC）数据包调度研究总结文中“【】”中的内容为个人想法，仅供参考。
Abstract
XLINK的两个设计目标：
最大化QoE最小化服务提供商（CDN）的成本开销
XLINK的两个基础：
用户态协议QUIC感知QoE
挑战：
多路径head-of-line（HoL）阻塞网络异构性链路的快速变化平衡成本和性能
实验：
环境：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.
两个观察
短视频的卡顿和启动时延严重影响用户满意度消费者渴望看到更好的细节和更有参与感的需求，推动了短视频朝着更高码率的方向发展
问题：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 PipeSource Pipe：将分割后的音视频帧发送至其对应的Decoder；记录缓存帧的数量及字节数（buffer）Decoder：解码，有音视频码率和帧率信息Decoder PipeRenderer 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-MPMPTCPQUIC 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的能耗最低，但吞吐量也远低于XLINKXLINK更适用于对高带宽和时延有需求的应用（如视频）
8 Related Work
MPQUIC
QUIC的多路径扩展方案：
MPQUIC草案MPQUIC - CoNEXT’17MPQUIC - ICC’18PQUIC - 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、PensieveRTC：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转移，这种情况下应选择耦合拥塞控制策略
参考阅读
您阅读本篇文章共花了：
发表评论