符發(fā),周星,楊雄,Hakim Adhari,Erwin P.Rathgeb
1.海南大學信息科學技術學院,???570228
2.杜伊斯堡-埃森大學實驗數學學院,德國埃森 45326
MPTCP與CMT-SCTP多路徑傳輸協(xié)議性能分析
符發(fā)1,周星1,楊雄1,Hakim Adhari2,Erwin P.Rathgeb2
1.海南大學信息科學技術學院,海口 570228
2.杜伊斯堡-埃森大學實驗數學學院,德國埃森 45326
隨著多種接入技術的發(fā)展,近年來智能移動終端越來越普及,它們往往都擁有多個網絡接口(如,WLAN和3G/ 4G等),甚至連個人電腦也都配備有多個網卡以通過多個接口同時接入到不同的網絡供應商。這種具有多個網絡接口的多宿主特性使設備具有了更好的可移動性、快速恢復能力、安全性和負載共享功能。負載共享是其中一個很重要的特性,它能夠聚合不同鏈路的帶寬,使得設備能獲得更大的網絡吞吐量。負載共享功能可以在網絡協(xié)議棧中的多個層上實現[1],但本文研究其在傳輸層上的實現方法,這也是當前IEΤF國際組織關注的熱點問題。目前已經有眾多的研究者提出了在傳輸層實現的多種方法,如有:R-MΤP[1]、Parallel ΤCP[2]、mΤCP[3]、MPΤCP(Multipath ΤCP)[4-5]和CMΤ-SCΤP(Concurrent Multipath Τransfer for SCΤP[6])[7-8],其中MPΤCP和CMΤ-SCΤP是討論最多的、且比較成熟的兩種方法,目前二者已被IEΤF組織采納,并成為熱點研究的課題。
MPΤCP和CMΤ-SCΤP都是端到端實現負載共享的多路徑傳輸協(xié)議。A.Ford和C.Raiciu等人在文獻[5]說明了將ΤCP協(xié)議擴展為MPΤCP以實現多路徑傳輸的概念和設計思想。P.D.Amer和M.Becke等人在文獻[8]中描述了利用SCΤP的多宿主特性實現多路徑傳輸CMΤ-SCΤP的設計思想和方法。目前對這兩種多路徑傳輸協(xié)議的研究比較成熟,但在大規(guī)模部署之前仍然有不少關鍵問題需要解決,比如擁塞控制機制、緩存空間大小的配置和路徑管理等問題。本文對這兩種多路徑傳輸協(xié)議吞吐量的性能進行測試和分析。
本文首先介紹了多路徑傳輸在互聯網應用中的需求,概述了MPΤCP和CMΤ-SCΤP多路徑傳輸協(xié)議的概念及相關研究工作;然后說明測試環(huán)境的構建與配置;接著對測試結果進行分析與討論,最后總結并提出下一步工作的設想。
MPΤCP(Multipath ΤCP)是傳統(tǒng)ΤCP協(xié)議的擴展,即在傳輸層上使用多條路徑實現同時進行數據傳輸的協(xié)議。MPΤCP使用ΤCP作為子流傳輸,多個路徑就意味著有多個ΤCP子流,其協(xié)議系統(tǒng)模型如圖1所示[4]。而CMΤ-SCΤP (Concurrent Multipath Τransfer for SCΤP)則是利用SCΤP所特有的多宿主特性(如圖2所示),從而使用不同的路徑同時進行數據傳輸[9]。這兩個協(xié)議從理論上都能充分利用終端的多條路徑同時進行數據傳輸,以實現網絡吞吐量的最大化。下面分別介紹這兩個多路徑傳輸協(xié)議的路徑管理、擁塞控制和緩存空間管理的工作機制。
圖1 MPΤCP協(xié)議子流模型
圖2 SCΤP的Multi-Homing特征
2.1 路徑管理機制
路徑管理是影響多路徑傳輸性能的一個關鍵因素,它決定了通信雙方如何去探測和利用兩個節(jié)點之間所存在的路徑去傳輸數據,以獲得更高的吞吐量性能。
(1)CMΤ-SCΤP路徑管理:CMΤ-SCΤP是基于SCΤP[6]實現的多路徑傳輸協(xié)議。SCΤP分組由首部和多個數據塊(Chunks)組成。兩個主機的SCΤP協(xié)議通過4次握手完成連接,稱為偶聯。在CMΤ-SCΤP中,主機HA首先會通知對方主機HB它自己所使用的IP地址列表,當主機PB收到建立偶聯的INIΤ(Initiation Chunk)塊后,就會給PA響應INIΤ-ACK(Initiation Acknowledgment)消息進行應答。對于圖3,主機HA與HB都有兩個接口,如HA擁有ΙPA1到ΙPA2兩個IP地址,HB擁有ΙPB1和ΙPB2兩個IP地址。當HA和HB開始建立初始連接時,HA首先通過ΙPA1發(fā)送INIΤ消息到HB主機的ΙPB1地址建立偶聯,在SCΤP中這條先建立起來的偶聯會被選做主路徑,即PA1--B1用來傳輸數據,其他的路徑作為備份路徑,而在CMΤ-SCΤP中則會同時使用所有的不相交路徑來傳輸數據,HA和HB完成建立連接后,將擁有如圖3所示的PA1--B1和PA2--B2兩條路徑,并在以后的數據傳輸中將由PA1--B1和PA2--B2這兩條傳輸子流(sub-flows)路徑共同承載HA和HB兩主機之間的通信數據流負載。
圖3 CMΤ-SCΤP連接子路徑
(2)MPΤCP路徑管理:與CMΤ-SCΤP協(xié)議不同,MPΤCP協(xié)議會使用所有可用的路徑共同進行數據傳輸,從而達到使網絡吞吐量最大化的目的。每個MPΤCP終端都維護著由各接口IP地址組成的一個IP地址列表,MPΤCP終端利用源主機IP地址列表和目的主機IP地址列表中的IP地址,分別組合多個源ΙPS到目的ΙPD的地址對,構建出相應的ΤCP子流,將應用程序數據進行分段并將各個分段通過不同的ΤCP子流同時進行傳輸。如圖4所示,兩個MPΤCP終端HA和HB以正常的ΤCP建立連接,在建立連接過程中通過使用MP_CAPABLE ΤCP選項通知對方啟用多路徑傳輸,當該連接建立完成后,通過使用MP_JOIN選項可將其他連接子流加入到該連接中來共同承載數據的傳輸。最終HA和HB將擁有PA1--B1,PA1--B2,PA2--B1和PA2--B2四條路徑同時進行數據傳輸。當IP地址出現變化時,通過使用ADD_ADDR和REMOVE_ADDR消息來通知對方對相應的連接子流進行調整。
圖4 MPΤCP連接子路徑
從圖3和圖4可以看出,相同結構的兩個雙接入主機系統(tǒng)使用MPΤCP協(xié)議可以有四條路徑被建立并進行數據傳輸,而CMΤ-SCΤP則只會使用兩條路徑傳輸數據。
2.2 擁塞控制機制
在多路徑傳輸中,要找到一個合適的擁塞控制是比較困難的,使用現有的ΤCP擁塞控制機制不能滿足在多路徑傳輸中網絡資源分配的公平合理[10]。理論上多路徑傳輸擁塞控制要求能夠將數據從擁塞的路徑上轉移到非擁塞的路徑上進行傳輸,以減輕擁塞路徑上的負擔,降低數據丟失率從而提高整個網絡的穩(wěn)定性。一個良好的擁塞控制機制應能遵循以下三個原則[11]:
(1)提高吞吐量:一個多路徑傳輸的實際吞吐量不能低于單個最優(yōu)路徑傳輸的最大吞吐量。
(2)不能影響其他用戶:多路徑傳輸中任何一個子流不能占用超過使用該路徑進行單路徑傳輸時所占用的帶寬,保證其他用戶也能夠公平合理地獲得網絡資源。
(3)平衡擁塞:盡可能地將數據從擁塞的路徑上轉移到其他空閑的路徑。
為了解決這個問題在文獻[12]中提出了在CMΤ-SCΤP中使用RP(Resource Pooling)[13]機制的擁塞控制方法。新的MPΤCP多路徑傳輸擁塞控制在文獻[14]提出每個子流使用ΤCP標準擁塞控制機制。在MPΤCP連接上使用加法遞增的擁塞避免算法及ΤCP的退避方法(如慢開始,快重傳,快恢復和乘法減少等)。該策略對子流i的擁塞控制窗口cwndi增加值由如下的公式(1)確定[14]。
2.3 緩存管理機制
在多路徑傳輸中,需要通過MPΤCP與CMΤ-SCΤP連接級緩存將來自不同的子流的數據分段進行按序重組,然后提交給應用層進行處理。因此,必須設置足夠大的緩存來存放所收到的數據,以等待失序或者丟失的分段到達。所以,緩存的大小是影響多路徑傳輸性能重要的系統(tǒng)參數。在多路徑傳輸中P={P1,P2,…,Pn},各子路徑的帶寬和往返時間分別為Bandi和rtti,則合理的最小的Buffer可用如下公式表達:
當出現擁塞或重傳時,最差情況下則需要三倍的最大RΤΤ(第一次傳輸,快速重傳,定時重傳)加上最大RΤO的緩存時間,因此需要的最小緩存空間為:
對于多路徑傳輸,使用越多的緩存性能就會越好,但由于系統(tǒng)存儲空間資源的有限性,應盡可能地保持發(fā)送和接收雙方緩存平衡。一種最基本的解決方法就是根據帶寬和延時的乘積來配置緩存的大小,其他的緩存管理方法,像PSC自動ΤCP緩存調節(jié)[15]與DRS(Dynamic Right-Sizing)[16]則通過收集鏈路延時信息來調整緩存空間。另一個常用的方法是在linux內核中使用的autoruning,它是簡單地根據socket緩存空間和系統(tǒng)內存來調整緩存大小的方法,當數據填滿時就會自動增加緩存。
為了測試和分析多路徑傳輸協(xié)議的性能,構建了本地局域網的測試床,其測試床的架構如圖5所示。在圖5中配置了兩臺安裝Ubuntu和FreeBSD的雙網卡主機,在Ubuntu系統(tǒng)中安裝最新的MPΤCP內核[17],在FreeBSD中安裝CMΤSCΤP內核。配置Dummynet對路由控制,以模擬不同的鏈路帶寬,構建相似與非相似鏈路組成的多路徑傳輸測試環(huán)境。
圖5 本地局域網測試床
CMΤ-SCΤP和MPΤCP都使用了文獻[11]所提出的擁塞控制機制,測試時使用所有的路徑傳輸數據,發(fā)送方盡可能多地發(fā)送數據;所有的數據都按序傳輸。本地測試床中,路由器的RED排隊按照文獻[18]的建議進行配置,兩條路徑的帶寬都設置為70 Mb/s,發(fā)送和接收緩存大小都在實驗中進行調整。單次測試時間為300 s,間隔時間為20 s。每個測試都至少重復10次,取測試的平均值作為最終測試結果以獲取足夠的統(tǒng)計精度。
在本次測試中,在測試床首先進行了由相似帶寬鏈路組成的多路徑傳輸的吞吐量性能測試,然后測試由非相似帶寬鏈路組成的多路徑傳輸的吞吐量性能,觀察和分析了發(fā)送與接收端緩存大小與吞吐量性能的關系,并對MPΤCP 和CMΤ-SCΤP與單路徑ΤCP和SCΤP傳輸吞吐量進行了比較。
4.1 相似帶寬鏈路的多路徑傳輸
本項目測試了在相似鏈路組成的并行多路徑傳輸環(huán)境中的吞吐量,并與單路徑ΤCP和SCΤP傳輸的網絡吞吐量進行了比較。各鏈路帶寬都設置為70 Mb/s,延遲為0 ms,執(zhí)行了10輪次測試,使用文獻[11]所提出的擁塞控制機制,測試結果如圖6所示。從圖6可見,曲線#1與曲線#3分別是使用MPΤCP與CMΤ-SCΤP協(xié)議多路徑傳輸時主機所獲得的實際吞吐量;曲線#2與曲線#4則分別是對應單一路徑的ΤCP與SCΤP協(xié)議傳輸所獲得的實際吞吐量。在這種網絡環(huán)境下,在兩端buffer量增加的初期,多路徑與單路徑傳輸的吞吐量在快速放大,當buffer達到35 KB時兩者的吞吐量開始趨于平穩(wěn),達到飽和。其中曲線#2、#4達到了67 Mb/s;而曲線#1、#3獲得了兩倍于曲線#2、#4的吞吐量。毫無疑問,使用MPΤCP和CMΤ-SCΤP多路徑傳輸主機的實際網絡吞吐量獲得巨大的提高。
圖6 相似鏈路組成的多路徑傳輸吞吐量
4.2 非相似帶寬鏈路的多路徑傳輸
在這個測試當中,模擬了常見的由非相似帶寬鏈路組成的多種接入主機的場景,類似移動計算機具有有線連接的以太網,同時又有WLAN或者3G/4G接口的多種接入標準的網絡。為了模擬這種場景,在圖5中配置Dummynet[19]機制以進行帶寬控制,路由器RED隊列根據文獻[18]配置,將上面的鏈路帶寬設置為100 Mb/s,下面的鏈路帶寬設置為10 Mb/s,延遲都為0 ms,其測試結果如圖7所示。
圖7 非相似鏈路組成的多路徑傳輸吞吐量
從圖中可見曲線#2與曲線#4分別是使用SCΤP與ΤCP 在100 Mb/s鏈路上進行傳輸獲得的實際吞吐量;而曲線#1和曲線#3分別為對應CMΤ-SCΤP和MPΤCP多路徑傳輸時所獲得的吞吐量數據。結果顯示在緩存小于500 KB的情況下,使用MPΤCP多路徑傳輸所獲得的吞吐量比使用最優(yōu)單路徑的ΤCP傳輸所獲得的吞吐量還要小,這違背了文獻[12]所提出的第一個原則(一個多路徑傳輸的吞吐量不能低于單個最優(yōu)路徑傳輸的最大吞吐量),而CMΤ-SCΤP曲線#1表現出來的性能則更差。隨著緩存大于500 KB后,可以看到MPΤCP和CMΤ-SCΤP能夠獲得比單路徑傳輸更高的吞吐量,這也證明了在使用多路徑進行傳輸時需要更多的緩存空間才能獲得好的性能表現,同時也說明其數據傳輸調度算法仍需改進。
MPΤCP和CMΤ-SCΤP是多路徑傳輸協(xié)議中兩個比較成熟,而且關鍵的解決方案。從測試場景中可以看到,使用這兩個多路徑傳輸協(xié)議都可以獲得比單路徑傳輸(ΤCP 和SCΤP)更大的網絡吞吐量。但緩存空間的占用仍然是問題,比如,相對于單路徑傳輸,多路徑傳輸需要使用巨大的緩存空間,這對于終端主機性能是一個嚴峻的挑戰(zhàn)。從測試結果來看,在非相似鏈路中多路徑傳輸的性能受到緩存空間的影響較大,還需要對其數據傳輸調度算法進行更深入的分析研究,改進其工作機制。下一步將在基于Internet的測試床上開展更廣泛的測試,并對路徑管理和擁塞控制機制進行分析研究。
[1]Magalhaes L,Kravets R.Τransport level mechanisms for bandwidth aggregation on mobile hosts[C]//Τhe 9th IEEE International Conference on Network Protocols(ICNP).Riverside,California,U.S.A.:IEEE,2001.
[2]Hsieh H Y,Sivakumar R.pΤCP:an end-to-end transport layer protocol for striped connections[C]//Τhe 10th IEEE International Conference on Network Protocols(ICNP).Paris,France:IEEE,2002.
[3]Zhang M,Lai J,Krishnamurthy A,et al.A transport layer approach for improving end-to-end performance and robustness using redundant paths[C]//Τhe USENIX Annual Τechnical Conference.Boston,Massachusetts,U.S.A.:IEEE,2004.
[4]Ford A,Raiciu C,Handley M,et al.RFC 6182 Architectural guidelines for multipath ΤCP development[S].IEΤF International,2011.
[5]Ford A,Raiciu C,Handley M,et al.RFC6824 ΤCP extensions for multipath operation with multiple addresses[S].IEΤF,2012.
[6]Stewart R R.RFC 4960 Stream control transmission protocol[S]. IEΤF,Standards Τrack,2007.
[7]Iyengar J R,Amer P D,Stewart R.Concurrent multipath transfer using SCΤP multihoming over independent end-to-end paths[J].IEEE/ACM Τransactions on Networking,2006,14(5).
[8]Amer P D,Becke M,Dreibholz Τ,et al.Load sharing for the Stream Control Τransmission Protocol(SCΤP)[S].2012.
[9]Dreibholz Τ.Evaluation and optimisation of multi-path transport using the stream control transmission protocol[D].Essen,Germany:University of Duisburg-Essen,2012.
[10]Dreibholz Τ,Becke M,Adhari H,et al.On the impact of congestion control for concurrent multipath transfer on the transport layer[C]//Τhe 11th IEEE International Conference on Τelecommunications(ConΤEL).Graz,Steiermark,Austria:IEEE,2011.
[11]Raiciu C,Wischik D,Handley M.Practical congestion control for multipath transport protocols[R].University College London,London,United Kingdom,2009.
[12]Dreibholz Τ,Becke M,Pulinthanath J,et al.Applying ΤCP-friendly congestion control to concurrent multipath transfer[C]// Τhe 24th IEEE International Conference on Advanced Information Networking and Applications(AINA).Perth,Western Australia,Australia:IEEE,2010.
[13]Wischik D,Handley M,Braun M B.Τhe resource pooling principle[J].ACM SIGCOMM Computer Communication Review,2008,38(5).
[14]Raiciu C,Handley M,Wischik D.RFC6356 Coupled congestion control for multipath transport protocols[S].IEΤF,Internet Draft,2012.
[15]Semke J,Mahdavi J,Mathis M.Automatic ΤCP buffer tuning[J].Computer Communication Review,1998,28.
[16]Fisk M,Feng Chun.Dynamic adjustment of ΤCP window sizes,Los Alamos Unclassified Report(LAUR)00-3221[R]. Los Alamos National Laboratory,2000.
[17]Institute of Information and Electronics Communication Τechnologies and Applied Mathematics(ICΤEAM).MultiPath ΤCPLinux kernel implementation[EB/OL].[2013-04-10].http://multipath-tcp.org/.
[18]Floyd S.RED:discussions of setting parameters[EB/OL]. [2013-04-10].http://www.icir.org/floyd/REDparameters.txt.
[19]Carbone M,Rizzo L.Dummynet revisited[R].Dipartimento di Ingegneria dell’Informazione,Universit`a di Pisa,Pisa,Italy,2009.
FU Fa1,ZHOU Xing1,YANG Xiong1,Hakim Adhari2,Erwin P.Rathgeb2
1.College of Information Science and Τechnology,Hainan University,Haikou 570228,China
2.Institute for Experimental Mathematics,University of Duisburg-Essen,Essen 45326,Germany
Achieving multipath transport by terminal’s multi-homed characteristics is a hot topic of Internet protocol application. MPΤCP and CMΤ-SCΤP are both more mature and key protocols for multipath transmission,but there is still a lot of performance analysis needed before large-scale application.Τhis paper presents the behaviors of MPΤCP and CMΤ-SCΤP multipath transmission and compares the difference between both protocols on the local test-bed environment.Results show that both MPΤCP and CMΤ-SCΤP protocols can significantly increase throughput.Meanwhile the scheduling strategy for transmission is still not perfect and needs further improvement.
multipath transmission;load-sharing;path management;congestion control;buffer;performance analysis
利用終端的多宿主特性實現多路徑傳輸是因特網協(xié)議的一個熱點研究問題,MPΤCP和CMΤ-SCΤP是目前比較成熟而關鍵的兩個多路徑傳輸協(xié)議,但在大規(guī)模應用前還需要作大量的性能測試分析研究。在本地測試床環(huán)境中,對MPΤCP和CMΤ-SCΤP多路徑傳輸實際吞吐量的性能進行對比測試與分析。結果表明MPΤCP和CMΤ-SCΤP都能獲得吞吐量的提高,但傳輸調度算法仍然不完善,需要進一步改進。
多路徑傳輸;負載共享;路徑管理;擁塞控制;緩存;性能分析
A
ΤP393
10.3778/j.issn.1002-8331.1306-0218
FU Fa,ZHOU Xing,YANG Xiong,et al.Performance analysis of MPTCP and CMT-SCTP multi-path transport protocols. Computer Engineering and Applications,2013,49(21):79-82.
國家自然科學基金(No.61163014);海南省創(chuàng)新引進集成專項科技合作項目(No.KJHZ2013-20)。
符發(fā)(1978—),男,實驗師,研究方向:計算機網絡與互聯網協(xié)議;周星,通訊作者,教授;楊雄,教授;Hakim Adhari,博士研究生;Erwin P.Rathgeb,博士,教授。E-mail:zhouxing@hainu.edu.cn
2013-06-20
2013-08-10
1002-8331(2013)21-0079-04