论文题目：XLINK：QoE-Driven Multi-Path QUIC Transport in Large-scale Video Services

所属会议：SIGCOMM 2021（CCF A）

博客目的：论文阅读时的翻译总结，供同行学习参考

XLINK:

Ⅰ. Introduction

1. 两个观察结果：短形式产品 视频摊位和 启动延迟 显著影响用户满意度 / 消费者希望看到更多的细节，更有参与感 <促使 推动视频向更高的数据速率发展>
2. 多路径传输的关注度高 👆，最著名 “MPTCP” 缺点：需要智能手机的操作系统级支持，非手机制造商的移动应用程序提供商来说，部署成本非常高.

• “ Quic 优势”: 与TCP不同，QUIC作为一种 **” 用户空间协议”**，可以作为应用的一部分进行安装和升级，因此作为端到端解决方案的多路径 QUIC 可以快速部署并不断发展

3. 问题：最近的提案 [7,13 ]被设计为支持通用流量，如 “ 网络和批量数据传输” ，并没有 “ 针对视频” 进行优化
4. 尝试：将多路径 quic 部署到大规模网络中， 理论是是比单路经要快，但是结果相反，有效地利用 聚合的无线资源 比预期的要 困难得多。
   • 主要障碍：由 “快速变化和异构路径” 引起的 multi-path head-of-line （多路径线性头 MP-HoL）阻塞问题 <”code_004”>
   • 解决上述问题的一个方法是发送冗余包，过 去发送数据副本的多路径解决方案可能适用于 “ 音频服务” [22]，但它们不适用于视频，因为流量要大得多
5. 令人惊讶的是，到目前为止，在大规模视频服务中使用 “ 多路径的可行性和好处仍然不清楚”
6. XLINk 关键思想：利用 QUIC 作为 “ 用户空间协议” 的机会，直接捕获视频 QoE 意图来控制多路径调度和管理 :
   • 不注重网络预测精准度，依靠客户机的**” QoE反馈” 来 “动态控制” 服务器调度程序中的数据包重新注入**的侵略性.
   • 多并发 quic流下，通过 “ 基于流优先级的重注入“ ，XLINK 根据流的紧急程度仔细确定发送顺序，从而实现更流畅的流体验
   • 引入了基于视频帧优先级的重注入的第一视频帧加速
7. Contribution :
   1. 提出了生产环境中 多路径QUIC 视频传输的第一次大规模实验研究，以证明可行性和可部署性
   2. 我们指出，从 “ 根本上” 解决上述挑战的关键 是**利用QUIC “ 作为用户空间协议”**，允许它与应用程序密切交互，并使用视频QoE进行调度和路径管理 。
   3. 揭示了在以前的文献中较少讨论的关于性能、成本、移动性、兼容性和网络异质性的实际挑战，并分享了我们在应对这些挑战方面的经验
8. 特别的：XLink 利用远程反馈 控制 “ 多路径数据包重注入” 背后的创新超出了端到端视频传输的范围，可以作为一种通用的高性能多路径传输机制;
   • 基于**” 流和帧优先级”** 的调度利用 QUIC 表达视频感知的能力，因此更加特定于QUIC!

< **XLINK的** 多路径协同作用和应用程序的qos意识的影响 超出了短视频，并为直播、360度视频、增强现实(AR)和虚拟现实(VR)等其他令人兴奋的研究领域铺平了新的道路>

Ⅱ. Motivation

1. 现状：

   • 观看者对短视频 QoE 缺陷的容忍度低于长视频
   • 消费者对视频内容的需求正在向 4K 及以上 (如AR和VR) 发展，这可以要求超过85Mbps的比特率[28]

2. Road to QUIC ：

   • TCP相比，QUIC更快、更安全，并提供防止协议僵化的保护
   • QUIC的用户空间属性是克服主要障碍的关键，如性能不理想、处理负载平衡器的困难、获得操作系统级支持以及穿越阻碍MPTCP使用的中间层[5,31,32]

3. Better mobility support:

   移动性支持在无线通信中至关重要！

   • QUIC引入了连接迁移(connection migration, CM)[34]，但连接迁移需要迁移后重置拥塞窗口，这可能不适合视频流，因为视频流需要持续的高带宽
   • MPTCP在 Sir i中支持Wi-Fi-LTE漫游的好处，已被证明，还不清楚多路径在部署的视频服务中是否仍然有效

4. Multi-path in 5G：

   • 5G ：

     • 优势：更高的带宽
     • 劣势：传播损耗更大；穿透能力更弱；信号覆盖范围更小

Ⅲ. Experience with vanilla Multi-Path QUIC

• 多路径性能面临的两个重大挑战：
  • 移动性
  • 路径延迟差异
• 基本流程：
  1. 研究了vanilla-MP在移动环境中的动力学
  2. 讨论了通过不同无线技术访问视频服务器时测量到的路径延迟差异
  3. 展示了vanilla-MP在我们的生产环境中的大规模A/B测试中如何对抗单路径 QUIC (SP)

We implemented vanilla-MP with the min-RTT packet scheduler as described
in MPQUIC [12]. The min-RTT packet scheduler is also the default packet scheduler
used in Linux kernel MPTCP

1. Fast changing wireless links :

   • 使用Mahimahi仿真工具绘制了在我们的校园行走时收集的一对Wi-Fi和LTE轨迹重放其飞行数据包的动态图：
     • 
     • LTE走线相对稳定
     • Wi-Fi走线变化迅速，吞吐量从1.7s下降到2.2s，几乎为零
       • 拥塞窗口(CWND)无法跟上这种快速变化
       • 结果:
         1. 调度器仍然在该路径上继续发送数据包
         2. 如此快速的变化可能导致严重的HoL阻塞，因为视频帧无法传送到应用程序，直到**慢路径(Wi-Fi)**上所有停滞的数据包经过很长一段时间恢复.

2. Path delays in heterogeneous networks

   1. 为了了解路径延迟差异，在通过不同的无线技术访问视频服务时测量了 RTT
   2. 无线技术对于 Path delay 有显著影响：
      • LTE的路径延迟中位数分别是Wi-Fi和5G SA的2.7倍和5.5倍，
      • LTE的 90𝑡 百分位数路径延迟是Wi-Fi的3.3倍
   3. 在多路径中，路径延迟差异随着跨 ISP 延迟的增加而进一步增大
      • 短视频服务中，路径延迟的巨大差异可能会影响视频启动延迟和请求完成时间

3. Deployment of vanilla-MP

   1. 我们通过在短视频服务中针对单路径**QUIC (SP)**进行大规模 A/B 测试，验证了vanilla-MP的有效性3:

      (视频块请求完成时间(RCT)在一周内收集)
      <img src="./XLINK/image-20230918093825351.png">

      • Vanilla-MP 仅在中位数和90𝑡h百分位RCT中有效，并且可能导致更差的表现（第1,3,4和5天）。最大的中位数RCT退化为16%。
      • Vanilla-MP 总是导致99𝑡百分位RCT的退化，甚至比SP(第4天和第7天)差28%

4. 在下表中，我们报告了一周内观察到的客户端视频重缓冲率的降低(以视频播放时间总量归一化的视频重缓冲时间总量来衡量)。
   

   1. 负数表示 vanilla-MP 的再缓冲速率比SP差
   2. 它不但没有减少，反而增加了34%以上，最大增幅高达96%
   3. 由于上面讨论的问题，这样的结果并不令人惊讶，因此 vanilla-MP 未能达到不比单路径传输更差的性能标准.

Ⅳ. XLINK Design Overview

goal: 以最小的开销成本实现最佳的用户感知的QoE(ex:低延迟和小的重新缓冲)

• 如上所示： XLINK被设计为部署在移动应用和边缘服务器中的轻量级端到端多路径QUIC扩展
• 促使：多家庭移动客户端能够通过多个无线接口(例如，Wi-Fi和蜂窝)同时传输与远程服务器通信
• 特征：与过去的解决方案**(如MPQUIC和MPTCP)不同，这些解决方案无需应用程序的辅助**；
  XLINK由 跨层网络设计的最新趋势 驱动[41]，并将传输与视频应用紧密集成在一起，同时实现高性能和成本效益。
• 核心：利用QUIC作为用户空间协议的机会，在 多路径调度和管理中利用 用户感知的视频QoE。

1. 体系结构上：XLINK的 QOS 驱动调度构建 在客户机-服务器反馈机制之上

   • XLINK客户端 捕获用户感知的QoE信号 (例如，视频播放器缓存的帧和视频播放器帧率)
   • 使用 ACK_MP扩展帧 (第6节) 将这些信号 传送到 远程视频服务器以控制其调度
     <img src="./XLINK/image-20230918103943018.png" alt="image-20230918103943018" style="zoom:80%;" />
   • QoE_control_signal字段的使用 控制了多路径的耦合和解耦, 它允许XLINK克服多路径HoL阻塞，而不会产生不必要的成本开销，这对于大规模部署至关重要 (第5.2节 阐述)
     • XLINK通过提供 第一视频帧加速(5.1)、 无线感知主路径选择(5.3) 和 最快路径ACK_MP来进一步处理大路径延迟差异，以避免慢路径造成的过度延迟并改善视频启动

2. 算法上：XLINK利用数据包重注入 来解耦多个路径

   • 特征：与 过去的重注入 [6] 不同，XLINK在两个级别实现了基于优先级的重注入:

     • 基于 传输 (QUIC流) 优先 级别
     • 基于 应用 (视频帧) 优先 级别 (第5.1节)

   • [6] : Costin Raiciu, Christoph Paasch, Sebastien Barre, Alan Ford, Michio Honda,
     Fabien Duchene, Olivier Bonaventure, and Mark Handley. How hard can it be?
     designing and implementing a deployable multipath {TCP}. In 9th {USENIX}
     Symposium on Networked Systems Design and Implementation ({NSDI} 12), pages
     399–412, 2012

     • 基于流优先级的重注入 ：
       • 考虑了QUIC请求视频不同部分的并发流
       • 它确保早期流的重注入数据包在后期流的数据包之前发送，从而防止流在传输时阻塞
     • 基于视频帧优先级的重注入：
       • 区分了流内视频帧的紧迫性
       • 它以最高优先级处理视频的第一帧，以加速视频启动

   • 在QoE反馈控制方面：

     • XLINK引入了双阈值控制(5.2.2)，实现了响应性和成本效率，并提供了平衡性能和成本的灵活性

3. 协议层上：

   • XLINK 建立在草案 [11] 中提出的多路径扩展的基础上，该扩展合并了PATH_STATUS和ACK_MP扩展帧来管理 路径状态并确认从不同路径接收的数据包。

   • [11] : Yanmei Liu, Yunfei Ma, Christian Huitema, Qing An, and Zhenyu Li. Multi-
     path Extension for QUIC. Internet-Draft draft-liu-multipath-quic-02, Internet
     Engineering Task Force, December 2020. Work in Progress.

   • 唯一的区别是 当前的XLINK实现(在本实验中使用)在 ACK_MP 帧中作为附加字段发送QoE反馈，而不是在草案中指定的独立的QOE_CONTROL_SIGNALS帧中发送QoE反馈

Ⅴ. QoE-Driven Scheduling AND Path Management

介绍：本节讨论 QoS驱动的多路径调度和路径管理的细节，这使 XLINK能够以最小的开销实现用户感知的优质qos

整体 由 三个主要部分组成:

• 基于流和视频帧优先级的数据包重注入
  • 克服了多路径HoL阻塞、流阻塞以及视频启动时的过度延迟
• QoE反馈控制：
  • 控制与再注入相关的冗余去 降低成本
• QoE感知路径管理
  • 处理异构网络中的路径延迟差异
  • 包括无线感知主路径选择和最快路径多路径ACK

1. Priority-based re-injection

   • Why re-injection?： 重注入用于解耦多个路径

     • 多路径HoL阻塞的根本原因： 是调度程序拆分数据包时多个路径的耦合，：
     • (a) 未注入，，（b) 重注入后
       <img src="./XLINK/image-20230918112726847.png" />
     • 快速路径和慢速路径 发送的数据包相互补充，Client 等待两条路径都成功发送以获得整个视频块
     • 重注入是一种技术，它允许我们通过使用冗余的重复数据包来解耦多条路径，如图3(b)所示
     • 重注入流程：
       1. 发送方跟踪未确认数据包的队列(unacked_q)。
       2. 当 pkt_send_q 中没有更多的数据包要发送时，发送方 可以将未确认的数据包6和7的副本重新注入到快速路径中，而无需等待慢路径上的丢失恢复，从而 允许接收方继续消费数据而不会受到阻塞效应的影响。

   • Priority-based re-injection.

     • 问题：上述重注入，不足实现视频传输的QoE
     • Quic 特征：与TCP协议不同，QUIC传输层有QUIC流的概念，一个连接可以携带多个流，每个流单独控制和丢失恢复
       • 在短视频传输中，视频播放器可以同时请求多个流，每个流下载视频的一小部分
     • 不同的重注模式：
       <img src="./XLINK/image-20230918134758263.png"/>
     • 传统的重注入：如上图(a)所示，以附加方式工作，pkt 4 在慢路径上丢失，调度器只能在流2后面pkt_send_q的末尾重新注入它，这不是最优的。
       • 由于流的内容按顺序播放，流2现在阻塞了流1的传输
       • 一个早期的流应该享有高优先级的重注入，这样 pkt 4 就会在流1之后被重注入
     • XLINK的重注入： 采用基于流优先级的重注入( 图(b) ) 来处理 并发QUIC流
       • 当发送方发出 流1 中的最后一个数据包时，它会立即检查unacked_q以查找具有相同流优先级的数据包
       • 如果有，它将这些数据包插入到低优先级流的未发送数据包之前，如图4(b)所示，从而防止流阻塞。 <此时的队列中 流2属于低优先级>

   • **First-video-frame acceleration **

     • 引入 基于视频帧的优先级重注入，加速第一视频帧的交付

       • 如果没有它，在存在较大路径延迟差异的情况下使用多路径可能会遭受视频帧阻塞效应导致的视频启动缓慢
       • 阻塞：
         <img src="./XLINK/image-20230918135611129.png" />
       • 如果条件良好路径的拥塞窗口已满，多路径调度程序可能会将第一视频帧数据包放在条件不良的路径上，( 例如图(c)中蓝色的pkt 3，放在了慢的路径)
       • 在这种情况下，基于流优先级的重注入提供的流级粒度是不够的，因为重注入的数据包仍然需要等待同一流中的其他视频帧被交付 (我想要的是在4后面，而不是在8后面)

     • XLINK 使用 基于视频帧的优先级 进行解决：

       • 在这种模式下，XLINK向应用程序提供 stream_send API，以更细的粒度表达视频 Qos 感知
         • 具体来说：为了加速第一视频帧，应用程序可以将包含第一视频帧的流数据设置为具有指示 视频帧相对位置的位置和大小参数的最高优先级
       • 启用时：XLINK 在发送最后一个第一帧数据包 (pkt 4) 后检查来自第一个视频帧 (pkt 3) 的未确认数据包
       • 如果有，调度程序在 同一流中其他视频帧的任何未发送的数据包之前重新注入它 (pkt 3)
       • 这次重注入的副本 可以走快速路径，可能会比原始数据包更早到达
       • 结果：基于视频帧优先级的重注入避免了慢路径的过度延迟，显著提高了视频启动速度

2. QoE feedback and re-injection control

• 上述引发的问题：数据包重注入的问题在于它引入了大量冗余数据包，案例中我们发现直接应用回注使**总流量增加了15%**， 成本开销问题，冗余还会影响总体吞吐量

• 解决方法：**XLINK **利用客户机的 QoE 反馈来控制 与数据包重注入相关的开销，同时确保用户感知的QoE

  背景：实际上，当 视频播放器 缓存视频块时，并不总是需要冗余数据包。

  如果**缓冲区占用级别高**，则到下一次可能的重新缓冲的剩余游戏时间很长，因此，使用重新注入的紧迫性较低；相反，如果**缓冲区占用水平较低**，则距离下一次可能的重新缓冲的时间很短，因此，使用重新注入的紧迫性很高。
  

• 知道客户机视频播放器的缓冲区占用率是用户感知的QoE的一个强有力的指示器。XLINK捕获缓冲区占用信息并将其发送回服务器以控制其重注入使用

• 其信号 在上述 中ACK_MP帧的QoE_Control_Signal字段中传递。

• QoE信号的定义可以很灵活。在我们的例子中，我们从客户端的视频播放器捕获四种类型的信号：

  • cached_bytes : 缓存的字节数
  • cached_frames : 缓存的帧数
  • bps : 比特率
  • fps : 帧速率

1. Capturing QoE signals.

   • XLINK 捕获 QoE反馈信号的流程：
     <img src="./XLINK/image-20230918144016477.png" />

   • MediaCacheService 响应来自媒体播放器的视频播放请求，并向服务器发送HTTP范围请求以获取视频块

   • TNET 是淘宝客户端使用的 Android 网络 SDK，用于向 XLINK 发送QoE信号

   • 传入的媒体数据首先由Meida Source 处理，其中音频和视频帧被分割并缓存在源管道中，源管道随后将帧发送到各自的解码器进行实际解码.

   • Source Pipe 跟踪 缓存帧的数量和缓存字节的数量

   • Decoder 了解帧率和解码率

   • 为了获得QoE信息，Source Pipe 和 Decoder 定期将这些更新的指标发送给 TNET

   • 当XLINK想要发送QoE反馈时，它会查询TNET

   • 然后 XLINK 将 QoE反馈信息封装到 ACK_MP帧中的 QoE控制信号字段 （QoE_Control_Signal） 中，

     • Double thresholding control :

   • 控制 重注入使用的算法需要满足三个属性: 响应性、成本效率 和 灵活性

     1. 在紧急需要回注时，必须有足够的反应能力。
     2. 准确防止不必要的再注射。
     3. 需要提供灵活性来调整性能和成本之间的平衡

   • 因此，引入 了双阈值控制 ，其算法如下：
     <img src="./XLINK/image-20230919145957260.png" />

   • 算法内容：

     1. 输入：如上所示的 四种QoE信号

     2. 输出：是否 启用重注入的决策

     3. step1: Computing play-time left

        • 首先用 QoE反馈 估计客户端缓冲区中剩余的视频播放时间Δ𝑡 , <如上算出>
        • < 当视频不是用恒定比特率编码并且帧率很高时，我们建议使用 **𝑐𝑎𝑐h𝑒𝑑_𝑓𝑟𝑎𝑚𝑒𝑠 / 𝑓𝑝𝑠**来计算Δ𝑡，因为𝑏𝑝𝑠可能会表现出很大的变化 ; 如果帧速率非常低,计算基于𝑐𝑎𝑐ℎ𝑒𝑑_𝑏𝑦𝑡𝑒𝑠和𝑏𝑝𝑠进行>

     4. step2 : Double thresholding

        • 我们将剩余的 播放时间Δ𝑡 与两个阈值 Tth1 和 Tth2 进行比较, 其中 Tth1 < Tth2
        • Tth1 用于 确保响应性：if **Δ𝑡 < Tth1** => 剩余播放时间太少。立即启动重注入
        • Tth2 用于成本效率 : if Δ𝑡 > Tth2 => 缓存足够多，关闭重注入以降低成本

     5. step3: Comparing with delivery time

        • 当 Δ𝑡 处于 [Tth1 , Tth2]] 范围内，冲区占用处于中等水平，因此飞行中数据包的投递时间在决策中起作用

        • 进一步将Δ𝑡与飞行中数据包的估计最大投递时间 deliverTimemax 进行比较：

          • < : 则其中一条路径可能太慢，因此应该打开重注入以使用另一条路径加速数据包的传递

          • : 飞行的报文准时到达，关闭回注

          • 其中 deliverTimemax : 包含未确认数据包的所有路径的𝑅𝑇𝑇加上它的方差𝛿 的最大值：
            

   • 为了说明该算法 如何在 快速变化的无线环境中 以更低的成本 克服 HoL 阻塞，绘制了客户端的缓冲区级别和重新注入数据包的数量与时间的动态关系：

     1. Network traces && vanillaMP：
        <img src="./XLINK/image-20230919153915630.png">
     2. re-injection without QoE control && re-injection with QoE control：
        <img src="./XLINK/image-20230919154051997.png">
     3. 从上图我们可以看出：
        • 随着 Path1 的恶化，缓冲级别多次降至零的 vanilla-MP 遭受了严重的多路径HoL阻塞，导致频繁的视频重新缓冲。
        • 重注入在克服多路径 HoL阻塞 方面是有效的，因此当 Path1 恶化时，**图c和图d **可以在其缓冲区中保持足够的缓存字节
        • 同时，带有QoE反馈的 Re-injection 只在缓冲级别较低时使用了回注，避免了缓冲级别较高时不必要的回注.

   • Performance and cost tradeoffs :

   • 两个阈值 Tth1 , Tth2 提供了在性能和成本之间进行权衡的灵活性

2. QoE-aware path management:

   • 本节描述 XLINK 的 Qos感知路径管理 如何处理异构网络中的路径延迟差异

   • **Wireless-aware primary path selection: **

     • XLINK 根据无线接口的类型仔细确定 初始化连接的主要路径

     • 过去的研究表明，由于路径延迟的差异，主路径选择会影响MPTCP的性能[43]

     • 随着5G SA的到来，路径延迟差异进一步扩大，因为：

       1. 不同于与 LTE 共用同一个核心网的 5G NSA , 5G SA采用了全新的、独立的核心网
       2. 5G SA本身支持边缘计算，并使内容交付服务进一步接近接入网的边缘

     • 为了适应即将到来的5G SA，我们使 XLINK 的主要路径选择具有无线感知能力：

       • 例如: 5G SA > 5G NSA > WiFi > LTE

     • 当从不同的无线接口开始多路径连接时，我们测量了第一帧传输时间与不同帧大小的关系：
       

     • 如上所示：主路径选择对第一视频帧传送时间的影响是显著的， 简单地从正确的主路径开始可以提供更快的视频启动

       4. Fastest-path Multi-path ACK ：

       • 最后，但重要的是，XLINK利用 最快路径多路径ACK

       • 与 MPTCP 不同的是，MPTCP 假定在同一子流(原始路径) 上返回ACK[4]

         • XLINK 允许从任何路径 返回ACK_MP，这提供了更大的灵活性

         • 有两种基本策略:

           1. ACK_MP 在最快路径 (min-RTT路径) 上
           2. ACK_MP 在原始路径上

         • 在XLINK中，我们使用最快的路径来传输ACK_MP

     • 下面展示了 两种具有三次拥塞控制的ACK路径选择策略的效果：
       <img src="./XLINK/image-20230919163800482.png">

     • 如上所示，测量 调整 两条路径之间的路径RTT比率来获得4MB的负载 的请求完成时间

       • 随着延迟比的增大，最快路径上的ACK_MP开始显示出优势
       • 原因是对于Cubic来说，更快的 ACK 返回有助于拥塞窗口增长更快，从而产生更好的吞吐量

Ⅵ. PROTOCOL AND IMPLEMENTATION

我们将在本节中**描述XLINK的协议和实现**,我们从 XLINK 如何将**QUIC扩展到多路径开始**，然后 将 **XLINK集成到android应用程序和视频服务**中.

1. XLINK 是基于我们的 多路径QUIC草案[11] 实现的，它以最小的修改将 IETF QUIC 扩展到多路径

   • [11] : Yanmei Liu, Yunfei Ma, Christian Huitema, Qing An, and Zhenyu Li. Multipath Extension for QUIC. Internet-Draft draft-liu-multipath-quic-02, Internet Engineering Task Force, December 2020. Work in Progress.

   • 与过去的提案 [7] 严重依赖于“单流”概念不同，我们在双向路径概念的基础上扩展了多路径，这很容易适应蜂窝和wifi链路的性质，这些链路覆盖了QUIC中的大多数多路径应用，同时保持设计简单易于实现.
   • 通过这样做，我们能够重复使用大多数当前QUIC传输设计，唯一增加了三个新框架。
     更重要的是，我们的设计支持QoE反馈，这是启用 XLINK 基于反馈的动态调度所必需的

2. Key design points :

   1. 不同的路径由CID (connection id) 序列号来标识。为了方便丢包检测和恢复，我们对每条路径使用单独的包数空间
   2. 我们保持 QUIC 包头格式不变，以避免包被中间盒阻塞的风险。
   3. 属于一个连接的所有路径共享相同的加密密钥，但我们合并了一种机制，使每个路径在 AEAD 中获得唯一的nonce。
      • 我们结合了**PATH_STATUS 和 ACK_MP扩展帧 **来支持 多路径功能和QoE反馈机制。

3. Multi-path initialization：

   • 多路径路径初始化过程如下所示：
     
   • XLINK 首先以与 单路径QUIC相同的方式 初始化主路径, 不同之处是在第一次握手期间，客户端包含一个𝑒𝑛𝑎𝑏𝑙𝑒_𝑚𝑢𝑙𝑡𝑝𝑎𝑡传输参数
     • 如果服务器回复一个𝑒𝑛𝑎𝑏𝑙𝑒_𝑚𝑢𝑙𝑡𝑝𝑎𝑡参数，那么两个终端主机都知道支持多路径
     • 否则，它们会退回到单路径QUIC。
   • 在初始化新路径之前，客户端需要提供至少一个未使用的可用CID (ex: C1, Seq=1)
   • 后续，服务器需要提供至少一个未使用的可用CID。为了建立一个新路径，客户端选择一个可用的连接ID S2作为新路径中的目标连接ID。
   • CID 的交换是通过 QUIC [34] 中定义的 New_connection_ID 针完成的。
   • 为了避免路径欺骗攻击，XLINK 使用 PATH_CHALLENGE 和 PATH_RESPONSE 针
   • 一旦多路径初始化，XLINK 使用 ACK_MP帧而不是ACK帧来发送确认

4. Frame extension：

   • 我们使用 PATH_STATUS帧 和 ACK_MP帧 来支持多路径功能和QoE反馈
     • PATH_STATUS帧：帮助管理多路径，它通知对等体一条路径的当前状态，对等体应该根据这些帧中表示的优先级发送报文
       • 取值：Abandon(0)、Standby(1)、Available(2)
     • 端点使用 对等端 使用的CID序列号 作为PATH_STATUS帧(描述发送方的路径标识符)

后续论文内容非论文设计核心内容，读者可通过论文查看

• Post author: Tao Tang
• Post link: https://taotangseek.github.io/2023/10/15/XLINK/
• Copyright Notice: All articles in this blog are licensed under unless otherwise stated.