基于MPTCP的多路徑傳輸優化技術綜述

薛開平陳 珂倪 丹張 泓洪佩琳

1(中國科學技術大學電子工程與信息科學系 合肥 230027)2(中國科學院無線光電通信重點實驗室(中國科學技術大學) 合肥 230027) (kpxue@ustc.edu.cn)

?

基于MPTCP的多路徑傳輸優化技術綜述

薛開平1,2陳 珂1,2倪 丹1張 泓1洪佩琳1,2

1(中國科學技術大學電子工程與信息科學系 合肥 230027)2(中國科學院無線光電通信重點實驗室(中國科學技術大學) 合肥 230027) (kpxue@ustc.edu.cn)

新型網絡環境致力于為用戶提供廣覆蓋、高帶寬、包含各種多媒體業務的服務，而多種接入技術并存的網絡環境為無處不在的高質量服務提供了可能.為了適應異構環境，用戶終端通常配置多個接口(比如WIFI和4G)，通信終端之間可能存在多條路徑.多徑TCP協議(multipath TCP， MPTCP)是IETF MPTCP工作組提出的新型傳輸層多徑協議,它在兼容TCP協議的基礎上，同時利用多條路徑的傳輸能力來進行數據傳輸，提高帶寬利用率，增強連接的恢復能力，并且能夠自適應地將數據從擁塞路徑轉移到非擁塞路徑.近年來國內外機構先后作出了大量的研究，逐步使得MPTCP由概念走向實用.總結和闡述了MPTCP相關方面的研究現狀，其中包括仿真實現與實際部署、亂序控制、聯合擁塞控制、能耗管理、安全以及關于路徑選擇、移動性和QoS、數據中心中的應用等其他方面的研究.最后給出總結和展望.

多路徑；多徑TCP協議；調度算法；擁塞控制；能耗管理；安全

多路徑傳輸技術旨在研究多宿終端之間如何同時使用多條路徑進行數據傳輸，從而實現帶寬聚合、負載均衡、動態切換以及自動將業務從最擁塞、最易中斷的路徑上轉移到較好的路徑上的功能.

多路徑傳輸將應用層的業務數據流分發到多條路徑并行傳輸，而多路徑的傳輸控制功能可以在終端協議棧的任意層次進行實現，目前已經存在很多研究在不同層次考慮多路徑傳輸的實現[1-4].為了保證對應用層的透明性，同時由于在TCPIP協議棧中傳輸層是最低的端到端層次，可以獲取所用路徑帶寬、延遲、丟包等信息，并且能夠通過擁塞控制算法對網絡中的擁塞事件作出快速反應，故而傳輸層多路徑方案一直是多徑傳輸技術研究中的重點.

Internet工程任務組(Internet Engineering Task Force， IETF)于2000年提出一種傳輸層多徑協議SCTP(stream control transmission protocol)，它是獨立于TCP和UDP協議的傳輸層協議.標準SCTP協議[5]中定義，一個SCTP連接可以使用多個IP地址，但是只有主路徑用于數據傳輸，其他路徑作為冗余備份，在主路徑失效時才啟用.之后的研究又提出了LS-SCTP(load sharing for SCTP)[6]和CMT-SCTP(concurrent multipath transmission for SCTP)[7]，對標準SCTP協議進行擴展以支持多徑并行傳輸.然而，SCTP協議至今沒有大規模部署，究其原因是其與現有的應用程序不兼容，通信雙方的應用都必須調用SCTP接口才能使用SCTP協議傳輸.

鑒于當前Internet中大部分重要的應用程序都基于TCP， Huitema[8]早在1995年就提出基于TCP的多路徑傳輸控制思想，IETF在2009年專門成立了多徑TCP協議(multipath TCP, MPTCP)工作組[9]，旨在研究在現有TCP會話基礎上增加多徑傳輸的功能，包括相應的體系結構、擁塞控制、路由、API、安全等.要求MPTCP與現有的網絡架構和協議兼容，對應用層提供的仍然是傳統TCP套接字，應用程序在不做任何更改的情況下也能使用，從而保證對應用層的透明性，并且在終端不支持MPTCP時可以回退到TCP.

MPTCP從根本上改變了數據的調度和傳輸方式，通過同時建立多條傳輸路徑，將數據的傳輸方式由傳統的單徑變成了多徑，有效地提升了網絡的傳輸能力和穩定性，具有非常重要的意義.

1 MPTCP協議技術細節

MPTCP利用多條路徑進行端到端傳輸，通信雙方必須同時支持MPTCP協議，并且至少一端具有多個IP地址，實現多路徑的分離.當前IETF MPTCP 工作組制定的標準(RFC)一覽如表 1所示，工作組主要討論的內容包括MPTCP的協議細節[10-11]，聯合擁塞控制[12-14]、安全問題[15-16]、應用層接口[17]、MPTCP代理[18]等.

Table 1 The List of IETF MPTCP RFCs

MPTCP的協議棧如圖1所示，傳輸層的TCP劃分為2部分:MPTCP層和TCP層(也叫子流層).MPTCP層對于應用層是透明的，應用層看見的仍然是傳統TCP.MPTCP層實現路徑管理、數據包調度、擁塞控制等功能，并與子流層有接口，而子流層使用標準TCP協議.

Fig. 1 MPTCP protocol stack.圖1 MPTCP協議棧

1.1 MPTCP頭標和基本操作

為保證MPTCP與TCP的兼容性，MPTCP利用TCP頭部區域攜帶MPTCP的選項，如圖2所示.MPTCP選項中的Kind域指明該選項是一個MPTCP選項，而Subtype域則指明該選項是MPTCP中的何種選項(比如MP_CAPABLE，MP_JOIN，DSS，ADD_ADDR等).

接下來我們給出MPTCP中的基本操作以及相應的簡要描述，如表2所示，具體描述請參考RFC 6824[10].

Fig. 2 The position of MPTCP header option in TCP.圖2 MPTCP頭標選項在TCP中的位置

Table 2 Basic Operations of MPTCP

1.2 MPTCP功能綜述和設計原則

MPTCP層在協議棧中位于應用層之下和TCP層之上，為應用層提供標準的TCP接口來隱藏多徑，同時需要管理多條TCP子流.MPTCP層具備路徑管理、數據包調度、子流接口及擁塞控制的功能，總結這4點如下：

1) 路徑管理.路徑管理功能負責檢測和使用2個主機之間的多條路徑.MPTCP的路徑管理機制要求把本機可用的地址發送給對端主機，而且可以建立新子流并加進已有的MPTCP連接中.

2) 數據包調度.此功能要求把從應用程序接收到的字節流(stream)切割成分段，后續由子流進行傳輸.MPTCP設計了序列號映射機制，每條子流上發送的數據包都對應有一個連接級別的序列號，從而保證接收端可以正確重組從不同子流上接收到的數據包.數據包調度功能依賴于路徑管理功能所提供的可用路徑信息.

3) 子流(采用單獨路徑TCP)接口.子流功能從數據包調度功能中取得分段，在特定的路徑上確保到主機可檢測的傳送.MPTCP考慮了網絡兼容性，在下層使用TCP，確保有序可靠的傳送.TCP在子流層給每個數據包添加子流序列號，用于實現子流級別的檢測和重傳丟包.在接收端，每條TCP子流在按序重組本子流的數據包后遞交給數據包調度模塊，繼而進行連接級別的數據包按序重組.

4) 擁塞控制.用于在多個子流之間協調窗口，從而實現擁塞控制功能.MPTCP設計了聯合擁塞控制算法[12]，保證在共享瓶頸處一個MPTCP連接與傳統單徑TCP相比不會占用過多的帶寬，從而實現公平性.

總之，這些功能彼此配合、相互協作.路徑管理功能獲取兩通信主機間的可用路徑；數據包調度功能獲取應用數據流后需要進行一定的操作，比如分割數據段、添加連接級別的序列號，而后將數據包分發至各條TCP子流；子流再添加子流級別的序列號和ACK到每個數據包，接收端子流將數據包按序交付給數據包調度功能進行進一步的連接級別數據包的按序重組；擁塞控制功能是數據包調度功能的一部分，它決定了哪些數據包以何種速率在哪條子流上進行發送.

MPTCP設計原則和優化目標可歸納為5點：

1) 提升吞吐量.一個MPTCP連接的總吞吐量不應小于其最好路徑上的單條TCP連接的吞吐量.

2) 公平性.與只使用其中的一個路徑時相比，MPTCP連接不能占用過多的資源.

3) 均衡擁塞.在滿足前2項的前提下，多徑流應該盡可能多地從最擁塞的路徑上轉移走一些業務.

4) 安全性.MPTCP要求其所具有的安全性不差于單個TCP連接.

5) 恢復力.在最壞情況下，MPTCP的恢復力必須不低于常規的單路徑TCP.

2 仿真實現與實際部署

倫敦大學學院(University College London， UCL)的網絡研究組開發了最早用于MPTCP方案驗證和性能仿真的仿真器htsim[19].Google公司負責開發和維護了目前最有影響力和知名度的NS3(network simulator)仿真環境下的MPTCP模塊[20]，該模塊基本實現了在一個MPTCP連接下多TCP子流并行傳輸的功能.雖然代碼并沒有嚴格按照MPTCP協議所規定的進行設計，但不影響將其作為仿真工具進行方案的性能評估.另一個用于NS3的MPTCP模塊由Sussex大學(University of Sussex)的Kheirkhah等人[21-22]提供.

UCL網絡研究組和以及來自比利時魯汶天主教大學(Université catholique de Louvain, UCLouvain)的IP網絡實驗室分別提供了MPTCP的Linux內核開源代碼[19,23]，并在內核代碼的基礎上進行了MPTCP性能的測試[24-27]，從擁塞窗口調整、數據中心支持、移動性支持、能耗考慮等多個方面對基本的MPTCP協議提出一系列機制改進.另外一個重要的開源實現是以補丁的形式由Apple公司的研究組所提供的[28]，并用于IOS和MacOS當中.這3個研究組以及前面提及的來自Google公司的研究組也是IETF MPTCP工作組的主要參與者.

圖3是內核代碼框架示意圖[23].從圖3可以看到，應用層調用的是傳統TCP套接字(socket)，而在建立了MPTCP連接后調用多徑控制模塊(multipath control block)，該模塊也就是所說的MPTCP層.初始的TCP 套接字為主套接字，之后新建立的TCP 套接字為從TCP 套接字.無論主TCP 套接字上的子流關閉與否，主TCP套接字一直存在，用于向上層應用隱藏MPTCP的存在，從而實現透明化.在具體實現[25,29]上，如圖4所示，首先每個子流的處理都通過一個tcp_sock來加以實現，除此之外，該tcp_sock還包含一個指向mptcp_tcp_sock的指針，用以維護TCP之外與MPTCP有關的信息以及處理MPTCP層的相關功能.MPTCP連接所產生的第1個子流的tcp_sock記為meta_sock，供應用層調用的為標準的TCP socket api.作為meta_sock的tcp_sock除了包含指向mptcp_tcp_sock的指針之外，還將通過指針連接到一個新添加的mptcp_cb，該結構體作為MPTCP的控制緩存，其中維護了到各個TCP 子流的tcp_sock的指針以及地址列表信息等.各個子流的mptcp_tcp_sock也需要將相關標識信息等存儲在mptcp_cb.

Fig. 3 Structure of MPTCP kernel code.圖3 MPTCP內核代碼框架

Fig. 4 Relationship and function description of structures in Linux implementation.圖4 Linux內核實現中結構體相互關系及功能

NS3中MPTCP模塊[20]中類的實現主要包含4個部分：

1) MpTcpSocketlmph.MpTcpSocketlmph是類TcpSocketlmpl的子類，它給應用層提供MPTCP API(connet，bind等)處理多路連接和包重排序.

2) MpTcpL4Protocol.MpTcpL4Protocol是類TcpL4Protocol的子類，是多路傳輸層和網絡層之間的接口.

3) MpTcpSubflow.MpTcpSubflow提供MPTCP連接的子路徑.

4) MpTcpHeader.MpTcpHeader是TcpHeader的子類，提供了MPTCP的頭選項等.

目前，除了Linux系統內核支持的開發之外，研究者和開發者還在Android系統進行了大量的嘗試，可以用于Google Nexus，Samsung Galaxy系列等[30].Apple IOS，MacOS以及數據中心Amazon EC2[31-32]也應用了MPTCP.除此之外，斯威本科技大學(Swinburne University of Technology， SWIN)先進互聯網架構中心(Centre for Advanced Internet Architectures)開發了用于FreeBSD10.x的MPTCP代碼[33].

目前的趨勢是：隨著MPTCP受到學術界和業界的重視，越來越多的研究者和開發者投入MPTCP相關功能的實現當中，日趨呈現百家爭鳴之勢.

3 亂序控制

MPTCP與任何傳統多徑傳輸協議一樣面臨數據包亂序問題的重大挑戰.大多數多徑并行傳輸協議的初衷是為了聚合各路徑帶寬，提升數據傳輸吞吐量.然而多條路徑將引入更為復雜的參數維度，亦對發送端的多徑控制能力提出更高的要求.

以往的研究[26,34]表明MPTCP吞吐量受到通信雙方間各條端到端路徑的時延、丟包率、帶寬等參數差異以及共享接收緩存大小的限制.隨著各路徑差異越大，共享接收緩存越小，MPTCP吞吐量性能急劇惡化，有時甚至比不上最好路徑上使用傳統TCP協議進行單徑傳輸的吞吐量.導致這一現象的主要原因是路徑差異導致接收端數據包亂序，而在接收緩存過小無法容納大量亂序包時性能將進一步惡化.接收端亂序會造成2方面的影響：

1) MPTCP多路徑共享一個接收緩存，接收端亂序導致接收緩存阻塞.

2) 限制路徑擁塞窗口滑動和增長，路徑傳輸速率偏低.

這2方面因素引起MPTCP各路徑擁塞控制窗口增長相互制約，嚴重影響吞吐量提升.針對亂序導致的頭阻塞問題，為了盡可能保證數據按序達到，現有方案主要包括發送端調度策略和MPTCP與網絡編碼相結合的方案.

3.1 MPTCP發送端調度算法

MPTCP的發送端調度算法可以解決路徑不對稱造成的接收端數據包亂序問題，盡力保證數據包按序到達接收端.下面介紹MPTCP相關研究中提出的調度機制[25,27,34-40].

輪詢算法(round-robin， RR)[25]是最簡單的調度算法.MPTCP連接的各個子流沒有優先級，發送端輪詢各個子流，發送緩存的數據按照輪詢的順序填滿各子流的發送窗口進行發送.此時，只是在多子流間簡單地調配數據包，數據的按序性無法保證.

最小RTT優先輪詢算法(lowest RTT first RR)[27]在輪詢算法的基礎上進行了一定的深化.MPTCP連接的各個子流按照RTT排列優先級，RTT越小優先級越高.發送端按照優先級高低輪詢各個子流，依次取發送緩存的數據包填滿各個子流的發送窗口.該算法讓路徑質量好的子流承載更多的數據包，有一定的負載均衡的效果.無論是輪詢算法還是最小RTT優先輪詢算法都沒有考慮數據包的按序性，沒有從數據包序列號角度出發.

Fig. 5 Scenario example of the Linux-MPTCP scheduling algorithm.圖5 Linux-MPTCP調度算法適用的場景示例

Linux-MPTCP調度算法[25]是Linux-MPTCP內核代碼支持的一種預測調度算法.以圖5為例說明該算法的思想:一個MPTCP連接上的數據需要調度到2個TCP子流(subflowi和subflowj)上發送.假設調度時刻2條子流的擁塞窗口均為2,2條子流的RTT值存在RTTj=5RTTi的關系，也就是說，subflowi上發送5輪數據所需的時間與subflowj上發送1輪數據包所需時間相同.發送一輪是指擁塞窗口(cwnd)內的第1個數據包從發送開始直到接收到該數據包的ACK，發送一輪的時間相當于一個RTT.如果使用RR算法，subflowi取數據包1，2，subflowj則取數據包3，4，那么，subflowi上數據包1，2的ACK回來后，接著取數據包5，6，數據包5，6將早于數據包3，4到達接收端，亂序的數據包需要緩存，且subflowi后續幾輪的數據包仍將早于數據包3，4到達接收端.Linux-MPTCP調度算法在調度時刻subflowj不取數據包3，4而是取數據包11，12.subflowi上發送5輪數據包，窗口大小為2，一共可以發送10個包，subflowj則將發送緩存中的前10個包都預留給subflowi后續發送.這樣一來，數據包1～12將能基本按序依次到達接收端.不過該算法過于簡略，沒有考慮擁塞窗口在這5輪發送過程中會按照擁塞控制算法變化.

前向預測調度(forward prediction scheduling, FPS)[34-35]是Linux-MPTCP調度算法的改進版本，想法來源于Westwood SCTP算法[41]，更精細地考慮了序列號的預測調度算法.假設一共有I條子流，對于pathi而言，其往返時延為RTTi，數據包從離開發送端到到達接收端的時延為FTi(≈RTTi/2)，擁塞窗口大小為si.為了簡化處理，數據包大小都設為TCP最大分段長度MSS(maximum segment size)，故而subflowi上每一個數據包的排隊時延εi是確定的：

(1)

在時刻t，subflowi發送si個數據包，那么這些數據包到達接收端的時刻分別為

t+FTi+εi,t+FTi+2εi,…,t+FTi+siεi，

而發送端接收到這些數據包的ACK的時刻分別為

t+RTTi+εi,t+RTTi+2εi,…,t+RTTi+siεi.

發送端接收到數據包成功接收的確認消息后擁塞窗口si會按照擁塞控制算法增加，新一輪數據在時刻t+RTTi+siεi發送.

Fig. 6 Transmission sequence diagram of two subflows in FPS.圖6 FPS算法中2條子流數據包傳輸時序圖

以圖6為例說明FPS算法.MPTCP連接的數據通過pathi和pathj這2條路徑傳輸，2條路徑往返時延滿足RTTj>RTTi.在時刻t，路徑pathj上發送窗口產生滑動，從而準備發送新數據.由于pathi傳輸數據快于pathj，pathj上發送的數據包需要經過調度.發送端首先估計pathj上數據包到達接收端的時刻為t′，然后計算在時刻t′之前pathi上可以發送的數據包總數.假設nl是從時刻tl(tl

(2)

其中，nl必須滿足：

(3)

如果tl+FTi+εi>t′，那么該輪傳輸的所有數據包均在t′之后到達，此時nl=0，最后計算t′之前可以傳輸的數據包總數為

(4)

其中，N就是在t′之前在pathi上成功發送的數據包總數.那么，發送端調度發送緩存的前N個包給pathi，pathj跳過發送緩存前N個數據包從第N+1個開始取來填滿自己的發送窗口.pathi上每接收到一個數據包成功接收的確認消息，RTTi平滑更新：

(5)

其中,rtti是新測量得到的往返時延;α是0～1之間的值，指明歷史RTTi和新測量rtti的權重關系.單程時延FTi按式(6)簡單估計：

(6)

由于在無線鏈路環境中隨機丟包事件不可避免，不考慮丟包的前向預測機制顯然已經不再適用.在FPS[34-35]基礎上，F2P-DPS(fine-grained forward prediction based dynamic packet scheduling)[36]充分考慮了子流的TCP特性以及路徑的丟包率，使用TCP建模的方法，發送端根據子流上平滑得到的RTT和統計得到的丟包率估計未來一段時間內該子流可能發送的數據量N.所采用的方法是，根據子流上給出的初始條件，以subflowi為例，初始窗口大小a以及路徑參數(pi,RTTi)， 對[t,t′]內subflowi上所有可能的數據包傳輸事件計算統計平均，最終該統計平均值即為N.

但從根本上講，FPS和F2P-DPS都只是預測算法，可能與實際情況有差距.為了防止多輪調度之后的誤差累計,進一步在F2P-DPS的基礎上，一種基于TCP SACK反饋的調度算法OCPS(offset compensation based packet scheduling)[37]被提出.方案中在子流級別使用TCP SACK返回當前接收端亂序情況,發送端根據TCP SACK攜帶的信息來判斷上一輪調度時預留給其他子流的數據包是過多還是過少，從而使用修正因子對下一輪的預留數據包總數進行修正.OCPS在路徑質量存在一定擾動的情況下有良好的適應能力.

借鑒單路徑中引入網絡編碼帶來的好處，大量研究者嘗試在多路徑TCP中也引入網絡編碼，一方面可以解決無線場景下由于無線隨機丟包帶來的問題[42-43]，另一方面可以簡化多路徑TCP各子流之間的調度問題[44-46].

以圖7和圖8為例進行說明，假定所有的丟包都是由于無線隨機丟包造成的.在圖7中，子流S0與子流S1均非編碼數據流，子流0傳輸D3，D4，D6，子流1傳輸D1，D2，D5，傳輸過程中假定子流S0上存在無線隨機丟包，D3由于無線傳輸錯誤而無法正常接收，則將會出現2個問題:1)子流S0傳輸的D4首先到達接收端，由于小序列號數據段未到達，則D4只能暫時緩存在接收緩存中，不可以提交；2)當發生丟包后，接收端需要顯式地發回反饋消息后發送端才會重新發送分組，這不僅通報了假的擁塞信息，同時較長的丟包通報延時再一次加重了連接級別的亂序.如圖7所示，當D4到達時，接收端反饋D3丟失了，D4不得不被緩存在接收緩存中等待小序列號數據段D1，D2，D3的到達.

Fig. 7 An example of MPTCP transmission.圖7 MPTCP傳輸示例

Fig. 8 An example of MPTCP subflow layer coded transmission.圖8 MPTCP子流級別編碼傳輸示例

與此不同的是，在圖8中，由于采取了編碼機制，按照TCP網絡編碼的原則，接收端并不以完全解碼出原始數據段作為成功接收的標準，只要接收端在編碼的分組中可以看到數據段，則認為已經接收到數據段，通過這種方式，使得2條子流不需要嚴格遵循序列號順序.①發送端會發出冗余的分組，在不需要進行顯示反饋的情況下，丟失的分組就可以被恢復，進一步縮短接收緩存被占用的時間;②無論是編碼子流還是非編碼子流，只要到達的編碼分組滿足2個條件，則發回成功接收的確認消息，避免造成擁塞誤判：

1) 編碼分組線性獨立于其他收到的編碼分組；

2) 最新收到的編碼分組中包含有接收端期望的序列號信息，或者可以借助新接收的編碼分組從解碼緩存中推導出接收端期望的序列號信息.

從編碼內容上，多路徑TCP網絡編碼的方式主要可以分為子流級別編碼[42-43]以及連接級別編碼[44-46].子流級別編碼對多路徑TCP協議的改進較小，兼容性更好.子流級別編碼和連接級別編碼的主要不同之處在于：執行數據在不同子流的分配調度與執行編碼的先后順序.若先執行數據段調度，再執行編碼，則為子流級別編碼；否則為連接級別編碼.

從傳輸形式上看，可以分為編碼子流與非編碼子流[43].在圖8中，子流0是編碼子流，而子流1是非編碼子流.

多路徑TCP網絡編碼的確認機制尚未統一，可以分為子流級別確認機制和連接級別確認機制.子流級別編碼采用子流級別的確認機制[42-43]，連接級別編碼可以采用子流級別確認[44]或者連接級別的確認機制.子流級別確認機制與多路徑TCP協議后向兼容性好，所有的丟包均在子流級別進行分析，以子流級別序列號信息作為反饋依據，反饋信息通報的丟包和延時變化均是該路徑上的情況，便于做出擁塞判決.連接級別反饋僅適用于連接級別編碼，以連接級別序列號信息作為反饋依據，不需要在連接級別和子流級別做映射，但是其不足之處在于，通過序列號信息可以獲得丟包信息，由于不再與子流信息相關，無法準確判定丟包發生在哪一條路徑上.在圖8中，若反饋的序列號信息為SSN:PX，則是子流的反饋；若為DSN:DX，則為連接級別的反饋.

3.3 其他可行的方案

除了以上提到的這2類方案可以用于解決包亂序的問題之外，MPTCP內核部署研究[26,34]中還提到了4種簡單的改進機制：

機制1. 在最快路徑上重傳阻塞數據包.當發生接收緩存阻塞時，將未到達接收端的序列號最小的數據包在最快路徑上重傳.最快路徑是RTT最小的路徑.

機制2. 懲罰阻塞接收窗口滑動的子流.發送端判斷阻塞接收緩存的子流，也即未到達接收端的序列號最小的數據包所在子流，并對該子流的擁塞窗口減半懲罰操作.不過為了防止總是懲罰某一條子流，在一個往返時延內同一條子流只能懲罰1次.

機制3和機制4. MPTCP的發送和接收緩存支持自動調整，在需要時才增大緩存，這樣可以防止直接設置大緩存造成的空間浪費.當接收緩存中所存儲的亂序數據包的數目超過1個BDP(BDP的計算值為Bandwidth×Delay)大小時，對擁塞窗口設置上限.MPTCP中具體的部署方式是：當sRTT(smoothed RTT)超過了2倍的基準RTT時就為擁塞窗口設置上限，基準RTT為所有子流中的最小RTT值.機制3與機制4在sRTT的測量方式上有所不同.機制3使用數據包timestamp選項所記錄的發送與接收時間來測量sRTT值，而機制4使用子流接收一個接收窗口大小的數據所需要的實際時間來估算sRTT值.

3.4 亂序控制小結

MPTCP接收端數據包亂序現象將直接導致接收端緩存阻塞，并進一步阻止發送端的擁塞窗口向前滑動.現有處理方案主要集中在3個方面：1)依據MPTCP各子流特性為其預分配數據包，使得不同子流所交付的數據包保持基本有序；2)使用網絡編碼的方式掩蓋上層數據包丟失狀況，發送冗余的編碼數據包以保證接收端數據包有序解碼；3)調整快速重傳策略以迅速向接收端交付造成緩存阻塞的數據包，使得接收端數據有序.目前尚無切實可行的方案可以完全應對亂序問題，以上方案的設計也只是處于初步階段，這與MPTCP歸根結底依然屬于端到端協議存在一定關系，網絡狀態是實變的，源端只能根據反饋信息估計出當前的網絡狀況，因而具有一定的滯后性，這也就給方案的有效執行帶來了難度.所設計方案往往很難從根本上解決問題，但力求可以更加準確地做到這一點，將亂序問題的影響降到最低.

4 聯合擁塞控制算法

MPTCP的每條TCP子流可以使用標準的TCP擁塞控制算法，而聯合擁塞控制算法是MPTCP研究的一大熱點.沿襲單路徑TCP擁塞控制的思想，多路徑TCP擁塞控制機制可以分為2類：1)以丟包作為擁塞發生的標志；2)以延時變化評估當前是否發生擁塞.

4.1 基于丟包判據的擁塞控制算法

在MPTCP提出之前，采用的方法是一個連接的多個子流共享同一個擁塞窗口，比如E-TCP[47]，CM[48]，MPAT[49].在這些方案中，窗口調整都采用了基本的AIMD(additive increasemultiplicative decrease)方式[50]：如果在一個RTT中沒有發生丟包，擁塞窗口就增加1；如果共享此擁塞窗口的任一子流發生了丟包，擁塞窗口就減半.這類方法在減小窗口的算法上過于激進，會對沒有發生丟包的子流帶來過多的性能限制，因此在公平性上有很大缺陷.之后多路徑TCP的擁塞控制機制設計為每個子流擁有自己的擁塞窗口，在AIMD基礎上，不同子流之間采用聯合擁塞控制的方法.比如EWTCP(equally-weighted TCP)[51]，COUPLED[52-53]，SEMI-COUPLED[54]，LIA[55]，RTT-Compensator[56]，OLIA[57]等.表3給出了這6種方案的窗口調整方式.

EWTCP方案中，通過“加權”限制多路徑TCP在瓶頸鏈路上的吞吐量，多路徑TCP子流以高耦合方式增大擁塞窗口，以獨立的方式減少擁塞窗口.參數a表示多路徑TCP流與單路徑TCP流吞吐量的關系，當a=1，可以滿足多路徑TCP流與單路徑TCP流吞吐量相當.EWTCP的不足之處在于，未考慮不同子流RTT的不同.

COUPLED算法可以保證數據流遷移至最不擁塞的路徑上，其不足之處在于：1)COUPLED僅考慮RTT相同的假設條件；2)COUPLED算法在流量遷移過程中會切斷最擁塞的路徑，當該條路徑恢復非擁塞后，也無法再繼續使用.

SEMI-COUPLED對COUPLED的改進在于，SEMI-COUPLED偏向于使用擁塞程度輕的路徑，但不會完全封閉擁塞最為嚴重的路徑，而是在擁塞的路徑中留一部分少量的數據以監測擁塞的路徑，當發送端的該路徑擁塞狀態減輕至低于其他路徑的程度時，將負載回遷至該路徑上，減輕其他更為擁塞的路徑壓力.SEMI-COUPLED依舊基于RTT相同的假設.

Table 3 Window Size Change of MPTCP Congestion Control Schemes

LIA從瓶頸公平性的角度出發，其最大的改進之處在于該機制考慮到各路徑RTT的不同設計出a的參考值，用來控制窗口變化的加速度.a的值與各條子流的RTT有密切的關聯.

RTT-Compensator在LIA算法之上進行改進，提出每收到一個ACK，則窗口的增大幅度上限設定為1wr，其目的是為了保證若一條或者多條多路徑TCP子流經過一個瓶頸鏈路，在相同的擁塞丟包率下以同一瓶頸中TCP流窗口增大值作為上限.RTT-Compensator兼顧了不同路徑RTT的區別，是最為常用的多路徑TCP擁塞控制機制，其也被應用于多路徑TCP網絡編碼傳輸機制中[43].

OLIA延用LIA中控制窗口變化加速度的思想，從公平性以及最優資源池角度對LIA進行了改進.劃分路徑優劣集合，為不具有最大擁塞窗口的較好路徑提供更大的窗口變化加速度，并減小較差路徑的窗口變化加速度，從而使得資源利用最大化，并使得擁塞鏈路中的大部分發送數據被轉移.目前OLIA已經在Linux-MPTCP內核代碼中實現.

4.2 基于延時判據的擁塞控制算法

在單路徑TCP擁塞控制中，TCP Vegas[58]是典型的基于延時的擁塞控制算法，其主要思想是基于延時的變化估計網絡中緩存的數據包數量，將其固定在一定的數量范圍，調整擁塞窗口的大小.由于延時對擁塞表現得更為敏感，因此可以在數據流未擁塞至丟包的狀態時便觸發擁塞控制，調整速率，減少分組的丟失.在此基礎之上，將基于延時的思想引入至MPTCP中，便提出了基于延時的多路徑TCP擁塞控制機制——加權Vegas(wVegas)算法[59].wVegas算法遵循擁塞均衡準則，即網絡資源效用最大化出現在網絡中每一條路徑上的擁塞程度相同的時候，實現擁塞程度相同的方法是流量遷移.wVegas機制中，欠擁塞的路徑可以獲得更大的權重，該路徑可以以更為激進的方式競爭網絡帶寬，這使得這條路徑傾向于更為擁塞；反之，過擁塞的路徑獲得的權重較小，通過反復變化，最終實現各條路徑上負載均衡.

在wVegas算法中，式(7)表示因擁塞路徑中緩存的分組數量；式(8)中，qr表示該條路徑的擁塞狀況，這里采用基于延時的擁塞控制方式，使用延時的增加作為擁塞程度的度量；as,r代替diff表示多路徑TCP流s在路徑r上因擁塞緩存的分組量，且吞吐量可以表示為xs,r=cwnds,r/rtts,r，最終可以用式(9)表示路徑上的吞吐量.經過推導，在wVegas算法中，速率的變化可以用式(10)表示，as表示多路徑TCP流在所有子流路徑上緩存的分組數量，ys表示多路徑TCP流總的吞吐量，多路徑TCP流中發送速率的增加與該路徑當前數據流的吞吐量占總吞吐量的比值、多路徑TCP緩存的分組總量以及當前路徑的擁塞狀態qr有關，其中，權重表示見式(11).

(7)

(8)

(9)

(10)

(11)

其中，r∈Rs.

4.3 動態窗口耦合機制

動態窗口耦合(dynamic windows coupling， DWC)[60]機制強調了瓶頸的檢測.DWC的核心思想在于，將經過同一個瓶頸的所有子流匯聚成為一條流，同時確保這一邏輯匯聚流與同一瓶頸上的TCP流之間的公平性，DWC同時兼顧丟包率與延時去檢測瓶頸鏈路.DWC機制保證在某一共享的瓶頸鏈路上子流集合(subflow set)可以與TCP流保證公平性，在不同瓶頸上的子流集合可以獨立地競爭帶寬，最大化其傳輸效率，DWC同時需要對瓶頸的遷移做出及時的響應，經過同一個瓶頸的所有子流被認為是一個子流集合.

DWC機制主要過程包括：瓶頸檢測、擁塞窗口調整.初始狀態下，所有子流處于慢啟動狀態，每一條子流都是一個獨立的子流集合.瓶頸檢測過程實際上是子流集合調整的過程.瓶頸檢測的觸發點是某一條子流出現第1個擁塞丟包，繼而其他子流出現延時增加、丟包的現象，則將這些子流分配至一個子流集合內，即該集合內的所有子流目前經過的路徑都包含了某一或者某些瓶頸鏈路.其具體過程如下：假定子流f檢測到一個擁塞丟包，則將子流f從其原子流集合中取出放入新的活躍集(active set)中，檢測所有其他的子流，統計其在該時間點前后的延時，延時明顯增加的子流進入活躍集中，在任意時刻，或者沒有活躍集或者有且僅有一個活躍集，活躍集中的子流通過相同的瓶頸.DWC以丟包為觸發不斷更新活躍集，并對活躍集中的子流進行擁塞控制.DWC的不足之處在于，先后出現丟包或者延時增大的子流不一定經過同一個瓶頸，而是有可能分別經過不同的瓶頸.

4.4 聯合擁塞控制算法小結

聯合擁塞控制算法致力于達到最佳公平性，不過公平性的定義很多，包括子流公平性、瓶頸公平性、網絡公平性等.子流公平性是指瓶頸處每條子流都是獨立的，分享瓶頸的一部分；瓶頸公平性是指MPTCP的子流在瓶頸處與其他TCP子流公平分享瓶頸帶寬；網絡公平性是指MPTCP多子流的總吞吐量不應該好于最好路徑單TCP吞吐量.側重點不同時設計的聯合擁塞控制算法就不同[60].

從更廣泛的角度來說，聯合擁塞控制算法還需要考慮在友好性(friendliness)、快速性(responsiveness)和窗口震蕩(window oscillation)三個矛盾因素間取得折中[61].友好性是指對單TCP的公平性，快速性是指對于網絡的擁塞做出快速的反應，窗口震蕩是指子流上窗口大小的反復震動.比如快速性和窗口震蕩之間的矛盾，如果MPTCP能對路徑擁塞做出快速反應，那么必然意味著某條子流在檢測到擁塞后將快速減小窗口而在發現路徑質量良好時將及時增大窗口，從而可能造成窗口大小的反復震動.

5 能耗管理

MPTCP需要開啟多個接口進行數據傳輸，對于終端而言會增加能量消耗，而有時候開啟多個接口帶來能量消耗甚至造成得不償失的后果.隨著對能耗要求的重視，結合底層技術的研究進展，這方面的研究將會進一步成為熱點.目前主要工作包括2個部分:1)基于MPTCP傳輸過程中的能耗進行量化測量；2)將能耗作為因素之一，用于性能優化.下面分別從這2方面對已有的工作進行介紹.

5.1 MPTCP能耗測量

基于對MPTCP能耗問題的關注，一些MPTCP研究小組采取了多種測量方法對MPTCP傳輸過程中的能耗進行了量化測量，以最小化能耗作為優化目標之一來改進MPTCP設計，從而使得其在保證QoS的同時減少能耗將具有指導性的意義.

文獻[62]提出了通過鄰居節點共享WIFI，Bluetooth接入從而在現存的3G4G連接之外具有多余的連接，并通過MPTCP組合使用這些不同的接入方式形成多路徑，通過在Galaxy Nexus phone上的實際測試，采用MPTCP能夠在提升性能的同時有效節省能耗.在文獻[10]中也提到了合理使用MPTCP可以有效地降低數據的單位傳輸所使用的能耗.

文獻[66]提出MPTCP能耗應主要分為CPU能耗和連接能耗2個部分進行考慮.目前針對MPTCP能耗方面的測量和方案設計主要還是考慮連接能耗.文獻[66]通過實驗得出結論，目前的MPTCP還遠沒有得到其應該具備的性能，除了連接能耗之外，多核CPU的計算能耗也應該考慮能耗和傳輸能力的折中式方案設計.

此外，通過在MPTCP中引入編碼[44-45,67]、高效的調度機制[25]等也可以有效地降低能耗.但從測量的角度，目前還沒有發現太多這方面的工作.

5.2 MPTCP能耗優化方案

能耗大小是路徑選擇和數據調度的標準之一，然而能耗較低的路徑可能擁塞程度較高，如何平衡兩者之間的選擇成為MPTCP相關研究中的一個難點.文獻[68]證明了該優化問題是一個NP難問題，雖然并未提出有效的近似算法，但從理論論證了MPTCP實現吞吐量與能耗雙優的可能性.

基于內核實現的減小能耗方案[69]，在3GWIFI場景下進行討論.由于開啟3G接口的能耗遠大于WIFI接口，故而方案中延遲3G的開啟時間.對于小文件的傳輸，可以在3G開啟前就利用WIFI單接口傳輸完畢；而對于大文件的傳輸，在一定時延后同時啟用3G和WIFI接口，從而提升吞吐量提升，實現魯棒性以及補償能耗的損失.

文獻[70]基于移動設備使用WIFI傳輸數據能耗低于LTE數據傳輸能耗的原理，提出了MPTCP能耗優化方案eMTCP.建立子流接口狀態監測器，實時監測WIFILTE的信道狀態，當LTE需要傳輸數據且WIFI信道正空閑時，將數據轉移到WIFI接口上進行傳輸，最大限度地利用低能耗接口，減少能耗.在此基礎上，文獻[71]進一步考慮了突發流量的情況.

文獻[72-73]同時對能耗和路徑選擇、擁塞控制等的結合進行了考慮.其中，ecMTCP[72]在聯合擁塞控制算法LIA的基礎上加入能耗因子，從而設計出一種新型的擁塞控制算法.文獻[73]使用了最優化理論，通過2個步驟進行路徑選擇和擁塞控制.

然而實際上，不同接入技術在不同網絡場景下都有可能具有不同的能耗表現.文獻[74]認為，將WIFI能耗優于3G能耗作為固有知識是不科學的行為，故而提出在MPTCP中使用實時探測的方式來決定能耗較優路徑.文獻[75]則通過綜合不同無線接口的能耗模型以及不同應用的業務模型來建立相應的預測模型，從而決定所應該選擇的低能耗路徑.由于其中的調度策略的高計算代價，該方案選擇使用云服務器完成調度策略的計算，用戶設備僅需將相關測量參數上傳至云服務器即可獲得選擇結果.

5.3 能耗管理小結

MPTCP協同使用多個網絡接口提升了網絡傳輸的性能，但相較于單接口協議也帶來更多的能耗.如何平衡能耗與性能的關系成為MPTCP能耗優化方案所考慮的一個關鍵問題.根據不同接入網的傳輸效率以及能耗模型的不同，能耗優化方案大多依據上層應用的不同特性動態選擇MPTCP所用接口，如優先使用WIFI網絡.但由于不同接入網(如WIFI和3G)覆蓋范圍有所不同，MPTCP能耗優化方案也應將由地域限制所導致的頻繁接口切換所帶來的能耗納入到考慮范圍內，以更好地適應實際網絡環境.已有的研究表明，MPTCP路徑的選擇和數據分配需要考慮不同接入網絡的能耗.能耗的研究往往是結合其他方面的機制進行綜合考慮的.同時在某些特定條件下，在TCP能滿足傳輸要求時，MPTCP并不一定具有優勢，這完全可以綜合評價具有優勢的接口采用TCP作為傳輸層協議.

6 安 全

隨著MPTCP的普及使用，其安全性也受到了越來越多的重視.首先，由于一個MPTCP連接是由多個TCP連接組成，因此TCP所面臨的威脅同樣會給MPTCP帶來風險；其次，MPTCP中使用的新方法會引入新的威脅.除了第3～5節所提及的性能目標之外，MPTCP要求其所具有的安全性不差于單個TCP連接.以下將從MPTCP中的安全機制、面臨的威脅以及對網絡安全的影響3個方面進行闡述.

6.1 MPTCP中的安全機制

從安全的角度，MPTCP在連接初始化過程中要求能夠提供簡單的機制為后續子流的建立提供驗證信息，同時也是確保所建立的多條TCP子流同屬于一個MPTCP連接.在RFC 6824[10]當中，提出基于密鑰交換來提供相應的功能.在連接初始化過程中，兩端通過3次握手的第2和第3個消息(SYNACK和ACK)中的MPTCP_CAPABLE選項以明文的形式各自包含發送方的64 b密鑰，在后續創建新子流時則可以基于雙方所發送的這2個密鑰生成相應的截斷的32 b令牌(token)，令牌用于標識一組隸屬于同一個MPTCP的子流.另外，還產生一個64 b截斷的密鑰Hash用作初始數據序列號.密鑰和隨機的現時值(nonce)還用于消息認證碼(message authentication code， MAC)的計算，用于認證和防重放.

在建立新子流時， 此前在連接初始化過程中使用MP_CAPABLE握手過程中交換的密鑰為驗證終端主機提供了信息.新子流的建立也和初始化標準TCP連接是類似的，只是在SYN，SYNACK，ACK的數據包中攜帶了MP_JOIN選項.假設NodeA在它的一個地址和NodeB的地址間建立一個新的子流，如圖9所示.從密鑰中生成的令牌決定此新子流應該加入哪一個MPTCP連接,MAC為驗證信息.前2個消息中還各自包含一個現時值，用于MAC值的計算當中，防止重放攻擊.

Fig. 9 Signaling flow of establishing a new subflow in MPTCP.圖9 MPTCP創建新子流的信令流程

6.2 MPTCP面臨的威脅

截止目前，IETF MPTCP工作組當中有2個RFC文檔[15-16]來討論MPTCP可能帶來的安全威脅.在MPTCP從草案變成標準建議[10]之前，RFC 6181[15]給出了使用單連接多地址進行數據傳輸的安全威脅分析，期望借用SHIM6[76]，SCTP[77]，MIPv6[78]等的經驗來指導MPTCP設計.這些可能的威脅在RFC 6824[10]中的解決方案是采用6.1節中所介紹的基于交換密鑰的安全機制，雖然該機制并不能從根本上解決安全威脅，但具有較高的執行效率.最近，RFC 7430[16]在RFC 6181[15]的基礎上，對MPTCP的安全威脅做了進一步的補充.

MPTCP對每個端點引入多個地址的支持，與單路徑TCP比較，MPTCP可以在已有的連接上添加新的地址，這將會導致重定向攻擊的發生.RFC 6181[15]給出了2種可能的攻擊方式：泛洪攻擊(flooding attack)和劫持攻擊(hijack attack)，這兩者都可以由off-Path的攻擊者來發起攻擊，而在引入一些安全機制的情況下，依然可以通過攻擊者初始on-path獲取基于明文傳送的安全信息，然后依然發起off-path的攻擊(這種組合的攻擊方式稱為time-shifted攻擊或者partial-time on-path攻擊).這里的泛洪攻擊指的是攻擊者通過與服務器建立初始的MPTCP連接，然后欺騙服務器與攻擊目標主機建立多個子流，觸發其發送大量的數據流給攻擊目標主機，從而耗費其資源.而在劫持攻擊中，首先由攻擊者劫持合法通信兩端的MPTCP連接，然后添加其地址用于和其中一端建立新的子流，或者作為中間人分別與合法通信的兩端建立子流，而實際的通信雙方還以為是與合法對端建立的子流，通過這樣的方式，攻擊者就可以非法獲得通信數據.RFC 6181[15]總結出3類可行的解決方案可供使用：1)基于cookie的方法；2)使用明文進行秘密交互；3)強加密錨交換.前兩者的缺陷是需要使用明文進行初始交換，無法避免on-path攻擊者對明文交換信息的獲取，但新增加的開銷較小.其中，RFC 6824[10]引入的是第2種方案.第3種方案的安全性較高，目前所提出的方案包括基于公鑰機制[15,79]和基于Hash chain[80]等.RFC 7430[16]還進一步提出了可以采用SSL，CGA，TCPcrypt，DNSSec等強安全機制，但可能會引入額外的交互，計算開銷和系統維護開銷的增加也不容忽視.

除了以上在RFC 6181[15]中所提及的攻擊之外，RFC 7430[16]還對這些攻擊和建議解決方案做了進一步的細化(包括初始握手過程的竊聽、SYNJOIN消息的中斷和篡改攻擊、ADD_ADDR攻擊等).此外，還針對信令交互過程的不合規操作以及可能產生的安全攻擊做了闡述，同時也給出了可行的方案.這些攻擊包括基于MP_JOIN的DoS攻擊、SYN Flooding 攻擊放大.其中，基于MP_JOIN的DoS攻擊類似于TCP中的half-open攻擊，但危害性更大，可以實現分布式的攻擊.如圖9所示的交互過程，當需要增加一個新的TCP子流時，通過包含MP_JOIN選項的3次握手來完成.在第1個SYN+MP_JOIN的消息中，包含32 b的token和一個用于MAC計算的現時值，由于需要對第3個消息發送過來的MAC進行驗證，而不再攜帶token和現時值，那么主機B就必須在接收到第1個消息后維護相應的信息.作為攻擊者就可以假冒主機A發送大量包含不同五元組的SYN+MP_JOIN消息，從而可以耗費主機B的資源.針對TCP的SYN Flooding攻擊指的是攻擊者短時間內發送大量的SYN請求，而服務器端需要維護相應的狀態，大量的請求則會耗費有限的資源；而在MPTCP中，除了需要維護與TCP相關的信息之外，還需要維護初始連接的SYN+MP_CAPABLE中的密鑰信息以及后續子流建立中SYN+ MP_JOIN有關的token和現時信息，這無疑會使得SYN Flooding的攻擊能力得到放大.針對這2個安全威脅，RFC 7430給出的建議方案是使得MPTCP的握手過程從有狀態變成無狀態，由消息重復攜帶必須的信息以及限制half-open的子流的數量.

6.3 MPTCP對網絡安全的影響

MPTCP提供了同時使用在2個節點之間的多個路徑的能力，這就使得數據流不再依附于某個單獨的TCP來進行傳輸，而是可以分布在構成MPTCP連接的多個子流上，實現數據流的分裂且提供連接的彈性.由于子流可以隨時添加和刪除，MPTCP的連接與實際的地址之間是可以實現解耦的，但由于MPTCP連接的不變性，基于token機制，新添加的地址和路徑依然可以關聯與特定的MPTCP連接,這勢必會給現有的網絡安全帶來影響.

文獻[81]總結了MPTCP在現有網絡中的安全機制所帶來的破壞性影響，例如，利用MTCP便于實施跨路徑的分片攻擊、安全檢測和過濾系統的繞過(bypass)，以及作為移動目標防御(moving target defense)[82]的實現手段等.對于數據監測也帶來了極大的難度，例如對于防火墻而言，往往屬于特定的網絡，這就很難中斷包含經過不同網絡的多個TCP子流的MPTCP連接.

MPTCP對于多個TCP子流的數據傳輸往往采用聯合擁塞控制，這就給實現跨路徑的推理攻擊(inference attack)引入了一種有效途徑.文獻[83]提出了利用MPTCP可以有效推斷出非監測路徑上的吞吐量.此外，該文還初步探討了對RTT和發送端的擁塞窗口大小的推斷方法.該文的作者Shafiq 和Liu近期獲得了美國國家科學基金會(National Science Foundation， NSF)的資助(2015-2018)[84]，用于研究利用MPTCP實現旁路攻擊的安全隱患和應對措施，勢必會取得新的進展，對于MPTCP協議下一步的制定也會產生一定的影響.

6.4 安全小結

MPTCP基于傳統TCP，可能會受到與TCP相同的安全威脅，此外，MPTCP可動態添加或刪除子流連接，但MPTCP提供基于令牌驗證的子流管理機制用于驗證子流有效性，其安全保護級別較低，易于導致新的安全威脅.然兒，MPTCP相關的工作主要還是處于如何發揮其傳輸性能，已有的針對MPTCP安全性的考慮并不充分，研究還比較初步，僅包括SYN Flooding等典型攻擊的預防.然而隨著MPTCP受到越來越多的關注，其安全性的考量也逐漸被各研究機構作為一個重要的研究方向.

7 其他方面的研究

7.1 路徑選擇

MPTCP的通信雙方之間可能有多條可供選擇的路徑，選擇最優的路徑子集來傳輸數據有時候會優于使用所有路徑，特別是對于路徑不對稱，即時延、丟包、帶寬、能耗等差異較大.

博弈路徑選擇算法[85]利用博弈的思想在各種開銷之間取平衡，比如接口開啟連接開銷和路徑時延開銷.另外，還有一些基于實現的方案執行路徑選擇策略.MAPS[86]提出在未用于發送數據的路徑上發送少量探測包探知吞吐量，一旦該路徑吞吐量增大到一定閾值則替換已選用集合吞吐量最小的路徑.

文獻[87]使用跨層信息作為移動設備路徑選擇的基本依據，數據接收端使用MAC層測量所得的路徑信號強度來估計路徑質量，從而決定是否啟用或中止一條路徑.該方法比基于時延或丟包率的方法反應更加靈敏準確.

此外，第5節中與能耗相關的工作很多也涉及到路徑管理方面的研究，并且該方向日趨成為熱點.

7.2 移動性和QoS

MPTCP可協同使用多個路徑，增加或者刪除若干路徑而不影響上層應用的連通性，并且能夠將數據從擁塞路徑轉移到其他路徑上進行傳輸.上述特征使得MPTCP 天然集成了移動特性.

除了前面的能耗研究之外，文獻[64]還首次使用具有Linux-MPTCP內核版本的移動設備在實際網絡環境中進行移動性測試，同時使用移動終端的WIFI接口和3G接口進行數據傳輸.當WIFI信號被終止后，MPTCP仍可以使用3G接口繼續進行數據傳輸，上層業務并沒有發生中斷，從而完成了不同接口間數據傳輸的無縫切換，驗證了MPTCP的移動切換特性.

文獻[63]在此基礎上提出更完善的MPTCP移動切換架構，即對于非MPTCP終端，可以使用MPTCP代理作為錨點，與MPTCP終端建立連接，該場景同樣支持移動性.

MPTCP與QoS結合方案[74,88-89]主要針對視頻業務而提出.根據視頻業務對時延敏感但是對丟包不敏感的特性，在MPTCP中增加部分可靠性策略，即接收端設置時延閾值(400 ms)，超過該閾值則接收端直接舍棄未接收到的數據包，這樣在容忍的丟包率范圍內保證小時延.另外，方案中還將視頻業務的I，P，B幀排優先級，對于優先級高的I幀在吞吐量較高的路徑上發送，而P幀在次優的路徑上發送.

7.3 數據中心中的MPTCP

隨著數據中心內部數據傳輸量的迅速增大，其傳統的分層集中式拓撲將造成核心交換機的數據傳輸壓力劇增.近年來的研究提出了VL2[90]以及FatTree[91]等新型拓撲結構來解決這一問題，這些拓撲在數據中心內部任意2臺主機間都有多個核心交換機以提供全帶寬連接.

文獻[92-93]提出在上述密集并行網絡拓撲結構中使用MPTCP替代TCP作為數據中心內部的傳輸協議.不僅利用MPTCP多徑傳輸的特性提升了連接的吞吐量，且由于對上層應用屏蔽部分路徑的失效，也提升了連接的健壯性.另一方面，路徑選擇和擁塞控制功能允許MPTCP將流量轉移到可用空間較大的路徑上，平衡了數據中心核心交換機上的流量，相較于TCP具有更好的公平性.

然而MPTCP在數據中心也存在TCP incast的問題，即同一路徑上的多個子流均遭遇擁塞而同步減小窗口，使得有效數據量急劇減少的情況.這種情況在一個終端向多個服務器同時請求數據時較為常見.EW-MPTCP (equally-weighted MPTCP)[94]在每個MPTCP連接執行自身擁塞控制機制的基礎上，對同一終端的不同MPTCP連接建立聯合擁塞控制機制，為各個連接“加權”，使得這些不同MPTCP以高耦合的方式增大擁塞窗口，其連接吞吐量之和相當于單條TCP連接，以能夠在瓶頸路徑上與單條TCP流公平競爭鏈路帶寬，而不至于引起路徑擁塞，進而避免TCP incast問題.

8 總結和展望

MPTCP是目前網絡領域的重要研究方向之一.本文介紹了MPTCP的技術細節以及不同方面的研究進展，這些研究促使MPTCP由當初的概念逐步走向實用.但本文的部分研究進展還處于模擬實驗階段，需要進一步的實驗，并完善到內核代碼當中.此外在一些研究方向上，相應機制還需要進一步加以研究.要使得MPTCP完全發揮其潛力，在端到端通信方面比擬于TCP在當前的普及程度還有待于進一步的研究.

[1]Song Wei, Zhuang Weihua. Performance analysis of probabilistic multipath transmission of video streaming traffic over multi-radio wireless devices[J]. IEEE Trans on Wireless Communications, 2012, 11(4): 1554-1564

[2]Kurant M. Exploiting the path propagation time differences in multipath transmission with FEC[J]. IEEE Journal on Selected Areas in Communications, 2011, 29(5): 1021-1031

[3]Wang Peng, Lan Julong, Chen Shuqiao. Multipath traffic splitting algorithm based on adaptive granularity[J]. Journal on Communications, 2015, 36(1): 211-217 (in Chinese)

(王鵬, 蘭巨龍, 陳庶樵. 粒度自適應的多徑流量分割算法[J]. 通信學報, 2015, 36(1): 211-217)

[4]Wu Chunming, Wang Baojin, Chen Junhua, et al. A traffic splitting algorithm based on nonius in multi-path[J]. Acta Electronic Sinica, 2010, 38(11): 2550-2554 (in Chinese)

(吳春明, 王保進, 陳均華, 等. 一種基于游標的多徑流量分割算法[J]. 電子學報, 2010, 38(11): 2550-2554)

[5]Stewart R. RFC2960 Stream control transmission protocol[S/OL]. Fremont, CA: IETF, 2000 [2015-06-17]. https://tools.ietf.org/html/rfc2960

[6]Amer P, Becke M, Dreibholz T, et al. draft-tuexen-tsvwg-sctp-multipath-11 load sharing for the stream control transmission protocol (SCTP)[S/OL]. Fremont, CA: IETF, 2013 [2015-12-03]. https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-11

[7]Iyengar J R, Amer P, Stewart R. Concurrent multipath transfer using SCTP multihoming over independent end-to-end paths[J]. IEEE/ACM Trans on Networking, 2006, 14(5): 951-964

[8]Huitema C. draft-huitema-multi-homed-01 multi-homed TCP[S/OL]. Fremont, CA: IETF, 1995 [2015-06-17]. https://tools.ietf.org/html/draft-huitema-multi-homed-01

[9]Eardley P, Nishida Y. IETF MPTCP WG[OL]. [2015-06-17]. http://datatracker.ietf.org/wg/mptcp

[10]Ford A. RFC 6824 TCP extensions for multipath operation with multiple addresses[S/OL]. Fremont, CA: IETF, 2013 [2015-06-17]. https://tools.ietf.org/html/rfc6824

[11]Ford A, Raiciu C, Handley M, et al. RFC 6182 Architectural guidelines for multipath TCP development[S/OL]. Fremont, CA: IETF, 2011 [2015-06-17]. https://tools.ietf.org/html/rfc6182

[12]Raiciu C, Handly M, Wischik D. RFC 6356, Coupled congestion control for multipath transport protocols[S/OL]. Fremont, CA: IETF, 2011 [2015-06-17]. https://tools.ietf.org/html/rfc6356

[13]Walid A, Peng Qiuyu, Hwang J, et al. draft-walid-mptcp-congestion-control-02 balanced linked adaptation congestion control algorithm for MPTCP[S/OL]. Fremont, CA: IETF, 2015 [2015-12-03]. https://tools.ietf.org/html/draft-walid-mptcp-congestion-control-02

[14]Xu Mingwei, Cao Yu, Dong Enhuan. draft-xu-mptcp-congestion-control-02 delay-based congestion control for MPTCP[S/OL]. Fremont, CA: IETF, 2015 [2015-12-03]. https://tools.ietf.org/html/draft-xu-mptcp-congestion-control-02

[15]Bagnulo M. RFC 6181 threat analysis for TCP extensions for multipath operation with multiple addresses[S/OL]. Fremont, CA: IETF, 2011 [2015-06-17]. https://tools.ietf.org/html/rfc6181

[16]Bagnulo M, Paasch C, Gont F, et al. RFC 7430 Analysis of residual threats and possible fixes for multipath TCP (MPTCP)[S/OL]. Fremont, CA: IETF, 2015 [2015-12-03]. https://tools.ietf.org /html/rfc7430

[17]Scharf M, Ford A. RFC 6897 multipath TCP (MPTCP) application interface considerations[S/OL]. Fremont, CA: IETF, 2013 [2015-06-17]. https://tools.ietf.org/html/rfc6897

[18]Wei X, Lopez E. draft-wei-mptcp-proxy-mechanism-02 MPTCP proxy mechanisms[S/OL]. Fremont, CA: IETF, 2015 [2015-06-17]. https://tools.ietf.org/html/draft-wei-mptcp-proxy-mechanism-02

[19]Handley M, Raiciu C. Multipath TCP implementations[OL]. 2015 [2015-06-17]. http://nrg.cs.ucl.ac.uk/mptcp/implementation.html

[20]Google Inc. MPTCP-NS3 project[OL]. 2015 [2015-06-17]. http://code.google.com/p/mptcp-ns3

[21]Kheirkhah M. Morteza Kheirkhah’s homepage on github.com[OL]. 2015 [2015-06-17]. https://github.com/mkheirkhah

[22]Kheirkhah M, Wakeman I, Parisis G. MultiPath-TCP in NS3[OL]. 2014 [2015-06-17]. http://arxiv.org/pdf/1510.07721.pdf

[23]Barré S, Paasch C, Duchêne F, et al. Linux kernel multipath TCP project[OL]. 2015 [2015-06-17]. http://multipath-tcp.org/pmwiki.php/Main/HomePage

[24]Barré S, Paasch C, Bonaventure O. MultiPath TCP: From theory to practice[C] //Proc of IFIP Networking. Berlin: Springer, 2011: 444-457

[25]Barré S. Implementation and assessment of modern host-based multipath solutions[D]. Louvain-la-Neuve: Université catholique de Louvain, 2011

[26]Raiciu C, Paasch C, Barré S, et al. How hard can it be? Designing and implementing a deployable multipath TCP[C] //Proc of the 9th USENIX Symp of Networked Systems Design and Implementation (NSDI’12). Berkeley, CA: USENIX Association, 2012: No.29

[27]Paasch C, Ferlin S, Alay O, et al. Experimental evaluation of multipath TCP schedulers[C] //Proc of the 2014 ACM SIGCOMM Workshop on Capacity Sharing Workshop (CSWS 2014). New York: ACM, 2014: 27-32

[28]Apple Inc. MPTCP patch for Apple IOS and MacOS[OL]. 2015 [2015-06-17]. http://www.opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet

[29]Paasch C. Improving multipath TCP[D]. Louvain-la-Neuve: Université catholique de Louvain, 2014

[30]Detal G, Baerts M, Caninck Q D. Bundles for Android[OL]. 2015 [2015-06-17]. http://multipath-tcp.org/pmwiki.php/Users/Android

[31]Raiciu C, Pluntke C, Barré S, et al. Data center networking with multipath TCP[C] //Proc of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks (HotNets IX workshop). New York: ACM, 2010: No.10

[32]Raiciu C, Barré S, Pluntke C, et al. Improving datacenter performance and robustness with multipath TCP[J]. ACM SIGCOMM Computer Communication Review, 2011, 41(4): 266-277

[33]Armitage G, Williams N, Stewart L, et al. Multipath TCP work in CAIA[OL]. 2015 [2015-06-17]. http://caia.swin.edu.au/urp/newtcp/mptcp

[34]Chen Y C, Lim Y, Gibbens R J, et al. A measurement-based study of multipth TCP performance over wireless networks[C] //Proc of the 2013 Internet Measurement Conf (IMC’13). New York: ACM, 2013: 455-468

[35]Mirani F, Boukhatem N, Tran M A. A data-scheduling mechanism for multi-homed mobile terminals with disparate link latencies[C] //Proc of the 72nd IEEE Vehicular Technology Conf (VTC 2010-Fall). Piscataway, NJ: IEEE, 2010: 1-5

[36]Ni Dan, Xue Kaiping, Hong Peilin, et al. Fine-grained forward prediction based dynamic packet scheduling mechanism for multipath TCP in lossy networks[C] //Proc of the 23rd Int Conf on Computer Communications and Networks (ICCCN 2014). Piscataway, NJ: IEEE, 2014: 1-7

[37]Ni Dan, Xue Kaiping, Hong Peilin, et al. OCPS: Offset compensation based packet scheduling mechanism for multipath TCP[C] //Proc of Int Conf on Communications (ICC 2015). Piscataway, NJ: IEEE, 2015: 6187-6192

[38]Xu Changqiao, Liu Tianjiao, Guan Jianfeng, et al. CMT-QA: Quality-aware adaptive concurrent multipath data transfer in heterogeneous wireless networks[J]. IEEE Trans on Mobile Computing, 2013, 12(11): 2193-2205

[39]Kim H, Oh B, Lee J. Improvement of MPTCP performance in heterogeneous network using packet scheduling mechanism[C] //Proc of the 18th Asia-Pacific Conf on Communications (APCC 2012). Piscataway, NJ: IEEE, 2012: 842-847

[40]Yang Fan, Amer P, Ekiz N. A scheduler for multipath TCP[C] //Proc of the 22nd Int Conf on Computer Communications and Networks (ICCCN 2013). Piscataway, NJ: IEEE, 2013: 1-7

[41]Casetti C, Gaiotto W. Westwood SCTP: Load balancing over multipaths using bandwidth-aware source scheduling[C] //Proc of the 60th IEEE Vehicular Technology Conf (VTC 2004-Fall). Piscataway, NJ: IEEE, 2004: 3025-3029

[42]Cloud J, Calmon F, Zeng Weifei, et al. Multi-path TCP with network coding for mobile devices in heterogeneous networks[C] //Proc of the 78th IEEE Vehicular Technology Conf (VTC 2013-Fall). Piscataway, NJ: IEEE, 2013: 1-5

[43]Li Ming, Lukyanenko A, Cui Yong. Network coding based multipath TCP[C] //Proc of the 2012 IEEE Conf on Computer Communications Workshops (INFOCOM WKSHPS). Piscataway, NJ: IEEE, 2012: 25-30

[44]Cui Yong, Wang Lian, Wang Xin, et al. FMTCP: A fountain code-based multipath transmission control protocol[J]. IEEE/ACM Trans on Networking, 2015, 23(2): 465-478

[45]Sharma V, Troy K, Kar K, et al. MPLOT: A transport protocol exploiting multipath diversity using erasure codes[C] //Proc of the 27th Conf on Computer Communications (INFOCOM 2008). Piscataway, NJ: IEEE, 2008: 592-600

[46]Li Ming, Ludreyanenko A, Tarkoma S, et al. Tolerating path heterogeneity in multipath TCP with bounded receive buffers[J]. Computer Networks, 2014, 64(2014): 1-14

[47]Eggert L, Heidemann J, Touch J. Effects of ensemble-TCP[J]. ACM SIGCOMM Computer Communication Review, 2000, 30(1): 15-29

[48]Balakrishnan H, Rahul H, Seshan S. An integrated congestion management architecture for Internet hosts[J]. ACM SIGCOMM Computer Communication Review, 1999, 29(4): 175-187

[49]Singh M, Pradhan P, Francis P. MPAT: Aggregate TCP congestion management as a building block for Internet QoS[C] //Proc of the 12th IEEE Int Conf on Network Protocols (ICNP 2004). Piscataway, NJ: IEEE, 2004: 129-138

[50]Handley M, Padhye J, Floyd S. RFC2861 TCP congestion window validation[S/OL]. Fremont, CA: IETF, 2000 [2015-06-17]. https://tools.ietf.org/html/rfc2861

[51]Honda M, Nishida Y, Eggert L, et al. Multipath congestion control for shared bottleneck[C] //Proc of the 7th Int Workshop on Protocols for Future, Large-Scale and Diverse Network Transports (PFLDNeT Workshop). New York: ACM, 2009: 19-24

[52]Han H, Shakkottai S, Hollot C, et al. Overlay TCP for multi-path routing and congestion control[C/OL] //Proc of IMA Workshop on Measurements and Modeling of the Internet. Montvale, NJ: IMA, 2004 [2015-06-17]. http://www.ifp.illinois.edu/～sshakkot/multipath_v3.pdf

[53]Kelly F, Voice T. Stability of end-to-end algorithms for joint routing and rate control[J]. ACM SIGCOMM Computer Communication Review, 2005, 35(2): 5-12

[54]Wischik D, Raiciu C, Greenhalgh A, et al. Design, implementation and evaluation of congestion control for multipath TCP[C] //Proc of the 8th USENIX Conf on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2011: No.8

[55]Raiciu C, Handley M, Wischik D. RFC 6356 coupled congestion control for multipath transport protocols[S/OL]. Fremont, CA: IETF, 2000 [2015-06-17]. https://tools.ietf.org/html/rfc6356

[56]Raiciu C, Wischik D, Handley M. Practical congestion control for multipath transport protocols[R/OL]. London, United Kingdom: University College London. 2009 [2015-06-17]. http://nrg.cs.ucl.ac.uk/mptcp/mptcp-techreport.pdf

[57]Khalili R, Gast N, Popovic M, et al. MPTCP is not Pareto-optimal: Performance issues and a possible solution[C] //Proc of the 8th Int Conf on Emerging Networking Experiments and Technologies (CoNEXT 2012). New York: ACM, 2012: 1-12

[58]Brakmo L, O’Malley S W, Peterson L L. TCP vegas: New techniques for congestion detection and avoidance[J]. ACM SIGCOMM Computer Communication Review, 1994, 24(4): 24-35

[59]Cao Yu, Xu Mingwei, Fu Xiaoming. Delay-based congestion control for multipath TCP[C] //Proc of the 20th IEEE Int Conf on Network Protocols (ICNP 2012). Piscataway, NJ: IEEE, 2012: 1-10

[60]Hassayoun S, Iyengar J, Ros D. Dynamic window coupling for multipath congestion control[C] //Proc of the 19th IEEE Int Conf on Network Protocols (ICNP 2011). Piscataway, NJ: IEEE, 2011: 341-352

[61]Peng Qiuyu, Walid A, Low S H. Multipath TCP: Analysis and design[OL]. 2013 [2015-06-17]. http://arxiv.org/pdf/1308.3119.pdf

[62]Nicutar C, Niculescu D, Raiciu C. Using cooperation for low power low latency cellular connectivity[C] //Proc of the 10th ACM Int Conf on Emerging Networking Experiments and Technologies (CoNEXT’14). New York: ACM, 2014: 337-348

[63]Raiciu C, Niculescu D, Bagnulo M, et al. Opportunistic mobility with multipath TCP[C] //Proc of the 6th Int Workshop on MobiArch. New York: ACM, 2011: 7-12

[64]Paasch C, Detal G, Duchene F, et al. Exploring mobile/WiFi handover with multipath TCP[C] //Proc of the 2012 ACM SIGCOMM Workshop on Cellular Networks: Operations, Challenges, and Future Design. New York: ACM, 2012: 31-36

[65]Deng Shuo, Netravali R, Sivaraman A, et al. WiFi, LTE, or both?: Measuring multi-homed wireless Internet performance[C] //Proc of the 2014 Conf on Internet Measurement. New York: ACM, 2014: 181-194

[66]Nika A, Zhu Yibo, Ding Ning, et al. Energy and performance of smartphone radio bundling in outdoor environments[C] //Proc of the 24th Int Conf on World Wide Web. Republic and Canton of Geneva, Switzerland: IW3C2 (International World Wide Web Conferences Steering Committee), 2015: 809-819

[67]Zhang Hong, Xue Kaiping, Hong Peilin, et al. Congestion exposure enabled TCP with network coding for hybrid wired-wireless network[C] //Proc of the 23rd Int Conf on Computer Communication and Networks (ICCCN 2014). Piscataway, NJ: IEEE, 2014: 1-8

[68]Minear L, Zhang E. Impact of energy consumption on multipath TCP enabled mobiles[OL]. 2014 [2015-06-17]. http://arxiv.org/pdf/1412.7912v1.pdf

[69]Lim Y S, Chen Y C, Nahum E M. How green is multipath TCP for mobile devices?[C] //Proc of the 4th Workshop on All Things Cellular: Operations, Applications, & Challenges. New York: ACM, 2014: 3-8

[70]Chen Shengyang, Yuan Zhenhui, Muntean G M. An energy-aware multipath-TCP-based content delivery scheme in heterogeneous wireless networks[C] //Proc of the 2013 IEEE Wireless Communications and Networking Conf (WCNC 2013). Piscataway, NJ: IEEE, 2013: 1291-1296

[71]Chen Shengyang, Yuan Zhenhui, Muntean G M. A traffic burstiness-based offload scheme for energy efficiency deliveries in heterogeneous wireless networks[C] //Proc of the 2013 IEEE Global Communications Conf Workshops (IEEE Globecom Workshops). Piscataway, NJ: IEEE, 2013: 538-543

[72]Le T A, Hong C S. ecMTCP: An energy-aware congestion control algorithm for multipath TCP[J]. IEEE Communications Letters, 2011, 16(2): 275-277

[73]Peng Qiuyu, Chen Minghua, Anwar W, et al. Energy efficient multipath TCP for mobile devices[C] //Proc of the 15th ACM Int Symp on Mobile Ad Hoc Networking and Computing (Mobihoc 2014). New York: ACM, 2014: 257-266

[74]Singh V, Ahsan S, Ott J. MPRTP: Multipath considerations for real-time media[C] //Proc of the 4th ACM Multimedia Systems Conf(MMSys’13). New York: ACM, 2013: 190-210

[75]Pluntke C, Eggert L, Kiukkonen N. Saving mobile device energy with multipath TCP[C] //Proc of the 6th Int Workshop on MobiArch. New York: ACM, 2011: 1-6

[76]Nordmark E, Bagnulo M. RFC5533 Shim6: Level 3 multihoming shim potocol for IPv6[S/OL]. Fremont, CA: IETF, 2009 [2015-06-17]. https://tools.ietf.org/html/rfc5533

[77]Stewart R. RFC4960 stream control transmission protocol[S/OL]. Fremont, CA: IETF, 2007 [2015-06-17]. https://tools.ietf.org/html/rfc4960

[78]Gundavelli S, Leung K, Devarapalli V, et al. Proxy mobile IPv6[S/OL]. Fremont, CA: IETF, 2008 [2015-06-17]. https://tools.ietf.org/html/rfc4960

[79]Bagnulo M. draft-bagnulo-mptcp-secure-00 secure MPTCP[S/OL]. Fremont, CA: IETF, 2014 [2015-06-17]. https://tools.ietf.org/html/draft-bagnulo-mptcp-secure-00

[80]Diez J, Bagnulo M, Valera F, et al. Security for multipath TCP: A constructive approach[J]. International Journal of Internet Protocol Technology, 2011, 6(3): 146-155

[81]Pearce C, Zeadally S. Ancillary impacts of multipath transmission control protocol (MPTCP) on current and future network security[J]. IEEE Internet Computing, 2015, 19(5): 58-65

[82]Jajodia S, Ghosh A K, Swarup V, et al. Moving Target Defense: Creating Asymmetric Uncertainty for Cyber Threats[M]. Berlin: Springer, 2011

[83]Shafiq M Z, Le F, Srivatsa M, et al. Cross-path inference attacks on multipath TCP[C] //Proc of the 12th ACM Workshop on Hot Topics in Networks (Hotnets 2013). New York: ACM, 2013: No.15

[84]Shafiq M Z. Multipath TCP side channel vulnerabilities and defenses[OL]. 2015 [2015-12-03]. http://www.nsf.gov/awardsearch/showAward?AWD_ID=1524329

[85]Nguyen S C, Nguyen T M T, Pujolle G, et al. Strategic evaluation of performance-cost trade-offs in a multipath TCP multihoming context[C] //Proc of the 2012 IEEE Int Conf on Communications (ICC 2012). Piscataway, NJ: IEEE, 2012: 1443-1447

[86]Chen Yu, Wu Xin, Yang Xiaowei. MAPS: Adaptive path selection for multipath transport protocols in the Internet, TR2011-09[R]. Durham, North Carolina: Department of Computer Science, Duke University, 2011

[87]Lim Y, Chen Y, Nahum E, et al. Cross-layer path management in multi-path transport protocol for mobile devices[C] //Proc of the 2014 IEEE Conf on Computer Communications (INFOCOM 2014). Piscataway, NJ: IEEE, 2014: 1815-1823

[88]Diop C, Dugué G, Chassot C, et al. QoS-aware and autonomic-oriented multi-path TCP extensions for mobile and multimedia applications[J]. International Journal of Pervasive Computing and Communications, 2012, 8(4): 306-328

[89]Dugue G, Chassot C, Exposito E. QoS-aware multipath-TCP extensions for mobile and multimedia applications[C] //Proc of the 9th Int Conf on Advances in Mobile Computing and Multimedia(MoMM’11). New York: ACM, 2011: 139-146

[90]Greenberg A, Hamilton J R, Jain N, et al. VL2: A scalable and flexible data center network[J]. ACM SIGCOMM Computer Communication Review, 2009, 39(4): 51-62

[91]Al-Fares M, Loukissas A, Vahdat A. A scalable, commodity data center network architecture[J]. ACM SIGCOMM Computer Communication Review, 2010, 38(4): 63-74

[92]Raiciu C, Pluntke C, Barre S, et al. Data center networking with multipath TCP[C] //Proc of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks. New York: ACM, 2010: No.10

[93]Raiciu C, Barre S, Pluntke C, et al. Improving datacenter performance and robustness with multipath TCP[J]. ACM SIGCOMM Computer Communication Review, 2011, 41(4): 266-277

[94]Li Ming, Lukyanenko A, Tarkoma S, et al. MPTCP incast in data center networks[J]. China Communications, 2014, 11(4): 25-37

Xue Kaiping, born in 1980. PhD, associate professor. Senior member of China Computer Federation and IEEE. His main interests include next generation network architecture, network security.

Chen Ke, born in 1992. Master candidate. Her main research interests include multipath TCP performance improvement and mobility management (chenke13@mail.ustc.edu.cn).

Ni Dan. born in 1991. Received her master degree from University of Science and Technology of China in 2015. Her main research interests include network performance optimization (nidan@mail.ustc.edu.cn).

Zhang Hong. born in 1990. Received her master degree from University of Science and Technology of China in 2015. Her main research interests include network performance optimization (zhh006@mail.ustc.edu.cn).

Hong Peilin. born in 1961. Professor. PhD supervisor. Her main research interests include next-generation network architecture, network virtualization, and information security (plhong@ustc.edu.cn).

Survey of MPTCP-Based Multipath Transmission Optimization

Xue Kaiping1,2, Chen Ke1,2, Ni Dan1, Zhang Hong1, and Hong Peilin1,2

1(DepartmentofElectronicEngineeringandInformationScience,UniversityofScienceandTechnologyofChina,Hefei230027)2(KeyLaboratoryofWireless-OpticalCommunications(UniversityofScienceandTechnologyofChina),ChineseAcademyofSciences,Hefei230027)

The newly developed networks hope to bring some specific features, such as wide coverage, high bandwidth, and provide varieties of media services. Fortunately, multiple access techniques are at there to help. Nowadays，terminals are always equipped with multiple interfaces to adapt to the heterogeneous networks. Thus, there are more than one paths existing between two endpoints. MPTCP (multipath TCP) is proposed by IETF MPTCP working group, in addition to compatible with traditional TCP, which utilizes multiple paths to transmit data. It improves the efficiency of bandwidth usage and the resilience of the connection. What’s more, it can adaptively move data from more congested path to less congested path. In recent years, many researches have been carried out to gradually make MPTCP from concept to practice. This paper introduces the technical details of MPTCP standard, and expounds the present situation of the related aspects, including simulation and actual deployment, out-of-order control, coupled congestion control, energy consumption maintenance, security, and other aspects such as path selection, mobility and QoS, the data center scenario, et al. Finally, this paper gives a summary and expectation.

multiple path; multipath TCP (MPTCP); scheduling algorithms; congestion control; energy consumption management; security

2015-06-17；

2015-12-29

國家自然科學基金項目(61379129，61390513)；國家“八六三”高技術研究發展計劃基金項目(2014AA01A706)

TP393

This work was supported by the National Natural Science Foundation of China (61379129, 61390513) and the National High Technology Research and Development Program of China (863 Program) (2014AA01A706).