問題背景：
基於移動智能終端多網絡接口的多路徑傳輸技術，實現聚合底層不同網絡接口帶寬資源的目的，以緩解實時流媒體服務對高帶寬的需求。目前帶寬資源是實現高質量服務的網絡瓶頸。智能終端設備通常同時具有Wifi和LTE兩個網絡接口，Mate10 支持多LTE網絡接口。多路徑專指通過智能終端多個網絡接口建立不同網絡連接接入到互聯網中同一服務，從而利用不同網絡接口網絡資源的實現方式。不同移動網絡在帶寬抖動、時延等方而異質性嚴重的特點。過程：將上層應用的數據，通過多個Ｎ絡接口傳輸到服務端，再由服務端對多個網絡接口傳輸的數據實現重組。所以必須合理的分配上層應用數據給不同網絡接口的子流傳輸。所以主要就是應對網絡異質性對帶寬聚合效率影響。可交互式的流媒體服務成爲主題（直播），所以時延需要滿足要求，需要最小化端到端時延，通過需要儘可能提高視頻質量（更高的視頻數據碼率，進而需要更高的帶寬）。
問題：
1，不同網絡接口的時延差異性使得多路徑傳輸技術帶寬聚合效率不高；
2，高視頻質量與低時延之間衝突，需要在滿足時延約束的基礎上儘可能提高視頻質量
相關技術：
多路徑傳輸技術的使用需要有基於多網絡接口的多路徑傳輸協議棧支持：SCTP，MPTCP，MPQUIC主要的優化策略是優化數據分配策略。
1，SCTP：可靠的傳輸層協議，SCTP連接當中可以包含多條不同的傳輸數據通路。當終端主機多個網絡接口具有不同的IP地址時，可以與之建立多條數據通路，這些數據通路的源目端IP地址分別對應端口的IP地址。SCTP在建立多條數據通路之後會將其中一條數據通路定爲首選數據通路進行數據通信，首選數據通路發生異常時會選擇備選路徑。SCTP是一個面向消息塊的協議，發送端發送的數據塊會被接收端相應的接受。SCTP在連接層面利用TSN保證數據的可靠傳輸，而在流層面利用SSN保證數據的有序傳輸。
2，MPTCP：基於TCP的多路徑傳輸協議，在傳統TCP協議棧之上添加了一層MPTCP層來管理調度建立於多個不同網絡接口上的TCP子流，從而實現多路徑傳輸。MPTCP層是實現在內核中，系統是否使用MPTCP協議棧對應用完全透明，其會維持個與TCP協議類似的套接字，兩者編程是一致的。只有當客戶端系統和服務端系統都同時啓用了MPTCP協議棧時，客戶端和服務端纔可以通過MPTCP協議實現通信。職責：MPTCP層面一方面需要負責數據包的分配調度，將數據包分配給合適的子流傳輸到接收端，另一方面需要負責數據包的重組，將從各個TCP子流接收到的數據包按照MPTCP層面的數據序號重組並有序提交給上層應用。MPTCP的各個子流之間並非完全解耦，發送端維持發送窗口，接收端維持接收緩存隊列，兩者同時對標數據包序號以此來保證數據包按序傳輸。數據分配策略爲minRTT，根據當前各個子流RTT的大小進行排序，優先選擇從RTT最小的子流發送數據包，當RTT最小的子流不可用時，再選擇從RTT次小的子流順序發送數據包。MPTCP要求通訊雙方一方存在多網絡接口即可。
3，MPQUIC：基於QUIC。QUIC是基於UDP的可靠傳輸層協議，利用QUIC協議特有的Packet Num確認機制實現了可靠傳輸。其把TLS加密的過程直接嵌入到了QUIC協議棧當中。QUIC協議支持單QUIC連接內部多條數據流。MPQUIC在QUIC協議的基礎上加入了多徑的功能，實現方式與MPTCP的實現方式類似。
目前有三種常見的視頻電話和視頻會議服務架構：客戶端服務器的服務架構模式；P2P服務架構模式；雲視頻服務架構模式。主要的優化分爲收流側的優化和推流側的優化。如下圖所示三個架構的對比圖。
下面就是這篇說是論文的重點。
-----------------------------------------------------------------------------------------------------------------------------------------------
多路徑傳輸帶寬聚合效率優化
1，核心即爲數據分配策略
2，各網絡接口的帶寬大小、時延、丟包率及網絡抖動等特性都不相同。各個網絡接口之間也並非完全解耦，若數據包被隨意分配，將影響整體的帶寬聚合效率。
3，網絡時延差異性是不同網絡接口網絡異質性對帶寬聚合效果影響的核心體現
4，所設計的多路徑傳輸數據分配策略應儘可能減少這種亂序現象的發生，接收端需要提高接收緩存才能解決剛纔的接收緩存不足無以應對數據包亂序的問題。該文設計的算法是優先選擇快速路徑進行發送，如果快速路徑正忙活着沒有空閒則選擇慢速路徑發送稍後些序號的數據包，此處是發送RTTs/2時間內從快速路徑發送到達接收端的數據包。算法如下
-----------------------------------------------------------------------------------------------------------------
實時流媒體推流端QOE優化
1，推流端對整體QOE的影響主要集中於視頻數據碼率以及端到端時延兩個方面
2，推流端的推流碼率（可連續變化）決定了收流端能夠獲取的最高視頻碼率。
3，推流端延遲包括排隊延遲和傳輸延遲，排隊時延佔主要部分
4，推端編碼器的編碼參數中可以指定編碼的數據碼率
5，爲了減小碼率抖動，碼率調節策略的探測機制不能夠太過激進
6，推流端時延由編碼器產生的時延、源端數據包排隊的時延以及網絡中傳輸的時延三大部分構成。
7，一方面通過控制源端發送緩存中排隊數據量大小以使得排隊時延加上測得的網絡傳輸時延滿足推流端的時延約束；另一方面，在推流端時延小於時延約束時，推流端應該儘可能増大其推流碼率適配當前可用帶寬資源以獲取更高的視頻質量，最大化其推流碼率帶來的QOE。
算法如下，先根據當前網絡信息預計吞吐量c_t，根據其與延遲約束計算得到targetBuffer，b_t（packetBuffer，即客戶端的本地排隊緩存）與targetBuffer對比，如果b_t大則說明超載，則需要降低畫質；如果b_t小，則說明可以提高碼率。補充一點，爲了減少抖動，需要避免碼率調節的幅度過大。這篇文章裏，增大碼率和降低碼率是通過α，β來控制的，這兩個數值是通過實驗控制得到的參數。
反思： 這篇論文前半部分介紹的不錯，但後半部分對於某些細節之處存在爭論，特別是碼率調節那塊，對於瓶頸帶寬那部分一系列公式似乎有些前後矛盾。對於將約束轉換爲buffer大小的對比，爲什麼不直接將碼率與瓶頸帶寬對比呢。
知識點：瓶頸鍊路約束了整條鏈路數據包傳輸的整體時間，即使水管再大，流出水的時間仍是由末端的水龍頭決定的。具體參考如下題目：50M的數據從左端向右端傳輸，末端出現瓶頸鍊路，求50M數據傳輸到終點的時間。答案是50 / 10 + 0.5s + 0.8s = 6.3s。
題目進一步拓展，看如下題目，存在兩個數據源。仍然求50M的數據發完需要多久。答案是 6.3s + （60 / 10 - 0.2s）= 12.1s。之所以減去0.2s是因爲60M的數據比50M的數據早到0.2s，所以對於這0.2s不在50M的排隊時間內。需要注意的是50M數據與60M數據是交錯排隊的，但我們求的是50M數據全部發完，所以不需要在意交錯。
