網(wǎng)絡(luò)傳輸公平性測(cè)量與算法設(shè)計(jì)：視頻應(yīng)用案例

王子逸 胡曉宇 王 歆 張行功 曹 振 鄭 凱 崔 勇

1 （清華大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)系 北京 100084）

2 （紐約州立大學(xué)石溪分校電氣與計(jì)算機(jī)工程系 紐約 NY11794）

3 （北京大學(xué)王選計(jì)算機(jī)研究所 北京 100080）

4 （華為技術(shù)有限公司計(jì)算機(jī)網(wǎng)絡(luò)與協(xié)議實(shí)驗(yàn)室 北京 100085）

（wangziyi0821@gmail.com）

算網(wǎng)融合是計(jì)算和網(wǎng)絡(luò)兩大學(xué)科深度融合形成的新型技術(shù)簇，是實(shí)現(xiàn)算網(wǎng)資源，即取即用愿景的重要途徑. 面向算網(wǎng)資源共享的公平性原則是支持實(shí)際應(yīng)用正常運(yùn)行的關(guān)鍵因素之一，對(duì)于保證互聯(lián)網(wǎng)的順利運(yùn)行至關(guān)重要[1-3]. 當(dāng)網(wǎng)絡(luò)資源與應(yīng)用需求發(fā)生沖突時(shí)，應(yīng)該有一種方法來確保每個(gè)流都能得到合理公平的份額. TCP 的擁塞控制框架遵循加性增加/乘性減少原則（AIMD），具有內(nèi)置的公平性設(shè)計(jì).因此，新提出的擁塞控制算法在被廣泛部署之前必須針對(duì)其TCP 友好特性進(jìn)行實(shí)驗(yàn)評(píng)估.

然而，隨著視頻應(yīng)用的激增，公平性問題再次出現(xiàn). 首先，根據(jù)思科VNI 報(bào)告[4]，視頻流量占所有互聯(lián)網(wǎng)流量的82%，并且其占比還在不斷增加. 因此視頻應(yīng)用的公平性從根本上影響著整個(gè)互聯(lián)網(wǎng)的公平性，了解視頻流量是否遵循公平原則變得非常重要. 其次，為了獲得更好的性能并提高用戶滿意度，內(nèi)容提供商調(diào)整了他們的網(wǎng)絡(luò)協(xié)議棧[5]，例如，通過自定義TCP AIMD 中的常量來更快地加速發(fā)送或更慢地降速發(fā)送. 對(duì)于在UDP 上運(yùn)行的實(shí)時(shí)交互類應(yīng)用，開發(fā)人員能夠直接在用戶態(tài)中隨意控制發(fā)送速率，而不依賴于底層系統(tǒng)（例如操作系統(tǒng)內(nèi)核）中已構(gòu)建的被證明表現(xiàn)良好的TCP 啟發(fā)式算法. 隨著視頻流量份額的增加，這些定制化的嘗試可能會(huì)對(duì)互聯(lián)網(wǎng)的正常運(yùn)行構(gòu)成威脅. 盡管這種自私操作可能在短期內(nèi)對(duì)自己有利，但從長(zhǎng)遠(yuǎn)來看，這些行為將對(duì)其他參與者和自身都造成危害. 此外，新提出的用戶態(tài)傳輸工具，如QUIC[6]使問題變得更加復(fù)雜，因?yàn)镼UIC 之上的應(yīng)用為了提高自身的用戶體驗(yàn)（QoE）能夠自定義發(fā)送速率，這大大破壞了公平性原則. 盡管IETF RFC 5166[7]中提供了公平性設(shè)計(jì)指南，在RFC 5348[8]中規(guī)范了TCP 友好的擁塞控制算法，但目前尚未被廣泛采用[9].

因此，分析這些視頻應(yīng)用的行為以了解它們是否偏離公平性原則并構(gòu)成潛在風(fēng)險(xiǎn)非常重要. 然而，針對(duì)應(yīng)用發(fā)送行為進(jìn)行測(cè)量和理解的研究很有挑戰(zhàn).首先，受擁塞級(jí)別、丟包類型和流量模式影響的高度多樣化網(wǎng)絡(luò)環(huán)境對(duì)應(yīng)用行為會(huì)產(chǎn)生錯(cuò)綜復(fù)雜的影響.通過微觀的方式在模擬環(huán)境中重現(xiàn)它們的行為非常有挑戰(zhàn). 其次，這些應(yīng)用越來越多地使用具有端到端加密的專有協(xié)議，這使得它們對(duì)于外部人員來說就是黑盒子，很難準(zhǔn)確地揭示它們的行為. 此外，關(guān)聯(lián)分析應(yīng)用的QoE 與數(shù)據(jù)傳輸之間的關(guān)系也很困難.然而，只有了解這種關(guān)系才能幫助應(yīng)用改進(jìn)其傳輸策略.

為了解決這些問題，本文構(gòu)建了一個(gè)公平性測(cè)量系統(tǒng)并分析了具有代表性的商業(yè)視頻應(yīng)用Zoom的行為. 首先，該系統(tǒng)采用一種簡(jiǎn)化的方式，通過軟件控制的網(wǎng)絡(luò)損傷來模擬不同的網(wǎng)絡(luò)環(huán)境，從而能夠研究不同網(wǎng)絡(luò)狀況下的視頻應(yīng)用. 其次，系統(tǒng)能夠根據(jù)數(shù)據(jù)包的相似性關(guān)聯(lián)分析捕獲到的數(shù)據(jù)包，將數(shù)據(jù)包分為不同的類別（媒體包、探測(cè)包、重傳包、前向糾錯(cuò)包FEC 等），在不同的加密級(jí)別下都可以正常運(yùn)行. 最后，成功地將數(shù)據(jù)傳輸行為與QoE 指標(biāo)相關(guān)聯(lián)，包括端到端視頻及音頻時(shí)延、視頻幀率和視頻質(zhì)量，以確定重傳和FEC 是否真的提高了傳輸質(zhì)量或根本沒有. 在測(cè)量系統(tǒng)幫助下的主要發(fā)現(xiàn)可以總結(jié)為5 點(diǎn)：

1）自私的帶寬占用. Zoom 在追求自身QoE 的過程中，往往會(huì)自私地?fù)屨紟? 這些資源競(jìng)爭(zhēng)行為復(fù)雜多變，Zoom 在不同的場(chǎng)景下表現(xiàn)出不同的帶寬搶占行為.

2）自擁塞. 隨著丟包率的增加，Zoom 顯著加快重傳或提高FEC 比例. 這不僅會(huì)引入自身發(fā)包造成的擁塞（自擁塞），還會(huì)餓死其他參與競(jìng)爭(zhēng)的TCP 流.

3）使用過多的探測(cè)包. Zoom 使用過多的探測(cè)包來探測(cè)可用帶寬. 然而，就改善其自身的用戶體驗(yàn)而言，Zoom 過度使用探測(cè)包被證明是徒勞的.

4）對(duì)緩存區(qū)大小敏感. Zoom 對(duì)具有不同緩存區(qū)大小的網(wǎng)絡(luò)路徑的反應(yīng)不同. 當(dāng)帶寬時(shí)延積（BDP）較小時(shí)，它會(huì)尋求占用更多的帶寬份額. 但是，它在較大的BDP 值下將保持較低的帶寬份額.

5）啟動(dòng)順序不公平. 較早啟動(dòng)的視頻應(yīng)用不斷搶占更多的帶寬，而較晚啟動(dòng)的應(yīng)用則無法取得公平份額. 這表明速率控制算法無法收斂到穩(wěn)定點(diǎn).

從測(cè)量研究中獲得的這些發(fā)現(xiàn)啟發(fā)我們提出一個(gè)重要問題，是否有可能設(shè)計(jì)一種能夠平衡QoE 目標(biāo)與公平性原則的實(shí)時(shí)視頻傳輸算法？事實(shí)上，每個(gè)應(yīng)用的QoE 目標(biāo)與公平性之間的沖突經(jīng)常源于不明智地觸發(fā)重傳，進(jìn)而造成自擁塞. 通過避免這種“自擁塞”操作并合理地控制發(fā)送速率，應(yīng)用可以同時(shí)實(shí)現(xiàn)這2 個(gè)目標(biāo). 為此，本文提出了QLibra，這是一種速率控制算法，它可以適應(yīng)網(wǎng)絡(luò)波動(dòng)，同時(shí)公平地對(duì)待其他參與競(jìng)爭(zhēng)的流. QLibra 采用啟發(fā)式算法判斷當(dāng)前丟包是否是由于自擁塞，然后觸發(fā)不同的速率調(diào)整邏輯. 我們已經(jīng)實(shí)現(xiàn)了QLibra 并通過實(shí)驗(yàn)證明它可以取得比現(xiàn)有視頻應(yīng)用更好的QoE，同時(shí)對(duì)其他參與流無害. 為了所有流的長(zhǎng)期利益，應(yīng)該鼓勵(lì)負(fù)責(zé)任的視頻應(yīng)用部署類似QLibra 的傳輸機(jī)制.

本文的貢獻(xiàn)包括：1）開發(fā)了公平性測(cè)量系統(tǒng)并對(duì)典型視頻應(yīng)用Zoom 進(jìn)行了全面的測(cè)量研究；2）分析了若干導(dǎo)致不公平的重要操作，包括自私的帶寬占用、自擁塞和使用過多的探測(cè)包等；3）提出了QLibra，一種在保持公平原則的同時(shí)實(shí)現(xiàn)QoE 目標(biāo)的速率控制算法. 通過分析丟包成因并消除自擁塞行為，QLibra 能夠在不損害其他參與流的情況下提高每個(gè)應(yīng)用的QoE.

1 挑戰(zhàn)與方法論

由于視頻流量的快速增長(zhǎng)，多個(gè)視頻客戶端越來越有可能共同競(jìng)爭(zhēng)接入網(wǎng)絡(luò)中的瓶頸鏈路. 例如，家庭或校園WiFi 網(wǎng)絡(luò)可以為筆記本電腦、電視、智能手機(jī)和平板電腦提供服務(wù)，所有這些設(shè)備可以同時(shí)傳輸流式視頻. 許多研究分析了最后一英里接入網(wǎng)絡(luò)的性質(zhì)[10-11]. 無論是家庭中的WiFi 網(wǎng)絡(luò)還是公共場(chǎng)所中的LTE 網(wǎng)絡(luò)，最后一英里成為瓶頸鏈路的共識(shí)已經(jīng)確立[12]. 為了測(cè)量和分析這種越來越有可能廣泛存在的場(chǎng)景，我們構(gòu)建了一個(gè)測(cè)量系統(tǒng)讓Zoom[13]、Bilibili[14]和iPerf[15]在接入網(wǎng)絡(luò)中相互競(jìng)爭(zhēng). Zoom[13]是一款基于云平臺(tái)的視頻通信軟件，可以進(jìn)行虛擬視頻和音頻會(huì)議. Zoom 可以被選擇作為實(shí)時(shí)通信應(yīng)用的代表；Bilibili[14]提供直播服務(wù)，觀眾可以在其中與主播互動(dòng)，Bilibili 可以被選擇作為直播應(yīng)用的代表；iPerf[15]是一種廣泛使用的網(wǎng)絡(luò)性能測(cè)量工具，它可以創(chuàng)建TCP 流來測(cè)量?jī)啥酥g的吞吐量，iPerf 可以被選擇作為傳統(tǒng)TCP 連接的代表. 當(dāng)這3 者共享相同的瓶頸鏈路并一起競(jìng)爭(zhēng)時(shí)，測(cè)量它們的吞吐量表現(xiàn). 事實(shí)上，視頻點(diǎn)播應(yīng)用與實(shí)時(shí)視頻應(yīng)用（如視頻會(huì)議、直播）存在本質(zhì)區(qū)別，視頻點(diǎn)播應(yīng)用的內(nèi)容都是提前錄制好的，因此其下載模式有鮮明的ONOFF 特征，即周期性地一段時(shí)間內(nèi)持續(xù)下載視頻片段，一段時(shí)間內(nèi)不進(jìn)行任何下載；而實(shí)時(shí)視頻應(yīng)用的內(nèi)容都是實(shí)時(shí)產(chǎn)生的，因此其下載模式是持續(xù)下載視頻內(nèi)容. 為了更細(xì)粒度地進(jìn)行視頻應(yīng)用競(jìng)爭(zhēng)行為的測(cè)量和刻畫，選擇了2 類在時(shí)間尺度上連續(xù)傳輸?shù)膶?shí)時(shí)視頻應(yīng)用和傳統(tǒng)TCP 流進(jìn)行比較.

然而，測(cè)量過程中存在3 個(gè)挑戰(zhàn)：1）網(wǎng)絡(luò)參數(shù)（帶寬、丟包率）不斷變化，應(yīng)用的競(jìng)爭(zhēng)行為也隨之變化，描述和重現(xiàn)不同網(wǎng)絡(luò)場(chǎng)景下的競(jìng)爭(zhēng)行為具有挑戰(zhàn)性；2）商業(yè)視頻應(yīng)用是閉源的，它們使用專有協(xié)議加密傳輸，關(guān)于他們的架構(gòu)和協(xié)議的公開信息非常有限，因此了解它們的傳輸內(nèi)容和行為非常困難；3）測(cè)量和分析應(yīng)用的競(jìng)爭(zhēng)行為與相應(yīng)的QoE 指標(biāo)之間的相關(guān)性很有挑戰(zhàn). 為了應(yīng)對(duì)這些挑戰(zhàn)，本文構(gòu)建了一個(gè)測(cè)量系統(tǒng)來模擬瓶頸鏈路并觀察不同網(wǎng)絡(luò)場(chǎng)景中視頻應(yīng)用之間的競(jìng)爭(zhēng)行為；開發(fā)了自動(dòng)化測(cè)量工具來揭示這些應(yīng)用在競(jìng)爭(zhēng)中的網(wǎng)絡(luò)流量和QoE 特征.如圖1 所示，同時(shí)啟動(dòng)Zoom、Bilibili 和iPerf，它們的數(shù)據(jù)流經(jīng)過網(wǎng)絡(luò)模擬器構(gòu)建瓶頸鏈路. 使用Wireshark軟件[16]捕獲詳細(xì)的數(shù)據(jù)包級(jí)別信息，并分析3 個(gè)應(yīng)用各自的帶寬占用情況，通過改變網(wǎng)絡(luò)模擬器的網(wǎng)絡(luò)限制，分析網(wǎng)絡(luò)參數(shù)對(duì)帶寬公平性的影響.

為了評(píng)估視頻應(yīng)用對(duì)鏈路丟包的魯棒性，測(cè)量了FEC 比例和重傳比例. 通過分析Wireshark 捕獲的數(shù)據(jù)包記錄，首先根據(jù)數(shù)據(jù)包的協(xié)議類型區(qū)分?jǐn)?shù)據(jù)包和控制/信令包. 然后將數(shù)據(jù)包相互比較，如果發(fā)現(xiàn)2 個(gè)數(shù)據(jù)包的內(nèi)容相同，則判斷發(fā)生了重傳. 其次將錄制視頻的碼率與Wireshark 捕獲的吞吐量進(jìn)行比較. 視頻碼率與捕獲的吞吐量的差值就是重傳包和FEC 包. 去除計(jì)算的重傳包后，就可以估計(jì)FEC 包. 最后可以得到傳輸過程中的FEC 包比例和重傳包比例.

Fig.1 Fairness measurement system圖1 公平性測(cè)量系統(tǒng)

為了更好地了解這些視頻應(yīng)用的競(jìng)爭(zhēng)行為，本文開發(fā)了一套自動(dòng)化測(cè)量工具來理解這些視頻應(yīng)用的QoE：

1）為了評(píng)估視頻質(zhì)量，使用VMAF 工具[17]，它是Netflix 開發(fā)的一種感知視頻質(zhì)量評(píng)估算法. VMAF 根據(jù)參考和失真的視頻序列預(yù)測(cè)視頻質(zhì)量. 本文使用虛擬攝像頭軟件指定特定的視頻內(nèi)容作為視頻應(yīng)用發(fā)送端的攝像頭輸入，這確保了傳輸?shù)囊曨l內(nèi)容是一致的和可重復(fù)的；將接收端獲取的非受限網(wǎng)絡(luò)傳輸?shù)囊曨l作為參考視頻，與受限網(wǎng)絡(luò)傳輸?shù)囊曨l進(jìn)行對(duì)比，在傳輸過程中視頻應(yīng)用自適應(yīng)地調(diào)整分辨率和幀率；開發(fā)了一個(gè)幀對(duì)齊程序，可以自動(dòng)對(duì)齊參考視頻和失真視頻的幀，將對(duì)齊后的2 段視頻輸入到VMAF 工具中，就可以得到通過受限網(wǎng)絡(luò)傳輸?shù)氖д嬉曨l的VMAF分?jǐn)?shù)，設(shè)視頻幀編號(hào)為i（i=1,2,…,N），相應(yīng)VMAF分?jǐn)?shù)可以由訓(xùn)練好的支持向量機(jī)（SVM）模型獲得，記為VMAF（i），則視頻序列的平均VMAF分?jǐn)?shù)為

2）為了測(cè)量端到端視頻時(shí)延和視頻幀率，開發(fā)了一個(gè)二維碼生成器[18]，它以可配置的速率（例如，每秒30 幀）不斷生成二維碼，并在二維碼中存儲(chǔ)相應(yīng)的時(shí)間戳信息；還開發(fā)了二維碼識(shí)別器，它可以不斷識(shí)別二維碼，自動(dòng)獲取時(shí)間戳. 在公平性測(cè)量系統(tǒng)中并排放置了4 臺(tái)電腦，如圖1 所示. 2 臺(tái)電腦是視頻發(fā)送端，1 臺(tái)電腦是視頻接收端，1 臺(tái)電腦是視頻記錄器. 將二維碼生成器的內(nèi)容和視頻序列組合在一起作為視頻源，指定為發(fā)送端的虛擬攝像頭輸入.然后發(fā)送端通過網(wǎng)絡(luò)將其傳送給接收端. 視頻記錄器使用視頻捕獲程序同時(shí)記錄發(fā)送端的原始視頻和接收端的接收視頻. 在任意給定時(shí)間，同時(shí)記錄的發(fā)送端視頻二維碼與接收端視頻二維碼之間的時(shí)間戳差值就是端到端視頻時(shí)延. 最后使用二維碼識(shí)別器來識(shí)別錄制視頻中的二維碼，并計(jì)算端到端時(shí)延樣本. 端到端時(shí)延樣本是實(shí)時(shí)視頻捕獲、編碼、傳輸、解碼和渲染所產(chǎn)生的時(shí)延總和. 此外，還可以通過計(jì)算2 個(gè)二維碼之間產(chǎn)生的二維碼數(shù)量除以相距時(shí)間來計(jì)算視頻幀率. 由于視頻應(yīng)用會(huì)根據(jù)網(wǎng)絡(luò)情況調(diào)整幀率，并且網(wǎng)絡(luò)傳輸本身會(huì)對(duì)視頻內(nèi)容造成一定的損傷，所以視頻發(fā)送端和視頻接收端的幀率是不一樣的. 在實(shí)驗(yàn)過程中，由于識(shí)別速度快、全程自動(dòng)化，可以在短時(shí)間內(nèi)采集大量樣本，統(tǒng)計(jì)計(jì)算出端到端的視頻時(shí)延和視頻幀率. 設(shè)記錄到的發(fā)送端視頻二維碼對(duì)應(yīng)的時(shí)間戳為相應(yīng)接收端視頻二維碼對(duì)應(yīng)的時(shí)間戳為，則平均視頻時(shí)延為

3）為了測(cè)量端到端的音頻時(shí)延，使用聲波分析軟件[19]. 在系統(tǒng)中也并排放置了4 臺(tái)電腦，如圖1 所示. 2 臺(tái)電腦是音頻發(fā)送端，1 臺(tái)電腦是音頻接收端，1 臺(tái)電腦是音頻記錄器. 使用重復(fù)的滴答聲作為音頻源，并使用虛擬麥克風(fēng)將其指定給發(fā)送端，發(fā)送端通過網(wǎng)絡(luò)反復(fù)向接收端發(fā)送滴答聲. 音頻記錄器使用錄音軟件記錄從音頻發(fā)送端和音頻接收端發(fā)出的聲音. 可以在該軟件中直觀地分析捕獲的音頻信號(hào). 由于將發(fā)送端揚(yáng)聲器的音量設(shè)置得明顯低于接收端揚(yáng)聲器的音量，因此幅度較小的脈沖對(duì)應(yīng)于發(fā)送端產(chǎn)生的重復(fù)滴答聲；而幅度較大的脈沖則對(duì)應(yīng)于接收端接收到的滴答聲. 本文使用大脈沖和小脈沖之間的時(shí)間差作為端到端音頻時(shí)延. 設(shè)記錄到的發(fā)送端音頻脈沖對(duì)應(yīng)的時(shí)間戳為相應(yīng)接收端音頻脈沖對(duì)應(yīng)的時(shí)間戳為則平均音頻時(shí)延為

2 資源競(jìng)爭(zhēng)測(cè)量

在測(cè)量這些視頻應(yīng)用的性能表現(xiàn)之前，首先描述它們的工作流程以及產(chǎn)生的流量類型. 通過查看數(shù)據(jù)包記錄發(fā)現(xiàn)，Zoom 使用了2 種傳輸協(xié)議：用于傳輸控制消息的TCP 協(xié)議和用于傳輸音視頻數(shù)據(jù)的UDP 協(xié)議. Zoom 在應(yīng)用層構(gòu)建速率控制方案，根據(jù)網(wǎng)絡(luò)狀況調(diào)整其發(fā)送速率和FEC 冗余度. 有趣的是，Zoom 也將網(wǎng)絡(luò)成本考慮在內(nèi)，在可能的情況下嘗試節(jié)省連接云端的通信成本. 我們發(fā)現(xiàn)，當(dāng)視頻會(huì)議只有2 個(gè)與會(huì)者時(shí)，它采用點(diǎn)對(duì)點(diǎn)通信；但當(dāng)有3 個(gè)或更多與會(huì)者時(shí)，它就會(huì)切換到客戶端—服務(wù)器架構(gòu).由于客戶端—服務(wù)器架構(gòu)是Zoom 中的普遍場(chǎng)景，我們?cè)趯?shí)驗(yàn)過程中主要是測(cè)量客戶端—服務(wù)器架構(gòu).對(duì)于Bilibili 直播來說，主播總是把直播流媒體內(nèi)容推送到云端，觀眾再?gòu)脑贫死?nèi)容. 因此，Bilibili中的這2 個(gè)連接都是基于TCP 協(xié)議運(yùn)行的.

通過將3 個(gè)不同應(yīng)用（Zoom、Bilibili 和iPerf）的接收端在同一設(shè)備上啟動(dòng)，強(qiáng)制它們的流通過一個(gè)共享的瓶頸鏈路. 然后分別改變帶寬限制、丟包率、緩存大小和啟動(dòng)順序來觀察它們之間的資源競(jìng)爭(zhēng)行為. 在測(cè)量過程中，我們希望獲得收斂狀態(tài)并避免瞬態(tài)階段，因此通常在應(yīng)用啟動(dòng)后等待1 min 再開始測(cè)量，以便應(yīng)用進(jìn)入穩(wěn)定狀態(tài)，然后開始一個(gè)10 min 的測(cè)量周期，在此周期捕獲所有針對(duì)不同網(wǎng)絡(luò)場(chǎng)景的數(shù)據(jù)包，每個(gè)場(chǎng)景重復(fù)10 次，計(jì)算相應(yīng)數(shù)據(jù)的均值和標(biāo)準(zhǔn)差.

執(zhí)行此類測(cè)量能夠揭示這些黑盒應(yīng)用的內(nèi)部處理邏輯. 結(jié)果表明在不同場(chǎng)景下它們的資源搶占行為不斷變化，沒有應(yīng)用能夠始終超過其他應(yīng)用. 例如，Zoom 在帶寬受限的情況下壓制其他應(yīng)用，但Bilibili在BDP 較大時(shí)則處于領(lǐng)先地位. 它們?cè)诓煌瑘?chǎng)景中表現(xiàn)出不同程度的搶占行為，并且比傳統(tǒng)TCP 流iPerf 更具攻擊性，本文在2.1～2.4 節(jié)中介紹主要的測(cè)量結(jié)果.

2.1 限制帶寬

本文使用網(wǎng)絡(luò)模擬器將帶寬分別限制為0.5 Mbps、1 Mbps、2 Mbps、4 Mbps 和8 Mbps. Zoom、Bilibili 和iPerf 的數(shù)據(jù)流都經(jīng)過該瓶頸鏈路. 使用Wireshark[16]抓取網(wǎng)絡(luò)模擬器和無線接入點(diǎn)之間的數(shù)據(jù)包，并分析這3 個(gè)應(yīng)用的吞吐量占比. 設(shè)Zoom、Bilibili 和iPerf 的平均吞吐量分別為 G1、G2和 G3，則總吞吐量Gsum=G1+G2+G3，Zoom、Bilibili 和iPerf 的吞吐量占比分別為結(jié)果如圖2（a）所示. 當(dāng)限制帶寬比較低的時(shí)候，Zoom 和Bilibili 猛烈地?fù)屨加邢薜膸捹Y源，其中Zoom 搶占帶寬能力最強(qiáng)，其次是Bilibili. 傳統(tǒng)的TCP 流iPerf 被擠壓到吞吐量占比低于10%. 具體來說，當(dāng)限制帶寬為0.5 Mbps和1 Mbps 時(shí)，Zoom 的發(fā)送速率分別接近0.6 Mbps和0.9 Mbps. 在這種情況下，Zoom 的發(fā)送行為加劇了瓶頸鏈路的擁塞，這不僅搶占了競(jìng)爭(zhēng)者的資源，降低了競(jìng)爭(zhēng)者的性能，而且自身也無法獲得收益（即出現(xiàn)自擁塞）. 當(dāng)限制帶寬達(dá)到2 Mbps 及以上時(shí)，Zoom 成功獲取到它所需要的帶寬（約1 Mbps）并保持在這個(gè)吞吐量. 當(dāng)限制帶寬達(dá)到4 Mbps 及以上時(shí)，Bilibili 也成功獲得了自己需要的帶寬（約2 Mbps）并維持這個(gè)吞吐量. 傳統(tǒng)的TCP 流iPerf 占用剩余的帶寬資源.

Fig.2 Throughput ratio of Zoom, Bilibili and iPerf when competing under different restricted bandwidth, and throughput composition of Zoom圖2 Zoom、Bilibili 和iPerf 在不同帶寬限制下競(jìng)爭(zhēng)時(shí)的吞吐量占比和Zoom 的吞吐量構(gòu)成

本文還分析了Zoom 在這些限制帶寬場(chǎng)景下相應(yīng)的吞吐量構(gòu)成，如圖2（b）所示. 在不同的限制帶寬條件下，Zoom 通過發(fā)送FEC 包來抵抗網(wǎng)絡(luò)丟包，這是實(shí)時(shí)流媒體中實(shí)現(xiàn)可靠性的常用方法. 在實(shí)驗(yàn)中發(fā)現(xiàn)Zoom 的FEC 冗余包比例一般在25%～35%之間. 這說明Zoom 為了保證自身的用戶體驗(yàn)，發(fā)送了大量冗余的FEC 包來?yè)屨紟? 與FEC 不同，重傳僅在需要時(shí)添加冗余，因此帶寬效率更高. 從圖2（b）中可以發(fā)現(xiàn)，Zoom 采用了不同的重傳比例來輔助傳輸.與使用FEC 相比，使用重傳的一個(gè)主要缺點(diǎn)是在網(wǎng)絡(luò)時(shí)延較大時(shí)效果不佳. 因此，當(dāng)限制帶寬降低到0.5 Mbps 且相應(yīng)的網(wǎng)絡(luò)往返時(shí)延（Round-Trip time，RTT）增加時(shí)，Zoom 會(huì)降低重傳比例并相應(yīng)增加FEC 冗余包比例.

通過分析Wireshark 捕獲的數(shù)據(jù)包記錄，發(fā)現(xiàn)Zoom 在網(wǎng)絡(luò)帶寬受限的情況下，在測(cè)量過程的早期階段使用探測(cè)數(shù)據(jù)包來探測(cè)可用帶寬. 在圖3 中展示了在1 Mbps 限制帶寬下競(jìng)爭(zhēng)時(shí)Zoom 的詳細(xì)信息，包括Zoom 的吞吐量、卡頓持續(xù)時(shí)間和探測(cè)數(shù)據(jù)包的數(shù)量. 如果2 個(gè)相鄰視頻幀的內(nèi)容完全相同，則判斷發(fā)生卡頓事件. 為了更好地在時(shí)間序列中展示卡頓時(shí)長(zhǎng)，將某個(gè)時(shí)間點(diǎn)的卡頓時(shí)長(zhǎng)表示為該時(shí)間點(diǎn)前后10 s 內(nèi)的累計(jì)卡頓時(shí)長(zhǎng). 同理，某個(gè)時(shí)間點(diǎn)的探測(cè)報(bào)文數(shù)表示為該時(shí)間點(diǎn)前后10 s 內(nèi)發(fā)送的探測(cè)報(bào)文的累計(jì)數(shù). 從圖3 中可以觀察到吞吐量的突發(fā)與探測(cè)包數(shù)量的突發(fā)是一致的. 推測(cè)吞吐量突發(fā)是由探測(cè)數(shù)據(jù)包突發(fā)引起的，這也導(dǎo)致相應(yīng)的卡頓持續(xù)時(shí)間增加. Zoom 使用探測(cè)數(shù)據(jù)包來探測(cè)可用帶寬，這不僅會(huì)占用額外的帶寬資源，對(duì)其他應(yīng)用造成不公平的影響，還會(huì)阻塞自身并導(dǎo)致自身的卡頓事件.

Fig.3 Zoom’s throughput, stall duration and probing packet count under the 1 Mbps restricted bandwidth圖3 在1 Mbps 限制帶寬下競(jìng)爭(zhēng)時(shí)Zoom 的吞吐量、卡頓持續(xù)時(shí)間和探測(cè)包數(shù)

2.2 限制丟包率

由于在實(shí)驗(yàn)中只進(jìn)行了Zoom、Bilibili 和iPerf這3 個(gè)應(yīng)用競(jìng)爭(zhēng)行為的測(cè)量，這3 個(gè)應(yīng)用的總吞吐量需求較小，為了給它們構(gòu)建競(jìng)爭(zhēng)環(huán)境并更細(xì)粒度地觀測(cè)它們之間的競(jìng)爭(zhēng)行為，本文使用網(wǎng)絡(luò)模擬器將帶寬限制在了2 Mbps，并將丟包率分別控制在1%、2%、5%、10%和20%. 由于數(shù)據(jù)包是在進(jìn)入網(wǎng)絡(luò)模擬器之前捕獲的，因此這些數(shù)據(jù)包的總吞吐量可能略微超過2 Mbps.

圖4（a）展示了3 個(gè)應(yīng)用的吞吐量占比. 隨著丟包率從1%上升到20%，iPerf 的吞吐量占比從20%下降到4%，Bilibili 的吞吐量占比從44%下降到24%. 不過在這個(gè)過程中，為了保持接收端的吞吐量，Zoom的吞吐量占比從36%提升到72%，發(fā)送速率從0.71 Mbps提升到1.42 Mbps. 可以看出，隨著網(wǎng)絡(luò)丟包率的增加，Zoom 在帶寬占用方面變得越來越激進(jìn)，使其他參與的流處于饑餓狀態(tài). 另一方面，當(dāng)丟包率達(dá)到20%時(shí)，Bilibili 仍能保持24%的吞吐量占比，遠(yuǎn)高于iPerf. 可以推測(cè)，雖然Bilibili 使用TCP 連接，但它調(diào)整TCP協(xié)議棧中的參數(shù)以提高自身性能.

圖4（b）展示了Zoom 相應(yīng)的吞吐量構(gòu)成. 隨著網(wǎng)絡(luò)丟包率的增加，Zoom 增加FEC 冗余比例. Zoom 將丟包率量化為多個(gè)不同的級(jí)別，并根據(jù)當(dāng)前檢測(cè)到的網(wǎng)絡(luò)丟包情況來確定FEC 級(jí)別[20]. 結(jié)合視頻幀中的數(shù)據(jù)包數(shù)量，Zoom 最終確定相應(yīng)幀中添加的FEC冗余數(shù)據(jù)包數(shù)量. 當(dāng)網(wǎng)絡(luò)RTT 較小時(shí)，Zoom 采用重傳作為補(bǔ)充方案. 從圖4（b）中可以發(fā)現(xiàn)，當(dāng)丟包率達(dá)到20%時(shí)，Zoom 顯著提高了FEC 比例，同時(shí)根據(jù)FEC 抗丟包能力調(diào)整重傳比例.

2.3 限制緩存大小

首先將帶寬限制在2 Mbps 以構(gòu)建Zoom、Bilibili和iPerf 相互競(jìng)爭(zhēng)的環(huán)境. Zoom 的吞吐量占用約為1.2 Mbps，RTT 約 為230 ms. Bilibili 的吞吐量約為0.8 Mbps，RTT 約為10 ms. iPerf 的吞吐量和RTT 極低，可以忽略不計(jì).因此估計(jì)1×BDP=1.2 Mbps×230 ms（BDPZoom）+0.8 Mbps×10 ms（BDPBilibili）=35.5 KB. 然 后使用網(wǎng)絡(luò)模擬器將緩存區(qū)大小分別限制為1/4 BDP、1 BDP、4 BDP、16 BDP 和64 BDP.

Fig.4 Throughput ratio of Zoom, Bilibili and iPerf when competing under different restricted packet loss rate, and throughput composition of Zoom圖4 Zoom、Bilibili 和iPerf 在不同丟包率限制下競(jìng)爭(zhēng)時(shí)的吞吐量占比和Zoom 的吞吐量構(gòu)成

Fig.5 Throughput ratio of Zoom, Bilibili and iPerf when competing under different restricted buffer size, and throughput composition of Zoom圖5 Zoom、Bilibili 和iPerf 在不同緩存大小限制下競(jìng)爭(zhēng)時(shí)的吞吐量占比和Zoom 吞吐量構(gòu)成

吞吐量占比的結(jié)果如圖5（a）所示. 當(dāng)緩存區(qū)比較小時(shí)（1/4 BDP、1 BDP 和4 BDP），Zoom 會(huì)占用很大比例的吞吐量. 當(dāng)緩存區(qū)增加到16 BDP 時(shí)，Zoom的吞吐量占比下降，而Bilibili 的吞吐量占比增加. 因此推測(cè)緩存區(qū)大小的增加導(dǎo)致排隊(duì)時(shí)延的增加. 對(duì)時(shí)延敏感的Zoom 不再參與帶寬搶占，時(shí)延容忍度更高的直播應(yīng)用Bilibili 則繼續(xù)搶占帶寬，體現(xiàn)出變化的競(jìng)爭(zhēng)策略. 當(dāng)緩存區(qū)大小增加到64 BDP 時(shí)，Zoom和Bilibili 的吞吐量占比都下降了，傳統(tǒng)的TCP 連接iPerf 占總吞吐量的81%. 這說明此時(shí)的緩存區(qū)大小也達(dá)到了Bilibili 的閾值，Bilibili 不再參與競(jìng)爭(zhēng). 結(jié)果表明，不同的緩存區(qū)大小將觸發(fā)不同應(yīng)用的不同競(jìng)爭(zhēng)行為. 當(dāng)緩存區(qū)較小時(shí)，Zoom 占用吞吐量的60%左右. 隨著緩存區(qū)的不斷增加，Bilibili 首先表現(xiàn)出搶占帶寬的自私行為，然后是iPerf. 可見，競(jìng)爭(zhēng)行為是復(fù)雜多變的，并且每個(gè)應(yīng)用在不同場(chǎng)景下都有自己的自私行為.

圖5 展示 Zoom、Bilibili 和iPerf 在不同緩存大小限制下競(jìng)爭(zhēng)時(shí)不同應(yīng)用的吞吐量占比和Zoom 的吞吐量構(gòu)成. 當(dāng)緩存區(qū)大小為1/4 BDP、1 BDP 和4 BDP時(shí)，Zoom 的吞吐量占比在60%左右浮動(dòng)，這時(shí)候Zoom 還傳輸了大量的FEC 冗余數(shù)據(jù)來保證其用戶體驗(yàn). 當(dāng)緩存區(qū)大小達(dá)到16 BDP 和64 BDP 時(shí)，Zoom的吞吐量占比顯著下降. Zoom 相應(yīng)降低了FEC 的比例以減少冗余. 同時(shí)，當(dāng)緩存區(qū)大小增加時(shí)，RTT 將繼續(xù)增加. 這樣一來，Zoom 也降低了重傳的比例，以減少時(shí)延的影響.

2.4 不同的啟動(dòng)順序

在2.1、2.2、2.3 節(jié)的3 組實(shí)驗(yàn)中，首先在不限制帶寬的情況下將3 個(gè)應(yīng)用全部啟動(dòng). 當(dāng)它們達(dá)到穩(wěn)定狀態(tài)時(shí)，開始限制帶寬. 因此，實(shí)驗(yàn)中并沒有討論應(yīng)用的啟動(dòng)順序?qū)Ω?jìng)爭(zhēng)行為的影響. 在2.4 節(jié)中研究啟動(dòng)順序?qū)Ω?jìng)爭(zhēng)行為的影響. 為了構(gòu)建競(jìng)爭(zhēng)環(huán)境，首先使用網(wǎng)絡(luò)模擬器將帶寬限制為2 Mbps. 然后按照不同的順序啟動(dòng)不同的應(yīng)用. 用A、B 和C 分別表示Zoom、Bilibili 和iPerf. 例如ABC 表示先啟動(dòng)Zoom，然后是Bilibili，最后是iPerf. 其他表達(dá)式的含義可以類推. 本文測(cè)量了6 種可能的順序（ABC、ACB、BAC、BCA、CAB 和CBA）.

圖6（a）展示了3 個(gè)應(yīng)用的吞吐量占比. 可以發(fā)現(xiàn)，應(yīng)用的啟動(dòng)順序影響帶寬占用，3 個(gè)應(yīng)用的吞吐量占比從大到小的順序與其啟動(dòng)順序基本一致. 也就是說，最先啟動(dòng)的應(yīng)用具有占用更多吞吐量的優(yōu)勢(shì). 還有一個(gè)比較有意思的現(xiàn)象是Zoom 在先啟動(dòng)時(shí)的吞吐占比比Bilibili 在先啟動(dòng)時(shí)的吞吐占比高，也比iPerf 在先啟動(dòng)時(shí)的吞吐占比高. 這在某種程度上反映了3 款應(yīng)用搶占帶寬的能力，即Zoom 強(qiáng)于Bilibili，Bilibili 強(qiáng) 于iPerf. 該實(shí)驗(yàn)還表明視頻應(yīng)用的碼率控制算法無法收斂到一個(gè)穩(wěn)定點(diǎn). 較早啟動(dòng)的應(yīng)用不斷搶占更多帶寬，而較晚啟動(dòng)的應(yīng)用則無法獲得公平份額.

Fig.6 Throughput ratio of Zoom, Bilibili and iPerf when competing with different start order, and throughput composition of Zoom (A:Zoom, B: Bilibili, C: iPerf. ABC means that we start Zoom first, then Bilibili, and finally iPerf. The meaning of other expressions can be deduced by analogy)圖6 Zoom、Bilibili 和iPerf 在不同啟動(dòng)順序下競(jìng)爭(zhēng)時(shí)的吞吐量占比和Zoom 的吞吐量構(gòu)成. （A：Zoom，B：Bilibili，C：iPerf. ABC 表示先啟動(dòng)Zoom，然后是Bilibili，最后是iPerf. 其他表達(dá)式的含義可以類推）

如圖6（b）所示，當(dāng)Zoom 先啟動(dòng)時(shí)，Zoom 吞吐占用量較高，對(duì)應(yīng)的FEC 比例也較高. 當(dāng)其他應(yīng)用先啟動(dòng)時(shí)，Zoom 會(huì)降低自身的FEC 比例. 另外，Zoom 使用不同的重傳比例來輔助FEC 傳輸.

3 QoE 表現(xiàn)分析

為了更好地理解視頻應(yīng)用的競(jìng)爭(zhēng)行為，本文使用自動(dòng)化測(cè)量工具來測(cè)量這些應(yīng)用的QoE 指標(biāo)，包括視頻質(zhì)量、端到端視頻/音頻時(shí)延和視頻幀率. 和第2 節(jié)一樣，也構(gòu)造了Zoom、Bilibili 和iPerf 相互競(jìng)爭(zhēng)的不同網(wǎng)絡(luò)場(chǎng)景，包括限制帶寬、限制丟包率、限制緩存大小和不同的啟動(dòng)順序.

3.1 限制帶寬

使用網(wǎng)絡(luò)模擬器將帶寬分別限制為0.5 Mbps、1 Mbps、2 Mbps、4 Mbps 和8 Mbps. Zoom、Bilibili 和iPerf 的數(shù)據(jù)流都經(jīng)過這個(gè)瓶頸鏈路. 測(cè)量了Zoom 和Bilibili 的QoE 表現(xiàn)，如圖7 所示.

在不同的限制帶寬條件下，Zoom 的端到端視頻和音頻時(shí)延基本在百毫秒級(jí)別，而Bilibili 的視頻和音頻時(shí)延在幾十秒級(jí)別，這是由不同的應(yīng)用需求造成的. Zoom 是一個(gè)視頻會(huì)議應(yīng)用，需要很強(qiáng)的實(shí)時(shí)交互，而Bilibili 是一個(gè)直播應(yīng)用，觀眾對(duì)抖動(dòng)更為敏感.

與視頻相比，音頻對(duì)用戶體驗(yàn)更為重要. 我們發(fā)現(xiàn)Zoom 和Bilibili 的視頻時(shí)延都高于音頻時(shí)延. 因此推測(cè)當(dāng)帶寬受限時(shí)，應(yīng)用會(huì)優(yōu)先傳輸數(shù)據(jù)量較小且對(duì)時(shí)延更敏感的音頻內(nèi)容. 另一個(gè)有趣的發(fā)現(xiàn)是當(dāng)限制帶寬降低時(shí)，Zoom 會(huì)降低視頻幀率以保障音頻時(shí)延，因?yàn)橐纛l在在線會(huì)議環(huán)境中更為重要. 具體來說，當(dāng)限制帶寬從1 Mbps 降低到0.5 Mbps 時(shí)，Zoom接收端的平均幀率從10.5 FPS 降低到1.5 FPS，而音頻時(shí)延減少了0.2 s.

由于帶寬受限導(dǎo)致的丟幀和卡頓事件，VMAF分?jǐn)?shù)不是很高（滿分為100 分）. 當(dāng)限制帶寬從0.5 Mbps增加到2 Mbps 時(shí)，Zoom 的VMAF 分?jǐn)?shù)從25.54 增加到48.14，略高于Bilibili. 這是因?yàn)閆oom 搶占帶寬的自私行為有效地保證了自身的視頻質(zhì)量. 但是，當(dāng)限制帶寬達(dá)到4 Mbps 及以上時(shí)，Bilibili 獲得了它需要的帶寬，相應(yīng)VMAF 分?jǐn)?shù)在提高.

3.2 限制丟包率

首先使用網(wǎng)絡(luò)模擬器將帶寬限制為2 Mbps 以構(gòu)建競(jìng)爭(zhēng)環(huán)境，然后用它來控制丟包率分別為1%、2%、5%、10%和20%. Zoom 和Bilibili 的QoE 表現(xiàn)如圖8所示.

Fig.7 QoE performances of Zoom and Bilibili when competing under different restricted bandwidth圖7 在不同帶寬限制下競(jìng)爭(zhēng)時(shí)Zoom 和Bilibili 的QoE 表現(xiàn)

隨著丟包率的增加，Zoom 的音頻時(shí)延基本保持穩(wěn)定，對(duì)應(yīng)的視頻時(shí)延略有增加，Bilibili 的音頻和視頻時(shí)延不斷增加. 由于Zoom 會(huì)根據(jù)不同的丟包情況搶占帶寬來保證自身的傳輸，因此其接收端的視頻幀率保持穩(wěn)定，F(xiàn)PS 為13～16. 在丟包率為20%的情況下，帶寬被Zoom 嚴(yán)重占用. 此時(shí)，Bilibili 占用的帶寬相對(duì)較低，相應(yīng)的接收端視頻幀率也較低，約為6 FPS.

Fig.8 QoE performances of Zoom and Bilibili when competing under different packet loss rate圖8 在不同丟包率限制下競(jìng)爭(zhēng)時(shí)Zoom 和Bilibili 的QoE 表現(xiàn)

隨著丟包率的增加，Zoom 的VMAF 分?jǐn)?shù)也出人意料地增加. 如圖8 所示，當(dāng)丟包率為20%時(shí)，Zoom的VMAF 分?jǐn)?shù)達(dá)到了50.68，屬于比較高的得分. 這是由于它在網(wǎng)絡(luò)惡化時(shí)激進(jìn)地?fù)屨紟捹Y源，表現(xiàn)出對(duì)其他競(jìng)爭(zhēng)者不公平的行為. 在整個(gè)過程中，Bilibili的VMAF 分?jǐn)?shù)由于分配的帶寬較小而不斷下降.

3.3 限制緩存大小

為了營(yíng)造競(jìng)爭(zhēng)環(huán)境，首先將帶寬限制在2 Mbps，然后將緩存大小分別限制為1/4 BDP、1 BDP、4 BDP、16 BDP 和64 BDP. 本文測(cè)量了Zoom 和Bilibili 相 應(yīng)的QoE 表現(xiàn)，結(jié)果如圖9 所示.

當(dāng)緩存大小持續(xù)增加時(shí)，Zoom 的音頻時(shí)延和視頻時(shí)延急劇上升，接收端的視頻幀率不斷下降. 當(dāng)緩存大小增加到16 BDP 及以上時(shí)，Zoom 的吞吐量占比已經(jīng)很低了. 再加上緩存大小增加導(dǎo)致的RTT 增加，整體時(shí)延較大. Bilibili 的情況類似. 不同的是，當(dāng)緩存大小為16 BDP 時(shí)，Bilibili 的吞吐量占比最高. 因此，相應(yīng)的音頻時(shí)延和視頻時(shí)延都比較低，接收端的視頻幀率也比較高. 但是當(dāng)緩存大小增加到64 BDP時(shí)，Bilibili 的吞吐量急劇下降，此時(shí)的QoE 性能表現(xiàn)也比較差.

VMAF 分?jǐn)?shù)的表現(xiàn)與吞吐量占比表現(xiàn)基本一致.當(dāng)緩存大小增加時(shí)，Zoom 的VMAF 得分不斷降低，Bilibili 的情況類似. 但是因?yàn)锽ilibili 在緩存大小為16 BDP 時(shí)吞吐量較高，所以對(duì)應(yīng)的VMAF 分?jǐn)?shù)也較高. 當(dāng)緩存大小增加到64 BDP 時(shí)，Bilibili 的VMAF分?jǐn)?shù)在下降.

3.4 不同的啟動(dòng)順序

首先將帶寬限制在2 Mbps 以構(gòu)建競(jìng)爭(zhēng)環(huán)境，然后按照不同的順序啟動(dòng)不同的應(yīng)用. 本文用A、B 和C 分別表示Zoom、Bilibili 和iPerf. 例如ABC 表示先啟動(dòng)Zoom，然后是Bilibili，最后是iPerf. 其他表達(dá)式的含義可以類推. 本文測(cè)量了6 種可能的順序（ABC、ACB、BAC、BCA、CAB 和CBA）. Zoom 和Bilibili 的QoE 表現(xiàn)如圖10 所示.

隨著啟動(dòng)順序的變化，Zoom 的音頻時(shí)延基本維持在0.57 s 左右，變化不大，這說明Zoom 可以很好地保障音頻時(shí)延. 同時(shí)，Zoom 最先啟動(dòng)時(shí)（ABC 和ACB）相應(yīng)的視頻時(shí)延較低，接收端的視頻幀率也略高，因?yàn)榇藭r(shí)它具有更大的吞吐量占比. 同樣，Bilibili 先啟動(dòng)時(shí)（BAC 和BCA）占用的帶寬也略高，這導(dǎo)致更低的音頻/視頻時(shí)延和更高的視頻幀率.

Zoom 先啟動(dòng)時(shí)，其VMAF 分?jǐn)?shù)較高，這是因?yàn)榇藭r(shí)Zoom 使用FEC 包來保證其視頻傳輸，占用了較高的吞吐量. 同樣，Bilibili 先啟動(dòng)時(shí)，它的VMAF 分?jǐn)?shù)超過了Zoom 的分?jǐn)?shù).

4 QLibra：QoE 和公平性之間的平衡

第2～3 節(jié)測(cè)量結(jié)果表明，Zoom 傾向于搶占帶寬來保證自身的QoE. 然而，其中一些發(fā)送行為被證明是無用的，并且對(duì)其他參與者和自身都是有害的. 造成這種情況的一個(gè)關(guān)鍵原因是Zoom 總是將數(shù)據(jù)包丟失視為隨機(jī)丟包，因此觸發(fā)了一些不必要的重傳行為. 如果網(wǎng)絡(luò)真的出現(xiàn)擁塞丟包，那么就不需要這樣的重傳，這只會(huì)引入額外的擁塞并導(dǎo)致不公平問題. 我們將這類丟包稱為“自擁塞”丟包. 基于這些發(fā)現(xiàn)，我們提出了傳輸算法QLibra，它既能夠?qū)崿F(xiàn)應(yīng)用的QoE 目標(biāo)，同時(shí)又能保障參與流之間的公平性. 在本節(jié)中，首先介紹QLibra 的設(shè)計(jì)并在本文的測(cè)量系統(tǒng)中對(duì)其進(jìn)行實(shí)驗(yàn)評(píng)估.

4.1 QLibra 設(shè)計(jì)

QLibra 的核心思路是確定丟包是否由自擁塞傳輸引起. 與現(xiàn)有的擁塞控制算法不同，QLibra 不會(huì)對(duì)所有數(shù)據(jù)包丟失做出同樣的反應(yīng). 不失一般性，在下文中，我們將基于Reno 描述QLibra. Reno 基于AIMD等同對(duì)待每一次丟包.

QLibra 對(duì)待自擁塞丟包與非自擁塞丟包完全不同. 具體來說，如果丟包被判斷為自擁塞造成的結(jié)果，QLibra 將觸發(fā)正常的乘性減模塊以快速降低發(fā)送速率. 但是，如果丟包不是由于自身?yè)砣斐傻模琎Libra將承擔(dān)一些風(fēng)險(xiǎn)選擇不降速，因?yàn)樵陔S機(jī)丟包的情況下這樣做是有意義的. 首先，QLibra 將根據(jù)丟包率的變化按比例增加擁塞窗口cwnd，以便發(fā)送端盡快恢復(fù). 為了更好地利用鏈路，QLibra 也避免觸發(fā)乘性減機(jī)制，但這不會(huì)損害公平性，因?yàn)閬G包已經(jīng)被推斷為隨機(jī)丟包.

QLibra 采用啟發(fā)式算法判斷自擁塞狀態(tài). 如算法1 所示，算法的輸入包括丟包率lossi、確定算法處理粒度的可配置閾值threshold以及自擁塞狀態(tài)self_congested，這是一個(gè)初始設(shè)置為false 的布爾變量. 本文將處理過程劃分為一組連續(xù)的時(shí)隙. 一旦當(dāng)前記錄的丟包率lossi與之前的丟包率lossi-1的差值超過閾值，那么就觸發(fā)算法的調(diào)節(jié)過程.

算法1.確定自擁塞狀態(tài)算法.

輸入：第i個(gè)時(shí)隙的丟包率lossi，丟包率變化的容忍閾值threshold，丟包率lossi?1的成因self_congestedi?1（true 代表自擁塞，false 代表非自擁塞，初始化為false）；

輸出：丟包率lossi的成因self_congestedi；擁塞窗口cwnd.

本文在圖11 狀態(tài)轉(zhuǎn)移機(jī)的幫助下介紹算法1.

Fig.11 State transition machine圖11 狀態(tài)轉(zhuǎn)移機(jī)

1）從自擁塞到非自擁塞. 如果之前的丟包已被確定為自擁塞丟包，QLibra 會(huì)立即降低發(fā)送速率. 如果此時(shí)丟包率繼續(xù)增加（lossi?1

2）從非自擁塞到自擁塞. 如果丟包率不斷增加（即lossi?2

3）保持非自擁塞狀態(tài). 由于數(shù)據(jù)包丟失很可能是由隨機(jī)網(wǎng)絡(luò)丟包引起的，因此發(fā)送端可以通過向網(wǎng)絡(luò)發(fā)送更多數(shù)據(jù)來承擔(dān)一些風(fēng)險(xiǎn). 它首先根據(jù)丟包率變化計(jì)算加速比speedup_rate←lossi/lossi-1，然后相應(yīng)增加擁塞窗口，以便傳輸可以更快地從丟包中恢復(fù). （算法1 中的行④～⑤. ）

4.2 QLibra 測(cè)量

基于QUIC 協(xié)議棧實(shí)現(xiàn)了QLibra，修改其中原生Reno 擁塞控制算法，并在上層實(shí)現(xiàn)了實(shí)時(shí)視頻應(yīng)用，接著在測(cè)量平臺(tái)上進(jìn)行了實(shí)驗(yàn)評(píng)估. 具體來說，探究了QLibra 在與Zoom、Bilibili 和傳統(tǒng)TCP 流競(jìng)爭(zhēng)時(shí)關(guān)于保障公平性和QoE 的有效性.

1）第1 個(gè)實(shí)驗(yàn)測(cè)量了QLibra 和Zoom 在1 000 kbps帶寬限制和10%丟包率限制下競(jìng)爭(zhēng)時(shí)的吞吐量表現(xiàn).如圖12 所示，最初QLibra 和Zoom 各占有大約900 kbps的吞吐量. 當(dāng)添 加1 000 kbps 帶寬限制時(shí)，QLibra 和Zoom 都出現(xiàn)了吞吐量突發(fā)增長(zhǎng). 然后QLibra 和Zoom都進(jìn)入穩(wěn)定階段，QLibra 的平均吞吐量為590 kbps，Zoom 的平均吞吐量為570 kbps. 基于此，可以推測(cè)QLibra 實(shí)現(xiàn)了比Zoom 更好的QoE. 當(dāng)添加10%的丟包率限制時(shí)，QLibra 和Zoom 都會(huì)發(fā)送額外的數(shù)據(jù)包來保障自身的性能. QLibra 的平均吞吐量為1 160 kbps，Zoom 的平均吞吐量為1 180 kbps. 可以發(fā)現(xiàn)，當(dāng)QLibra判斷丟包是由于其他應(yīng)用搶占帶寬導(dǎo)致的時(shí)候，它也會(huì)主動(dòng)提升速率以獲得更好的性能. 總體而言，QLibra 和Zoom 一起競(jìng)爭(zhēng)時(shí)，帶寬分配相對(duì)公平.

Fig.12 The throughputs when QLibra and Zoom competing under 1 000 kbps restricted bandwidth and 10% restricted packet loss rate圖12 QLibra 和Zoom 在1 000 kbps 帶寬限制和10%丟包率限制下競(jìng)爭(zhēng)時(shí)的吞吐量

2）第2 個(gè)實(shí)驗(yàn)測(cè)量了QLibra 和Bilibili 在1 000 kbps帶寬限制和10%丟包率限制下競(jìng)爭(zhēng)時(shí)的吞吐量表現(xiàn).如圖13 所示，QLibra 最初占有約900 kbps 的吞吐量，Bilibili 占有約1900 kbps 的吞吐量. 當(dāng)添加1 000 kbps帶寬限制時(shí)，QLibra 和Bilibili 都出現(xiàn)了吞吐量突發(fā)增長(zhǎng)，然后它們進(jìn)入穩(wěn)定階段. QLibra 的平均吞吐量為560 kbps，Bilibili 的平均吞吐量為500 kbps. 基于此，可以發(fā)現(xiàn)QLibra 和Bilibili 一起競(jìng)爭(zhēng)時(shí)帶寬分配相對(duì)公平. 當(dāng)添加10%的丟包率限制時(shí)，QLibra 和Bilibili都會(huì)發(fā)送額外的數(shù)據(jù)包來保障自身的性能. QLibra的平均吞吐量為1 160 kbps，Bilibili 的平均吞吐量為1960 kbps.

3）第3 個(gè)實(shí)驗(yàn)測(cè)量了QLibra 和原生Reno 在不同限制場(chǎng)景下一起競(jìng)爭(zhēng)時(shí)的性能表現(xiàn). 如圖14 所示，最初QLibra 和原生Reno 各占有大約900 kbps 的吞吐量.當(dāng)添加1 000 kbps 的帶寬限制時(shí)，QLibra 的平均吞吐量是540 kbps，原生Reno 的平均吞吐量是470 kbps.基于此，可以推測(cè)QLibra 對(duì)其他參與的TCP 流無害.當(dāng)添加10%的丟包率限制時(shí)，QLibra 會(huì)發(fā)送額外的數(shù)據(jù)包來保障自身性能，而原生Reno 則會(huì)迅速降低吞吐量占用. QLibra 的平均吞吐量為1 120 kbps，原生Reno 的平均吞吐量為640 kbps. 可以發(fā)現(xiàn)，當(dāng)QLibra判斷丟包是由于自身?yè)屨紟捫袨閷?dǎo)致時(shí)，并沒有主動(dòng)提速. 通過有效判斷丟包成因的方式，QLibra 可以與傳統(tǒng)的TCP 流很好地共存.

Fig.13 The throughput when QLibra and Bilibili competing under 1 000 kbps restricted bandwidth and 10% restricted packet loss rate圖13 QLibra 和Bilibili 在1 000 kbps 帶寬限制和10%丟包率限制下競(jìng)爭(zhēng)時(shí)的吞吐量

Fig.14 The throughput when QLibra and original Reno competing under 1 000 kbps restricted bandwidth and 10% restricted packet loss rate圖14 QLibra 和原生Reno 在1 000 kbps 帶寬限制和10%丟包率限制下競(jìng)爭(zhēng)時(shí)的吞吐量

通過以上3 組實(shí)驗(yàn)發(fā)現(xiàn)，QLibra 可以有效判斷當(dāng)前丟包的成因. 當(dāng)QLibra 發(fā)現(xiàn)已經(jīng)存在其他流的攻擊性行為導(dǎo)致丟包時(shí)，也會(huì)提高發(fā)送速率來保證自身的QoE. 相反，當(dāng)QLibra 發(fā)現(xiàn)當(dāng)前丟包是自擁塞時(shí)，它會(huì)回退到原生Reno 并與其他傳統(tǒng)TCP 流公平共存. 在第4 個(gè)實(shí)驗(yàn)室中探索一個(gè)更實(shí)際的場(chǎng)景，即，在瓶頸鏈路中同時(shí)存在攻擊性流量（例如Zoom）和傳統(tǒng)TCP 流量（例如原生Reno）時(shí)，我們測(cè)量QLibra在與這些不同類型的流相處時(shí)的行為.

Fig.15 The throughput when QLibra, Zoom and original Reno competing under 1 000 kbps restricted bandwidth and 10% restricted packet loss rate圖15 QLibra，Zoom 和原生Reno 在1 000 kbps 帶寬限制和10%丟包率限制下競(jìng)爭(zhēng)時(shí)的吞吐量

4）第4 個(gè)實(shí)驗(yàn)測(cè)量了QLibra、Zoom 和原生Reno在不同限制場(chǎng)景下競(jìng)爭(zhēng)時(shí)的吞吐量表現(xiàn). 如圖15 所示，最初QLibra、Zoom 和原生Reno 各占有大約900 kbps的吞吐量.當(dāng)添加1 000 kbps 帶寬限制時(shí)，QLibra 和Zoom 都出現(xiàn)了吞吐量突發(fā)增長(zhǎng). QLibra 占用的平均吞吐量約為540 kbps. 同時(shí)，Zoom 占有470 kbps 的平均吞吐量. 至于原生Reno，它的平均吞吐量只有60 kbps.由于Zoom 的存在，傳統(tǒng)的TCP 流量幾乎被擠死. QLibra目前能做的就是通過與Zoom 搶占帶寬來保證自身的QoE，結(jié)果是QLibra 將自己也保持在高吞吐狀態(tài).當(dāng)增加10%的丟包率限制時(shí)，QLibra 和Zoom 都開始提高發(fā)送速率來抵抗丟包. QLibra 的平均吞吐量達(dá)到了1 130 kbps，而Zoom 的平均吞吐量達(dá)到了1 010 kbps.原生Reno 的平均吞吐量在10%丟包率的影響下有所下降，平均為640 kbps.

通過本節(jié)實(shí)驗(yàn)可以發(fā)現(xiàn)，當(dāng)存在其他攻擊性流量導(dǎo)致的擁塞丟包或鏈路隨機(jī)丟包時(shí)，QLibra 會(huì)提升發(fā)送速率以保證自身的QoE. 當(dāng)瓶頸鏈路中存在的流都是TCP 友好型時(shí)，QLibra 的激進(jìn)發(fā)送行為將導(dǎo)致自擁塞丟包. 這時(shí)QLibra 將回退到傳統(tǒng)的TCP 流來保證公平性. 實(shí)驗(yàn)結(jié)果表明，QLibra 可以實(shí)現(xiàn)比現(xiàn)有視頻應(yīng)用更好的QoE，同時(shí)與其他參與的TCP 流很好地共存.

5 相關(guān)工作

5.1 公平性測(cè)量

先前的研究集中在擁塞控制算法的公平性上，包括協(xié)議內(nèi)公平性（同一算法的2 個(gè)實(shí)例）和協(xié)議間公平性（2 個(gè)不同算法的2 個(gè)實(shí)例）. 對(duì)于協(xié)議內(nèi)公平性，Ha 等人[21]報(bào)告說Cubic 在具有不同RTT 的流量之間實(shí)現(xiàn)了公平的帶寬分配. Hock 等人[22]報(bào)告說BBR沒有明確的機(jī)制可以讓多個(gè)BBR 流量收斂到公平的份額. 對(duì)于協(xié)議間公平性，Ware 等人[23]展示了當(dāng)與多達(dá)16 個(gè)基于丟包的擁塞控制算法競(jìng)爭(zhēng)時(shí)，單個(gè)BBR流量可以消耗40%的鏈路帶寬. Ha 等人[21]報(bào)告說，Cubic 對(duì)Reno 不公平，但這并不顯著影響Reno 的表現(xiàn). Cardwell 等人[24]報(bào)告說BBR 對(duì)Cubic 不公平，他們正在考慮建模小緩存區(qū)的情況. Dong 等人[25]報(bào)告說PCC Vivace 對(duì)Cubic 不公平，但是隨著Cubic 發(fā)送端數(shù)量的增加，PCC Vivace 可以實(shí)現(xiàn)公平性. Arun 等人[26]報(bào)告說Copa 對(duì)Cubic 不公平，但比BBR 和PCC公平得多. 同時(shí)，Copa 充分利用Cubic 不使用的帶寬資源. 還有一些研究討論公平性的度量問題. Ware 等人[3]認(rèn)為基于損害的度量方法比傳統(tǒng)的公平性概念更加實(shí)用、更有前景，并且可以適用于更廣泛的指標(biāo).

關(guān)于視頻應(yīng)用的公平性，Jiang 等人[27]測(cè)量了現(xiàn)有商業(yè)視頻客戶端的表現(xiàn)，并展示了不同商業(yè)解決方案的不公平、低效率和不穩(wěn)定. Akhshabi 等人[28]重點(diǎn)關(guān)注2 個(gè)視頻客戶端間的不公平問題，并依據(jù)視頻應(yīng)用的開關(guān)行為解釋他們的測(cè)量發(fā)現(xiàn). Huang 等人[29]展示了視頻客戶端和持久TCP 流之間的不公平問題，他們歸因于視頻客戶端很難估計(jì)出準(zhǔn)確的可用帶寬. 這些研究都集中關(guān)注傳統(tǒng)的視頻點(diǎn)播應(yīng)用，而不是時(shí)延敏感型應(yīng)用，比如直播和實(shí)時(shí)通信. 此外，Huang[29]等人也沒有分析在不同網(wǎng)絡(luò)場(chǎng)景下視頻應(yīng)用的行為表現(xiàn). MacMillan 等人[30]展示了視頻會(huì)議應(yīng)用定制的擁塞控制算法導(dǎo)致不公平的帶寬分配. 他們還進(jìn)行了Zoom 的2 個(gè)實(shí)例之間的競(jìng)爭(zhēng)實(shí)驗(yàn)，實(shí)驗(yàn)結(jié)果表明2 個(gè)實(shí)例在超過100 s 的時(shí)間內(nèi)都在激烈地?fù)屨紟挘罱K一個(gè)實(shí)例將另一個(gè)實(shí)例擠死. 即使是相同應(yīng)用的不同實(shí)例，仍然存在不公平行為. Sander等人[31]使用Zoom 作為示例研究了視頻會(huì)議擁塞控制算法的公平性問題，并研究了部署主動(dòng)隊(duì)列管理（AQM）機(jī)制的影響. 但是，他們沒有將應(yīng)用的傳輸行為與QoE 指標(biāo)關(guān)聯(lián)分析，來確定這些發(fā)送行為是否真正提高了傳輸質(zhì)量或僅僅是不必要的. 此外，Sander[31]等人希望通過利用諸如FQ_CoDel 之類的AQM 機(jī)制將公平性由網(wǎng)絡(luò)運(yùn)營(yíng)商來控制. 然而，將這種機(jī)制部署在網(wǎng)絡(luò)邊緣的數(shù)百萬個(gè)設(shè)備上缺乏動(dòng)力. QLibra設(shè)計(jì)具有“不傷害自己”的動(dòng)機(jī)，更有可能被視頻應(yīng)用所采用.

有一些研究討論TCP 友好的速率控制（TFRC）.Floyd 等人[8]提出了一種在互聯(lián)網(wǎng)環(huán)境中運(yùn)行的擁塞控制方案，可以做到在中等時(shí)間尺度上與TCP 流量公平競(jìng)爭(zhēng). Yan 等人[32]提出了用于可擴(kuò)展視頻流媒體的TCP 友好速率控制算法，該算法在不同擁塞環(huán)境中的表現(xiàn)優(yōu)于TFRC. 然而，出于自私的原因，目前大多數(shù)視頻服務(wù)都與TFRC 的原則偏離[9].

一些研究提出了QoE 公平性，用來衡量不同用戶觀看體驗(yàn)的相似程度. Nathan 等人[33]使用視頻客戶端狀態(tài)和視頻特征信息來調(diào)整擁塞控制行為以優(yōu)化QoE 公平性. Georgopoulos 等人[34]提出了一個(gè)OpenFlow 輔助的QoE 公平框架，旨在共享網(wǎng)絡(luò)環(huán)境中公平地最大化多個(gè)競(jìng)爭(zhēng)客戶端的QoE. Chen 等人[35]認(rèn)為客戶端和網(wǎng)絡(luò)必須協(xié)同以實(shí)現(xiàn)QoE 公平. Mu 等人[36]引入了一個(gè)用戶級(jí)資源分配模型，該模型可以最大程度地實(shí)現(xiàn)自適應(yīng)流媒體間的QoE 公平性. 李杰等人[37]提出了一種基于資源共享公平概念的多資源公平分配機(jī)制. 盡管這些研究關(guān)注新算法和已部署算法之間的公平性問題，但仍缺少有關(guān)真實(shí)互聯(lián)網(wǎng)公平狀況的研究. 為了解決這個(gè)問題，本文探討了視頻服務(wù)提供商的真實(shí)互聯(lián)網(wǎng)流量是否遵循公平性原則.

5.2 視頻應(yīng)用測(cè)量

一些研究測(cè)量了商業(yè)視頻應(yīng)用，包括視頻點(diǎn)播（VoD）、直播和實(shí)時(shí)通信. Xu 等人[38]對(duì)流行的視頻點(diǎn)播服務(wù)開展了詳細(xì)的測(cè)量研究. Li 等人[39]基于大規(guī)模視頻點(diǎn)播系統(tǒng)中提取的日志研究了移動(dòng)用戶的行為及相應(yīng)的視頻觀看模式. Ghasemi 等人[40]對(duì)雅虎的流媒體服務(wù)進(jìn)行端到端特征的刻畫，并發(fā)現(xiàn)了一系列性能問題. Dimopoulos 等人[41]提出了一種用于檢測(cè)加密視頻流QoE 問題的新方法. Wang 等人[42]對(duì)直播流媒體應(yīng)用Periscope 的設(shè)計(jì)和性能進(jìn)行了詳細(xì)的分析. Siekkinen 等人[43]也探索了Periscope 服務(wù)并提供了一些關(guān)于關(guān)鍵性能指標(biāo)的發(fā)現(xiàn). Chen 等人[44]提出了一種工具用來支持移動(dòng)應(yīng)用QoE 的可重復(fù)測(cè)量和分析. Dimopoulos 等人[45]開發(fā)了一個(gè)框架，用于借助機(jī)器學(xué)習(xí)診斷移動(dòng)視頻QoE 問題的根本原因.Shafiq 等人[46]介紹了移動(dòng)視頻流性能的表征，并從網(wǎng)絡(luò)運(yùn)營(yíng)商的角度對(duì)用戶參與的影響進(jìn)行了建模.Hohlfeld 等人[47]從影響最終用戶體驗(yàn)的角度研究了緩存區(qū)大小選擇的影響. Yu 等人[48]對(duì)3 款流行的移動(dòng)視頻電話應(yīng)用進(jìn)行了測(cè)量研究. Xu 等人[49]針對(duì)3款視頻電話系統(tǒng)開展測(cè)量研究. Jansen 等人[50]在模擬網(wǎng)絡(luò)條件以及實(shí)際的有線和無線網(wǎng)絡(luò)環(huán)境中對(duì)WebRTC進(jìn)行了性能評(píng)估. Chang 等人[51]測(cè)量比較了3 個(gè)主流的視頻會(huì)議系統(tǒng)：Zoom、Webex 和Google Meet.

這些研究針對(duì)一些流行商業(yè)視頻應(yīng)用的關(guān)鍵設(shè)計(jì)和性能開展獨(dú)立測(cè)量，它們沒有考慮當(dāng)多個(gè)應(yīng)用競(jìng)爭(zhēng)網(wǎng)絡(luò)帶寬資源時(shí)出現(xiàn)的公平性問題. 本文提出的機(jī)制可以用來測(cè)量視頻會(huì)議軟件，實(shí)時(shí)直播平臺(tái)和傳統(tǒng)的TCP 流在不同網(wǎng)絡(luò)環(huán)境中的競(jìng)爭(zhēng)行為.

6 討 論

互聯(lián)網(wǎng)作為共享媒介而誕生，必須禁止任何一方濫用. 如果單個(gè)應(yīng)用發(fā)送行為過激，不僅會(huì)導(dǎo)致不公平，還可能出現(xiàn)網(wǎng)絡(luò)版本的公地悲劇[52]. 早期的互聯(lián)網(wǎng)設(shè)計(jì)者已經(jīng)注意到這個(gè)問題，并在擁塞控制方面的持續(xù)研究中建立了堅(jiān)實(shí)的技術(shù)基礎(chǔ)和經(jīng)驗(yàn)教訓(xùn)[53]. 這些經(jīng)驗(yàn)已經(jīng)融入到操作系統(tǒng)提供的套接字接口等底層系統(tǒng)軟件中，使得大多數(shù)應(yīng)用開發(fā)者不需要重新發(fā)明這些算法. 但是，一旦應(yīng)用開發(fā)者獲得了自由，如果他們不從歷史中吸取教訓(xùn)，那將是危險(xiǎn)的.因此為應(yīng)用提供合適的抽象接口很重要. 針對(duì)視頻的場(chǎng)景，定制化的實(shí)時(shí)通信軟件實(shí)現(xiàn)肯定比標(biāo)準(zhǔn)WebRTC 帶來更高的風(fēng)險(xiǎn)，因?yàn)楹笳呤褂肁PI 隱藏了速率控制算法細(xì)節(jié). Zoom 也正從專有實(shí)現(xiàn)切換回WebRTC[54]，希望Web 傳輸和RTC PaaS 等方案可以起到幫助的作用.

以5G 為代表的蜂窩網(wǎng)接入技術(shù)具有10 Gbps 的高吞吐量和約1 ms 的RTT，為VR 和8K 直播等沉浸式應(yīng)用提供技術(shù)支持. 但是，僅靠帶寬增加并不能消除風(fēng)險(xiǎn). 不斷增長(zhǎng)的需求和設(shè)備將更快地填滿增加的容量. 如果接入網(wǎng)容量無法以相同的速度發(fā)展，這很有可能會(huì)將擁塞點(diǎn)移至其他地方，例如骨干網(wǎng)中，進(jìn)而造成更大的危害.

TCP 友好速率控制（TFRC）[8]是一個(gè)不錯(cuò)的設(shè)計(jì)，但是缺乏部署的動(dòng)力. Briscoe 認(rèn)為擁塞控制在某種程度上決定了公共互聯(lián)網(wǎng)上的帶寬分配[55]. 因此，這些分配應(yīng)該是由一些潛在的經(jīng)濟(jì)模型驅(qū)動(dòng)的，而流量公平性沒有這樣的模型基礎(chǔ). 也就是說，流量不是互聯(lián)網(wǎng)上的經(jīng)濟(jì)參與者，因此沒有理由平等地對(duì)待它們. 尋找一種符合當(dāng)前互聯(lián)網(wǎng)經(jīng)濟(jì)模型的帶寬分配方式是一個(gè)很有前景的方向. 根據(jù)我們的測(cè)量研究，通過避免對(duì)發(fā)送者自身有害的發(fā)送行為（即自擁塞）可以有效地在QoE 和公平性之間保持平衡.QLibra 的設(shè)計(jì)中含有“不傷害自己”的激勵(lì)機(jī)制，這符合視頻應(yīng)用的部署動(dòng)機(jī).

7 結(jié) 論

視頻流量的顯著增長(zhǎng)使得人們了解它們的公平屬性非常重要. 我們對(duì)典型視頻應(yīng)用Zoom 進(jìn)行了廣泛的測(cè)量研究，并揭示了它如何在不同的網(wǎng)絡(luò)條件下尋求更好的QoE. 我們發(fā)現(xiàn)它的某些行為偏離了公平性原則，尤其是當(dāng)鏈路質(zhì)量惡化時(shí)通過發(fā)送冗余數(shù)據(jù)包來餓死其他參與的TCP 流. 這些冒險(xiǎn)行為源于應(yīng)用QoE 目標(biāo)與公平性原則不能很好地平衡. 因此，本文提出QLibra 來解決這個(gè)問題，通過適應(yīng)不同的擁塞信號(hào)來平衡QoE 和公平性目標(biāo). 實(shí)驗(yàn)證明QLibra可以比現(xiàn)有視頻應(yīng)用獲得更好的QoE，同時(shí)對(duì)其他參與的TCP 流無害. 為了長(zhǎng)期利益，負(fù)責(zé)任的視頻應(yīng)用應(yīng)該積極部署類似QLibra 的方案.

作者貢獻(xiàn)聲明：王子逸負(fù)責(zé)提出關(guān)鍵算法，設(shè)計(jì)實(shí)驗(yàn)方案并撰寫論文；胡曉宇負(fù)責(zé)完成實(shí)驗(yàn)并采集分析數(shù)據(jù)；王歆負(fù)責(zé)指導(dǎo)實(shí)驗(yàn)設(shè)計(jì)、實(shí)現(xiàn)及結(jié)果分析；張行功負(fù)責(zé)指導(dǎo)關(guān)鍵算法的設(shè)計(jì)；曹振、鄭凱負(fù)責(zé)論文修改與結(jié)構(gòu)設(shè)計(jì)；崔勇負(fù)責(zé)指導(dǎo)論文算法和實(shí)驗(yàn)的設(shè)計(jì)并參與論文修改.