XLINK (SIGCOMM ‘21) MPQUIC多路徑傳輸論文閱讀筆記

這篇具有很好參考價值的文章主要介紹了XLINK (SIGCOMM ‘21) MPQUIC多路徑傳輸論文閱讀筆記。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方，請大家不吝賜教，您也可以點擊"舉報違法"按鈕提交疑問。

總結(jié)

論文及視頻：XLINK: QoE-driven multi-path QUIC transport in large-scale video services

XLINK設(shè)計思想：

結(jié)合MPQUIC與短視頻應(yīng)用——傳輸層應(yīng)用層協(xié)同
通過重注入來解決HoL阻塞以最大化QoE，同時最小化重注入成本

XLINK的核心貢獻：

MPQUIC+短視頻大規(guī)模部署經(jīng)驗
基于播放器buffer的重注入調(diào)節(jié)策略
平衡QoE性能與重注入流量成本

XLINK核心設(shè)計：基于播放器buffer水平的重注入

方法：雙閾值控制
- buffer < 閾值1：啟用重注入
- buffer > 閾值2：停止重注入
- 閾值1 ≤ buffer ≤ 閾值2：
  - buffer < 預(yù)期剩余傳輸時間：啟用重注入
  - buffer > 預(yù)期剩余傳輸時間：停止重注入
- *其實就是buffer < 閾值2時才可能啟用重注入，而buffer < 閾值1時必定啟用重注入
選擇：重注入 vs. 數(shù)據(jù)包調(diào)度
- 數(shù)據(jù)包調(diào)度：基于對網(wǎng)絡(luò)環(huán)境的預(yù)測，可能不準(zhǔn)確
- 重注入：放棄預(yù)測，對性能下降進行快速反應(yīng)

XLINK特殊設(shè)計：

基于QUIC stream優(yōu)先級的重注入
基于視頻幀優(yōu)先級的重注入
無線感知主路徑選擇
快路徑ACK

其他設(shè)計：

數(shù)據(jù)包調(diào)度：沿用MinRTT
擁塞控制：解耦合
路徑管理（增/刪/改/查）：無特殊設(shè)計
能耗：無特殊設(shè)計（單bit耗能與單路徑差不多）
蜂窩數(shù)據(jù)流量：無特殊設(shè)計（只針對免流用戶）
網(wǎng)絡(luò)編碼：無

*注：

關(guān)于多路徑數(shù)據(jù)包調(diào)度相關(guān)介紹，可參閱：多路徑傳輸（MPTCP&MPQUIC）數(shù)據(jù)包調(diào)度研究總結(jié)
文中“【】”中的內(nèi)容為個人想法，僅供參考。

Abstract

XLINK的兩個設(shè)計目標(biāo)：

最大化QoE
最小化服務(wù)提供商（CDN）的成本開銷

XLINK的兩個基礎(chǔ)：

用戶態(tài)協(xié)議QUIC
感知QoE

挑戰(zhàn)：

多路徑head-of-line（HoL）阻塞
網(wǎng)絡(luò)異構(gòu)性
鏈路的快速變化
平衡成本和性能

實驗：

環(huán)境：3百萬短視頻，安卓APP
結(jié)果：相對于單路徑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.

“網(wǎng)紅經(jīng)濟“的興起

Target China. WHAT IS “INTERNET CELEBRITY ECONOMY” IN CHINA. https://targetchina.com.au/article/internet-celebrity, 2020.

兩個觀察

短視頻的卡頓和啟動時延嚴(yán)重影響用戶滿意度
消費者渴望看到更好的細(xì)節(jié)和更有參與感的需求，推動了短視頻朝著更高碼率的方向發(fā)展

問題：is it practical and worthwhile to bring multi-path QUIC to large-scale video services?

1.2 挑戰(zhàn)

直接將多路徑應(yīng)用于大規(guī)模視頻

挑戰(zhàn)：實測多路徑的性能不如單路徑
原因：MP-HoL阻塞問題——慢路徑的包先發(fā)晚到，亂序到達的數(shù)據(jù)包無法向應(yīng)用層提交，導(dǎo)致快路徑的包需要等待

MP-HoL的傳統(tǒng)解決方案：

更復(fù)雜的包調(diào)度算法：依賴于準(zhǔn)確的吞吐量預(yù)測
發(fā)送冗余包：帶來嚴(yán)重的冗余流量，視頻傳輸無法承受

因此，現(xiàn)有MP技術(shù)主要用于音頻場景（Apple Siri和Apple Music）

1.3 XLINK介紹

思想&方法

Key idea：

用戶空間協(xié)議QUIC
直接通過視頻QoE來控制多路徑調(diào)度和管理

設(shè)計機制：

基于客戶端的QoE反饋，在服務(wù)器的調(diào)度器中動態(tài)控制數(shù)據(jù)包的重注入（re-injection）行為
- 思路：基于客戶端播放器的buffer水平來控制重注入的數(shù)據(jù)量，以提升多路徑傳輸性能同時降低冗余流量成本
- 因為無線鏈路的不可預(yù)測性，不追求準(zhǔn)確的網(wǎng)絡(luò)特征預(yù)測
為多路并行QUIC流設(shè)計，使用基于流優(yōu)先級的重注入，根據(jù)流的緊急性確定發(fā)送順序
- 思路：優(yōu)先傳輸高優(yōu)先級Stream的重注入數(shù)據(jù)包，確保QUIC Stream按照其先后順序（優(yōu)先級順序）完成傳輸
為短視頻做優(yōu)化，使用基于視頻幀優(yōu)先級的重注入實現(xiàn)了首幀加速（比流更細(xì)粒度的調(diào)度）
- 思路：優(yōu)先傳輸首幀的重注入數(shù)據(jù)包，確保首幀傳輸不被后續(xù)幀阻塞
基于QoE感知的路徑管理，解決流異構(gòu)網(wǎng)絡(luò)下路徑時延差距大的問題
- 主路徑選擇：基于無線感知的主路徑（啟動會話的路徑）選擇
- ACK_MP路徑選擇：多路徑ACK不局限于同一個子流，可以靈活選擇其返回路徑，這不同于MPTCP

優(yōu)勢&提升

核心指標(biāo)

性能
- 視頻啟動延遲
- 視頻卡頓率
- 移動性支持
- CDN流量開銷
安全性

貢獻：

展現(xiàn)了生產(chǎn)環(huán)境中多路徑QUIC視頻傳輸?shù)拇笠?guī)模實驗結(jié)果
提出了解決挑戰(zhàn)的關(guān)鍵：利用QUCI作為用戶空間協(xié)議的特性，并使用QoE進行調(diào)度及路徑管理
揭示了之前的文獻較少提及的實際挑戰(zhàn)（性能、成本、移動性、兼容性、網(wǎng)絡(luò)異構(gòu)性），并分享了解決這些挑戰(zhàn)的經(jīng)驗

主要結(jié)果：

數(shù)據(jù)量：100K參與者，3百萬視頻播放
對比：單路徑QUIC
效果（同摘要）：
- 視頻塊請求完成時間
- 首幀延遲
- 卡頓率

XLINK總結(jié)：

主要創(chuàng)新：利用遠(yuǎn)端反饋來控制重注入
利用QUIC的能力：基于流優(yōu)先級和幀優(yōu)先級的調(diào)度
感知應(yīng)用的傳輸層優(yōu)化：可以擴展至短視頻以外的其他應(yīng)用，如360°視頻、AR、VR等

2 Motivation

2.1 短視頻

短視頻應(yīng)用：：TikTok、Reels、Twitter
電子商務(wù)公司：阿里、亞馬遜、Ebay、Redfin

現(xiàn)狀：

短視頻爆發(fā)
電子商務(wù)引入短視頻來展示商品
短視頻對QoE的要求更高：相對于長視頻，觀眾對短視頻的QoE下降的容忍度更低[27]

2.2 QUIC

QUIC是Google提出的用于替換TCP的協(xié)議，現(xiàn)已占據(jù)Google流量的40%+和Facebook流量的75%+
QUIC相對于TCP的優(yōu)勢：

更快
更安全
協(xié)議變更靈活

QUIC的用戶態(tài)特性，便于其實際MPTCP在克服部署中的問題，如：

不理想的性能
負(fù)載均衡器（LB）的支持
OS支持
中間件的支持

2.3 移動性支持

現(xiàn)狀：

無線網(wǎng)絡(luò)下，對于移動性的支持至關(guān)重要
從Wi-Fi切換至蜂窩數(shù)據(jù)要么太慢，要么容易失效
QUIC具有連接遷移（CM）策略
- 缺陷：遷移后需重置連接的窗口，對于具有高帶寬需求的視頻流而言可能并不合適

2.4 5G下的多路徑

現(xiàn)狀：

盡管5G提供了更高的帶寬，但與LTE相比，由于更多的傳播損耗（propagation loss）和更弱的滲透能力（weaker penetration）導(dǎo)致5G信號覆蓋范圍更小，這為5G滿足傳輸可靠性和QoS保證帶來了新的挑戰(zhàn)
Wi-Fi6可能仍將是最高效的室內(nèi)通信方法

趨勢：同時利用5G和Wi-Fi

3 Experience with Vanilla Multi-path QUIC

Vanilla-MP：MPQUIC（CoNEXT’17）

數(shù)據(jù)包調(diào)度：MinRTT

多路徑性能的兩個挑戰(zhàn)：

移動性（導(dǎo)致路徑性能快速變化）
路徑時延差異：不同無線技術(shù)的路徑時延差異很大，此外還受跨ISP的時延影響
- 數(shù)據(jù)：LTE的時延是Wi-Fi的2.7倍，是5G SA的5.5倍

3.1 Vanilla-MP in 仿真環(huán)境

環(huán)境：Mahimahi
觀察：Vanilla-MP無法快速應(yīng)對網(wǎng)絡(luò)突變

在Wi-Fi帶寬突降時（1.7s），其Inflight依然在增長

3.3 Vanilla-MP in 真實環(huán)境

數(shù)據(jù)采集：一周
對比：Vanilla-MP vs. SP（單路徑）
觀察：

Vanilla-MP只能偶爾在RCT（請求完成時間）的中位數(shù)和90%分位數(shù)上有所提升，有時甚至?xí)?dǎo)致更差的性能（中位數(shù)最多16%）
Vanilla-MP總在RCT的99%分位數(shù)上（長尾部分）導(dǎo)致性能下降（最多28%）
Vanilla-MP會引起視頻卡頓率的增長（34%～96%）
- 卡頓率：總卡頓時間/視頻總播放時間

結(jié)論：直接應(yīng)用于短視頻時，Vanilla-MP相對于單路徑不一定能取得性能提升

4 XLINK Design Overview

目標(biāo)：用最少的開銷取得最優(yōu)的QoE（低時延，少卡頓）
思想：跨層網(wǎng)絡(luò)設(shè)計，與視頻應(yīng)用緊密結(jié)合

核心：

利用QUIC的用戶態(tài)特性
利用客戶端的QoE反饋：為QUIC的ACK_MP添加QoE_control_signal字段

MPQUIC草案：MPQUIC（CoNEXT’17）

PATH_STATUS擴展幀
ACK_MP擴展幀

XLINK與草案的區(qū)別：為ACK_MP幀引入額外的字段，而非使用額外的幀

5 QoE-Driven Scheduling and Path Management

三個組成部分：

基于優(yōu)先級的重注入
基于QoE反饋的重注入
感知QoE的路徑管理

5.1 基于優(yōu)先級的重注入

在傳輸層與應(yīng)用層同時實現(xiàn)

重注入的作用

MP-HoL阻塞的根源：調(diào)度器在多個路徑分配數(shù)據(jù)包，使多路徑產(chǎn)生耦合

圖a示例：快路徑完成傳輸，慢路徑尾部丟包，則需要等待RTO才能進行重傳

重注入：通過另一個路徑重傳Inflight數(shù)據(jù)包，將多路徑解耦合，以緩解MP-HoL阻塞

時機：待發(fā)送隊列（pkt_send_q）中無數(shù)據(jù)包
圖b示例：通過快路徑重傳Inflight數(shù)據(jù)包，不需要等待RTO觸發(fā)丟包恢復(fù)，可以提前完成傳輸

【關(guān)于路徑耦合我的理解：
指一條路徑的傳輸行為受到另一條路徑的影響，無法充分利用帶寬。那么所謂解耦合，就是指不管其他路徑的環(huán)境如何，所有路徑在傳輸數(shù)據(jù)的全部時間內(nèi)，都可以打滿帶寬進行發(fā)送。
MinRTT之所以會耦合，是因為慢路徑在傳輸最后一個RTT的數(shù)據(jù)時，快路徑很可能被空閑，導(dǎo)致無法更快地完成傳輸。而重注入通過利用快路徑發(fā)送冗余數(shù)據(jù)包，使得在最后一個慢路徑RTT內(nèi)，快路徑仍然以滿帶寬傳輸，直至所有數(shù)據(jù)傳輸完成。通過重注入，可以將傳輸尾部的完成時間從慢路徑RTT縮短至快路徑RTT。】

QUIC優(yōu)化：基于流優(yōu)先級的重注入

QUIC特性：Multi Stream
思想：按照Stream的先后順序進行優(yōu)先級排序，確保高優(yōu)先級的Stream優(yōu)先完成傳輸
實現(xiàn)：發(fā)送某Stream的最后一個數(shù)據(jù)包后，檢查未ACK隊列（unacked_q）中是否存在同優(yōu)先級的數(shù)據(jù)包，若有，則將其插入至低優(yōu)先級流未發(fā)送的數(shù)據(jù)包前，優(yōu)先發(fā)送

首幀加速：基于視頻幀優(yōu)先級的重注入

挑戰(zhàn)：對于視頻幀而言，其傳輸單元相對較小，幀的傳輸很容易被慢路徑阻塞（圖中的pkt3）——需要重注入
問題：基于流級別的重注入粒度太粗（一個流包含多個幀），無法解決視頻幀阻塞的問題
思想：識別視頻幀的數(shù)據(jù)，優(yōu)先完成首幀數(shù)據(jù)包的傳輸
實現(xiàn)：stream_send API

將包含視頻首幀的流設(shè)為最高優(yōu)先級
通過設(shè)置首幀的位置與大小參數(shù)，指示首幀在流中的相對位置
發(fā)送首幀的最后一個數(shù)據(jù)包后，檢查未ACK隊列（unacked_q）中是否存在首幀的數(shù)據(jù)包，若有，則在發(fā)送下一幀數(shù)據(jù)包前優(yōu)先注入對應(yīng)數(shù)據(jù)包

5.2 基于QoE反饋的重注入控制

重注入的問題：冗余流量成本（直接使用會引入15%的冗余流量）

開銷：$0.085/GB

解決思路：利用客戶端的QoE反饋，控制重注入的數(shù)據(jù)量

播放器有buffer，不需要在任何時候都重注入

QoE反饋：XLINK感知播放器buffer水平

實現(xiàn)：ACK_MP幀的QoE_Control_Signal字段
信號：
- 緩存字節(jié)數(shù)量（???????????_??????????）
- 緩存幀數(shù)量（???????????_????????????）
- 碼率（??????）
- 幀率 (??????)

QoE信號采集

播放器結(jié)構(gòu)：

video pipeline
- Media Source：分割音視頻幀，存儲至Source Pipe
- Source Pipe：將分割后的音視頻幀發(fā)送至其對應(yīng)的Decoder；記錄緩存幀的數(shù)量及字節(jié)數(shù)（buffer）
- Decoder：解碼，有音視頻碼率和幀率信息
- Decoder Pipe
- Renderer
MediaCacheService：視頻塊HTTP請求
TNET：Android網(wǎng)絡(luò)SDK，將QoE信號傳遞給XLINK

QoE反饋采集流程：

Source Pipe和Decoder將QoE信號周期性發(fā)送至TNET
當(dāng)XLINK需要發(fā)送QoE反饋時，向TNET查詢
若QoE信息已更新，TNET響應(yīng)XLINK的查詢
XLINK將QoE信息封裝在ACK_MP幀的QoE_Control_Signal字段中

雙閾值控制

重注入控制算法的三個設(shè)計目標(biāo)：

responsiveness：在急需重注入時快速響應(yīng)
cost-efficiency：準(zhǔn)確避免任何不必要的重注入
flexibility：平衡性能與成本

XLINK的重注入控制算法：雙閾值控制

輸入：四種QoE信號（->播放器buffer水平）
輸出：是否啟用重注入
步驟：
- 計算剩余播放時間Δ??（buffer水平）
  - 緩存幀數(shù)量 / 幀率：VBR編碼時
  - 緩存數(shù)據(jù)量 / 碼率：幀率較低時
  - *相關(guān)信息更新頻率低時，需要估算剩余播放時間
- buffer vs. 雙閾值（?????1 < ?????2）
  - ?????1（responsiveness）：若buffer小于該值，則立即啟用重注入
  - ?????2（cost-efficiency）：若buffer超過該值，則停止重注入
  - ?????1 & ?????2（flexibility）
- buffer vs. 剩余傳輸時間（????????????????????????????）
  - 當(dāng)buffer處于[?????1, ?????2]之間時，判斷Δ?? < ????????????????????????????，成立時啟用重注入，否則停用
  - ????????????????????????????：所有包含Inflight的路徑的{RTT + 對應(yīng)路徑RTT標(biāo)準(zhǔn)差}的最大值

示例：

b：MinRTT（無重注入）——嚴(yán)重卡頓
c：MinRTT+重注入（不限量）——引入過多的冗余流量
d：XLINK——以最少的流量開銷保證播放的流暢性

*注：視頻流在start-up階段重注入的數(shù)據(jù)量較多，但當(dāng)buffer穩(wěn)定以后，重注入較少

性能&成本

?????1：流量開銷下限???????? ≥ ?? ? ????????(Δ?? < ?????1)
?????2：流量開銷上限???????? ≤ ?? ? ????????(Δ?? < ?????2),
??：重注入成本開銷，約15%

5.3 感知QoE的路徑管理

主路徑選擇

過去研究表明，由于路徑時延差異的存在，主路徑選擇會影響MPTCP性能

Wifi, lte,or both? measuring multi-homed wireless internet performance - IMC’14

5G SA增大了路徑時延差

獨立核心網(wǎng)絡(luò)
原生支持邊緣計算，使得內(nèi)容傳輸更靠近接入網(wǎng)邊緣

XLINK的無線感知主路徑選擇：5G SA > 5G NSA > WiFi > LTE

主路徑選擇影響首幀時間

ACK_MP路徑選擇

MPTCP：ACK從其原始路徑返回
XLINK：ACK從最快路徑返回

對于CUBIC類擁塞控制而言，ACK的快速返回有助于快路徑快速增窗

6 Protocol and Implementation

XLINK基于所提出的MPQUIC草案實現(xiàn)：https://datatracker.ietf.org/doc/html/draft-liu-multipath-quic-02
與之前草案的區(qū)別：

充分利用現(xiàn)有QUIC的傳輸層設(shè)計，僅僅引入了三個額外的幀類型
支持QoE反饋

設(shè)計要點：

不同路徑通過連接ID（CID）來標(biāo)識，每條路徑使用單獨的數(shù)據(jù)包序號（for丟包監(jiān)測和恢復(fù)）
保持QUIC協(xié)議頭部格式不變，避免被中間件禁用
一個連接的所有路徑共享相同密鑰，每個路徑可以在AEAD中獲取一個單獨的nonce
引入PATH_STATUS和ACK_MP擴展幀，以支持多路徑功能和QoE反饋機制

多路徑初始化

QUIC標(biāo)準(zhǔn)草案[34]：https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-33

實現(xiàn)：

初始化主路徑：同單路徑QUIC，差異在于，在第一次握手時，客戶端發(fā)送????????????_?????????????????，若服務(wù)器返回????????????_?????????????????，則雙端啟用多路徑，否則回退到單路徑
初始化新路徑：
- 初始化前：客戶端與服務(wù)器各自需要至少提供一個未使用的CID（如上圖中的C1和S2）
  - 客戶端先檢查雙端是否有可用CID，并選擇一個可用的CID（如S2）作為新路徑的目標(biāo)CID
- 初始化中：客戶端選擇S2作為新路徑的目標(biāo)CID（DCID），完成新路徑設(shè)置
  - 通過QUIC的??????_????????????????????_????幀交換CID
  - 為避免路徑欺騙攻擊，XLINK使用????????_??????????????????和????????_????????????????幀
- 初始化后：使用ACK_MP幀替代普通的ACK幀

幀擴展

三個擴展幀：

PATH_STATUS：多路徑管理。將路徑的當(dāng)前狀態(tài)通知給對端，對端應(yīng)根據(jù)可用信息發(fā)送數(shù)據(jù)包
- CID：使用對端CID的序列號，描述發(fā)送方的路徑ID
- 可用值：Abandon(0)、Standby(1) 和 Available(2)
ACK_MP：通過引入Path Index字段（CID序列號），進行丟包檢測與恢復(fù)
- XLINK引入??????_??????????????_????????????字段來反饋QoE
QOE_CONTROL_SIGNAL：QoE反饋。可以獨立發(fā)送，不受ACK頻率限制

路徑關(guān)閉

服務(wù)器與客戶端通過發(fā)送PATH_STATUS幀來關(guān)閉Path Identifier對應(yīng)的路徑

當(dāng)路徑被標(biāo)記為Abandon(0)時，可以釋放與該路徑相關(guān)的資源

通過檢測網(wǎng)絡(luò)環(huán)境變化，客戶端和服務(wù)器可以立即關(guān)閉路徑

例如：客戶端關(guān)閉4G/Wi-Fi；Wi-Fi信號衰減至閾值；RTT或丟包率變差

路徑保護（安全性）

QUIC安全性的一般原則不變：設(shè)置數(shù)據(jù)包保護密鑰、初始化加密、頭部保護、0-RTT密鑰等

對于1-RTT數(shù)據(jù)包使用的multiple number spaces，需要改變AEAD的使用
【這部分看不懂，暫略】

負(fù)載均衡支持

負(fù)載均衡器（LB）需實現(xiàn)QUIC-LB草案[44]中指定的路由算法
對于LB中的CID使用相同的hash，以確保將多路徑數(shù)據(jù)包路由到相同的真實服務(wù)器

真實服務(wù)器需要在發(fā)給客戶端的CID中編碼其服務(wù)器ID

Android APP客戶端集成

XLINK客戶端基于XQUIC（IETF QUIC的C語言實現(xiàn)），并集成至手淘Android客戶端APP，測試包可以每周發(fā)布

CDN服務(wù)器部署

XLINK服務(wù)器同樣基于XQUIC，部署于CDN服務(wù)器
對程序的進程ICD使用相同的hash，以確保將多路徑數(shù)據(jù)包傳遞給保存QUIC連接上下文的進程

在CID的保留字節(jié)中編碼進程ID

XLINK通過配置項添加其算法參數(shù)，可在幾小時內(nèi)更新

7 Evaluation

實驗環(huán)境：

真實上線
- 雙閾值參數(shù)選擇
- XLINK vs. 單路徑
可控實驗
- XLINK vs. 其他多路徑機制
- 能耗

7.1 雙閾值控制參數(shù)選擇

根據(jù)buffer水平的分布來確定雙閾值控制參數(shù)

在start-up階段結(jié)束后，開始統(tǒng)計buffer水平
圖表示在不同參數(shù)設(shè)置下，相對于單路徑的buffer水平提升
- 參數(shù)（橫坐標(biāo)）：X-Y表明兩個閾值的buffer水平分位數(shù)，如95-80即95%的buffer水平超過閾值1，80%的buffer水平超過閾值2

觀察：

對于性能而言，重注入是必要的。若不啟用重注入，buffer水平相對于單路徑會有嚴(yán)重下降
對于成本而言，雙閾值控制是必要的。若不控制重注入的數(shù)據(jù)量（1-1），流量開銷會達到15%
開銷下界??*(1???)，上界??*(1???)，其中??=15%
- 【可見X越小，即閾值1對應(yīng)的buffer水平越高，開銷下界越大；對應(yīng)地，Y越小，開銷上界越高。因此圖中從左到右的開銷是遞增的】
相對保守的閾值（如95-80）即可取得不錯的性能，更為激進的重注入策略會導(dǎo)致邊際效益遞減
與預(yù)期傳輸時間進一步對比，有助于在開銷上界較高時有效控制成本，比如90-80與90-60的對比

相對單路徑，XLINK降低了buffer<50ms的比例（此時很可能引發(fā)卡頓）

最終參數(shù)：95-80，產(chǎn)生2.1%的冗余數(shù)據(jù)開銷

7.2 大規(guī)模A/B測試

傳輸指標(biāo)：請求完成時間

連續(xù)兩周的線上測試表明，對于中位數(shù)、尾部請求完成時間（RCT），XLINK可以穩(wěn)定優(yōu)于單路徑，因為它有效地解決了MP-HoL問題

中位數(shù) / 95%分位數(shù) / 99%分位數(shù)分別提升：2.3%～8.9 / 9.4%～34% / 19%～50%

QoE指標(biāo)1：卡頓率

卡頓率下降：23.8%～67.6%

卡頓率：sum(rebuffer time)/sum(play time)，即總卡頓時間/視頻總播放時間

QoE指標(biāo)2：首幀時延

觀察：

無首幀加速時，XLINK性能不如單路徑（14%的99分位下降），這是由慢路徑的巨大時延引起的
首幀加速將視頻啟動時延限界至快路徑性能內(nèi)（32%的99分位提升）
- 長尾部分的提升更明顯，因為長尾部分的路徑時延差很大

7.3 極限移動性

環(huán)境：Mahimahi仿真+真實網(wǎng)絡(luò)采集的Trace
對比對象：

SP（單路徑）
Vanilla-MP
MPTCP
QUIC CM（connection migration，連接遷移）

實驗觀察（RCT的中位數(shù)與最大值）：

SP表現(xiàn)最差，因為不支持移動性
CM相對單路徑表現(xiàn)更優(yōu)，但在極端場景下，遷移到的新路徑同樣可能面臨性能問題，此時CM不一定有效，甚至可能性能更差；此外，路徑的CWND在連接遷移后會被重置，需要幾個RTT重新探測帶寬，對于快速的網(wǎng)絡(luò)環(huán)境變化（如hand-off）反應(yīng)遲緩
MPTCP和Vanilla-MP表現(xiàn)相對較好，不過因為MP-HoL阻塞問題，在某些情況下也有性能下降

7.4 能耗

實驗環(huán)境：3個安卓5G手機下載不同大小（10MB～50MB）的文件
記錄信息：時間戳，瞬時電流，電壓，WiFi RSSI，cellular RSSI
控制變量：清后臺，開關(guān)飛行模式，保持屏幕亮度相同

結(jié)論：使用多路徑會提升瞬時能耗（power），但不一定會提升每bit能耗（energy）

energy = power × 時間，使用多路徑的傳輸時間會變短

觀察：

吞吐量：Wi-Fi+LTE、Wi-Fi+NR均比多路徑有提升
energy per bit：
- 引入Wi-Fi作為多路徑后降低了單獨使用蜂窩數(shù)據(jù)網(wǎng)絡(luò)（4G LTE、5G NR）的能耗
- 單路徑Wi-Fi的能耗最低，但吞吐量也遠(yuǎn)低于XLINK
- XLINK更適用于對高帶寬和時延有需求的應(yīng)用（如視頻）

8 Related Work

MPQUIC

QUIC的多路徑擴展方案：

MPQUIC草案
MPQUIC - CoNEXT’17
MPQUIC - ICC’18
PQUIC - SIGCOMM’19

現(xiàn)有方案的缺陷：對于可部署性和收益的問題缺乏大規(guī)模實驗研究（ https://mailarchive.ietf.org/arch/browse/quic/）

XLINK驗證了MPQUIC在商業(yè)大規(guī)模短視頻服務(wù)中作為端到端服務(wù)的可行性、可部署性和優(yōu)勢

MPTCP

MPTCP在2013年實現(xiàn)標(biāo)準(zhǔn)化，卻極少在移動操作系統(tǒng)中應(yīng)用，原因：

部署困難
MP-HoL阻塞等引發(fā)的性能問題
成本

大規(guī)模實驗室可控環(huán)境實驗表明，MPTCP對于單路徑的性能提升受到許多因素影響，如下載數(shù)據(jù)量、路徑時延差等

本文認(rèn)為不同路徑對于多路徑能力的需求有所不同，因此多路徑需要與應(yīng)用協(xié)同

多路徑數(shù)據(jù)包調(diào)度

MPTCP默認(rèn)：MinRTT + opportunistic retransmission and penalization

懲罰機制會影響聚合帶寬

基于網(wǎng)絡(luò)預(yù)測的方法（解決懲罰影響性能的問題）：ECF、BLEST、Musher

移動場景下很難得到準(zhǔn)確的預(yù)測

亂序發(fā)送按序到達類方法：STMS、DEMS

低時延MPTCP：RAVEN

通過大量冗余數(shù)據(jù)降低時延，沒有應(yīng)用于視頻服務(wù)

XLINK：以視頻應(yīng)用為中心，考慮可擴展性和部署性，通過QoE反饋的重注入來解決HoL擁塞問題，平衡性能與成本

跨層視頻優(yōu)化

跨層視頻QoE提升技術(shù)（單路徑）：

DASH：BBA、MPC、Pensieve
RTC：Salsify、Concerto

多路徑方案：

MP-DASH：MPTCP+DASH
- MPTCP在內(nèi)核中，不易與應(yīng)用結(jié)合
- 使用粗粒度的決策來決定是否啟用子流
Cross-layer scheduler（MMSys’16）：
- 粗粒度
- 只是對MPTCP的視頻數(shù)據(jù)包進行優(yōu)先級排序

XLINK：

用QoE反饋控制多路徑策略
細(xì)粒度（幾百ms）框架

9 Discussion and Limitations

蜂窩數(shù)據(jù)流量成本

解決方案：

手淘APP免流策略
手淘APP中附加XLINK開關(guān)

擁塞控制公平性

XLINK采用解耦合擁塞控制，與MP-DASH一致
原因：現(xiàn)有Wi-Fi和蜂窩數(shù)據(jù)網(wǎng)絡(luò)（甚至是5G NSA）不太可能共享瓶頸鏈路（last mile）
limitation：隨著5G SA的部署，瓶頸鏈路很可能從last mile轉(zhuǎn)移，這種情況下應(yīng)選擇耦合擁塞控制策略文章來源地址http://www.zghlxwxcb.cn/news/detail-498622.html

到了這里，關(guān)于XLINK (SIGCOMM ‘21) MPQUIC多路徑傳輸論文閱讀筆記的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！