王 琨,周 星, 周 峰,譚齊寧,程 璽,符 發(fā),譚毓銀,廖宇力
( 海南大學(xué) 信息科學(xué)技術(shù)學(xué)院,海南 海口 570228)
基于MPTCP路徑管理算法性能分析
王 琨,周 星, 周 峰,譚齊寧,程 璽,符 發(fā),譚毓銀,廖宇力
( 海南大學(xué) 信息科學(xué)技術(shù)學(xué)院,海南 海口 570228)
介紹了MPTCP的4種路徑管理算法,給出了MPTCP路徑管理性能評價指標-帶寬聚合效益(B)因子量化公式,并用其評價測試數(shù)據(jù)結(jié)果以幫助MPTCP協(xié)議研究者定量分析MPTCP的多路徑傳輸性能,最后根據(jù)不同網(wǎng)絡(luò)場景測試,通過性能評價因子(B)的計算證明了Fullmesh路徑管理算法在多路徑傳輸中性能最優(yōu).
多路徑傳輸; MPTCP; 路徑管理; 帶寬聚合效益因子; 性能研究
隨著云計算、大數(shù)據(jù)和物聯(lián)網(wǎng)應(yīng)用不斷深入,網(wǎng)絡(luò)流動的數(shù)據(jù)不斷增大,因此對網(wǎng)絡(luò)提出支持高吞吐量的應(yīng)用需求.IETF提出的基于傳輸層的多路徑并發(fā)傳輸就是不需改變現(xiàn)行網(wǎng)絡(luò)基礎(chǔ)設(shè)施就可以提升網(wǎng)絡(luò)呑吐量、以支撐大體量數(shù)據(jù)應(yīng)用,并得到IT業(yè)界的高度重視,越來越多的研究機構(gòu)及個人正在從事此研究工作.研究者提出多個多路徑傳輸協(xié)議:流控制傳輸協(xié)議(Stream Control Transmission Protocol,SCTP)[1-2]支持多宿主[3-5],基于SCTP擴展的并發(fā)多路徑傳輸協(xié)議(Concurrent Multipath Transfer-Stream Control Transmission Protocol, CMT-SCTP)[6]和MPTCP(Multi-path TCP)[7-9]等. MPTCP及CMT-SCTP是關(guān)于多路徑傳輸?shù)?個具體協(xié)議實現(xiàn),受到了IETF的高度重視.
由于MPTCP能很好地兼容TCP協(xié)議上的應(yīng)用,筆者首先分析了基于MPTCP協(xié)議的4種路徑管理算法對多路徑傳輸性能的影響,其次在此基礎(chǔ)上給出MPTCP帶寬聚合效益因子的量化公式,量化MPTCP的帶寬聚合效益,最后判斷參與并發(fā)傳輸?shù)淖恿魇欠衲軐Χ嗦窂讲l(fā)傳輸?shù)膮淄铝啃阅茉鲩L作貢獻.
MPTCP能夠提供SCTP和TCP相同的功能,其重要的優(yōu)點是向后兼容性,能夠兼容現(xiàn)有TCP[10]的所有應(yīng)用,并提供一個類似中間件的功能,如防火墻、網(wǎng)絡(luò)/端口地址轉(zhuǎn)換路由器,使網(wǎng)絡(luò)能平穩(wěn)地運行.MPTCP是目前在傳輸層上較為成熟且成為研究熱點的多路徑傳輸協(xié)議,也是IETF重點關(guān)注的研究熱點.MPTCP是傳統(tǒng)TCP的擴展.傳統(tǒng)TCP僅支持單路徑傳輸,多路徑傳輸機制的引入使得不改變TCP基礎(chǔ)架構(gòu)能實現(xiàn)多宿主資源的同時利用與共享.MPTCP以資源共享的方式,將數(shù)據(jù)流分發(fā)到多條路徑上進行并行傳輸,以此來提高網(wǎng)絡(luò)吞吐量,支持并行多路傳輸,且兼容TCP和現(xiàn)有網(wǎng)絡(luò)應(yīng)用,滿足網(wǎng)絡(luò)中間件的要求.因此,MPTCP具有廣闊的應(yīng)用前景.但MPTCP仍處于研究階段,一部分研究者通過仿真設(shè)計來部署實驗,對其性能進行評估[11];另一部分研究者的關(guān)注點主要在協(xié)議本身,如協(xié)議的體系結(jié)構(gòu),筆者研究分析數(shù)據(jù)則是基于真實的大規(guī)模多路徑傳輸NorNet國際測試床.目前,MPTCP 處于大規(guī)模實測研究階段,但用帶寬聚合效益因子評價多路徑管理算法并進行實測的研究并不多見.
1.1路徑管理算法及工作原理現(xiàn)有的MPTCP路徑管理只提供了建立、添加與刪除子流(1條TCP 路徑)的方法,其建立路徑連接的工作原理如下:每個 MPTCP 終端都有1個 IP 地址列表,由各接口的IP 地址表組成,是多宿主主機接入的基礎(chǔ).端設(shè)備利用源主機 IP 地址列表和目的主機IP 地址列表,分別構(gòu)建多個IPS(源IP地址)到 IPD(目標IP地址)地址對的 TCP 子流,將數(shù)據(jù)進行分段,然后通過不同的 TCP 子流并行傳輸.2個 MPTCP端設(shè)備先建立正常的 TCP連接,在此過程中, MPTCP使用 MP_CAPABLE TCP 選項告訴對方可使用多路徑傳輸,當初始連接建立完成后,若對方仍有可用子流,則再使用 ADD_ADDR[12]選項建立連接子流并加入到初始建立的連接中傳輸數(shù)據(jù).在MPTCP連接生命周期里,若某個IP地址突然失效不可使用,用REMOVE_ADDR可選項將失效的IP地址從MPTCP連接中刪除,從而斷開跟該IP地址相關(guān)的所有子流.
關(guān)于多路徑傳輸?shù)穆窂焦芾?,是由MPTCP定義.在Linux MPTCP[13]中有4種路徑管理算法.
Default 路徑管理算法 Default 路徑管理算法是MPTCP默認的路徑管理算法. Default路徑管理算法既不會公布不同的IP地址,也沒有啟動創(chuàng)建新子流的功能,但會被動接受創(chuàng)建新子流.MPTCP使用Default路徑管理算法時,與TCP傳輸相比,并不能提高網(wǎng)絡(luò)吞吐量,在此種情況下,多路徑傳輸?shù)腂接近于0甚至等于0,即相當于TCP單路徑傳輸. Default路徑管理算法雖然不能增加帶寬聚合效益B的大小,但被動接受創(chuàng)建新子流的能力可以提升路徑冗余的恢復(fù)能力,工作原理示意圖如圖1所示.
圖1 Default 路徑管理工作原理
Fullmesh 路徑管理算法 Fullmesh 路徑管理算法將所有可以利用的子流全部利用起來,從而達到匯聚子流帶寬實現(xiàn)并行傳輸?shù)哪康腫10].使用此路徑管理算法,性能優(yōu)的子流加入傳輸會使B﹥0,性能差的子流加入傳輸會拖累性能好的子流,使B變小甚至小于0.Fullmesh的工作原理示意圖如圖2所示,MPTCP端設(shè)備HostA和HostB先建立正常的TCP連接,在此過程中,MPTCP使用 MP_CAPABLE TCP 選項告訴對方可以使用多路徑傳輸,當初始連接建立完成后,若對方仍有可用子流,ADD_ADDR選項會將其加入到初始建立的連接中并發(fā)傳輸數(shù)據(jù).最終HostA和 HostB將有PA1—B1,PA1—B2,PA2—B1和PA2—B24條路徑同時并發(fā)傳輸數(shù)據(jù).
圖2 Fullmesh 路徑管理工作原理
Ndiffports 路徑管理算法 Ndiffports 路徑管理算法利用多個不同的應(yīng)用服務(wù)端口來實現(xiàn)并發(fā)傳輸. Ndiffports 路徑管理算法始終使用相同的IP地址與不同的基于TCP的應(yīng)用端口來同時多路復(fù)用TCP.理論上只有當每條子流負載平衡時,B﹥0,即此算法有效,其工作原理示意圖如圖3所示.
Binder[14]路徑管理算法 Binder路徑管理算法將松散源路由(Loose Source and Record Routing,LSRR)選項添加到MPTCP,以確保MPTCP子流使用所有可用的網(wǎng)關(guān),即采用LSRR分發(fā)子流的數(shù)據(jù)包. Binder路徑管理算法允許用戶終端設(shè)備從網(wǎng)關(guān)直接獲得更高的網(wǎng)絡(luò)吞吐量,而不需要進行任何修改,可用圖4 a和b說明其工作原理.理論上,只有在網(wǎng)絡(luò)中設(shè)置了LSRR選項,才能使其B﹥0,從而使得Binder路徑管理算法發(fā)揮良好的效果.
圖3 Ndiffports 路徑管理工作原理
圖4 Binder 路徑管理工作原理
1.2擁塞控制算法除路徑管理算法外,擁塞控制算法也是對網(wǎng)絡(luò)中流量與負載均衡進行控制的協(xié)議.擁塞控制算法不僅對網(wǎng)絡(luò)資源進行更合理分配和利用,并能更好地確保在進行多路徑傳輸時保持其流量的公平性.目前用于多路徑傳輸?shù)膿砣刂扑惴ㄓ卸喾N,如Cubic,Reno,Dctcp,Bic,Hybla,Balia,Lia,Olia和Vegas等.為了更好地分析子流的加入對B的影響,筆者主要使用2種擁塞控制算法:
1) Cubic是基于Linux的TCP和MPTCP的默認擁塞控制算法,屬于非耦合算法,但對于多路徑傳輸來講,當不同的子流共享共同瓶頸時,是不公平的,具有資源搶占性.
2) OLIA (Opportunistic LIA)是LIA算法的更新版,是 Linux MPTCP中耦合算法之一,其基本思路是通過共享瓶頸解決非耦合算法的不公平性問題.
2.1帶寬聚合效益B定義評價多路徑傳輸帶寬聚合性能的指標叫帶寬聚合效益因子,用B表示.B為與單路徑傳輸(如TCP)相比,多路徑傳輸?shù)膸捑酆闲б娴拇笮?,其取值可?∞~+∞ 之間,即當 MPTCP 的帶寬高于 TCP 時,B>0;當 MPTCP 的帶寬等于 TCP 時,B=0;當 MPTCP 的帶寬小于 TCP 時,B<0,其數(shù)學(xué)表達
(1)
圖5給出了帶寬聚合效益因子B的圖示說明,解釋了多路徑并發(fā)傳輸協(xié)議應(yīng)當考慮如何基于整體多路徑傳輸性能的提高而采取相應(yīng)的措施.圖5中第一象限區(qū)域是B﹥0的子流,意味著該子流可以加以利用,并能改進或提高帶寬聚合效益,應(yīng)當充分利用并激活該子流;而B<0落入第二象限區(qū)域的子流對整體性能的提升是不利的,不應(yīng)當加以利用.
圖5 帶寬聚合效益度量指標B 示意圖
綜上所述,期待每個子流的加入提高整體的聚合帶寬.但根據(jù)文獻和實驗分析得知,并不是所有的子流的加入都會提高整體的聚合帶寬,如何根據(jù)當前使用的路徑管理算法判斷加入傳輸?shù)淖恿髀窂綄Χ嗦窂絺鬏斒欠裼胸暙I,筆者重定義了MPTCP路徑管理性能評價指標-帶寬聚合效益(B)的內(nèi)涵,并用其評價了測試數(shù)據(jù)結(jié)果來評判路徑管理算法的優(yōu)劣,并幫助MPTCP協(xié)議研究者量化MPTCP的多路徑傳輸性能.
2.2帶寬聚合效益B量化設(shè)計B為帶寬聚合效益因子,表示與單路徑傳輸(如TCP)相比,多路徑傳輸?shù)膸捑酆闲б嬉蜃拥拇笮?因此,B的數(shù)學(xué)量化
(2)
其中,MPTCP_APT (MPTCP Application Payload Throughout)表示使用MPTCP多路徑傳輸時網(wǎng)絡(luò)應(yīng)用的有效載荷吞吐量;TCP_APT (TCP Application Payload Throughout)表示使用TCP單路徑傳輸時網(wǎng)絡(luò)應(yīng)用的有效載荷吞吐量.
本文所獲得的研究分析數(shù)據(jù)均來源于NorNet國際測試床[15]的測試結(jié)果.NorNet是由挪威Simula國家實驗室主導(dǎo)構(gòu)建的一個大規(guī)模分布式國際測試平臺,海南大學(xué)擁有亞洲第一個在該測試床上上線的測試站點HU-NNC-Site(HainanUniversity NorNet Core-Site),以下簡稱HU.
3.1測試場景設(shè)計實驗的帶寬通過工具NetPerfMeter測量,能為多個協(xié)議提供傳輸連接的性能對比,包括支持MPTCP.實驗數(shù)據(jù)結(jié)果都是通過GNU R進行處理,每組實驗結(jié)果為運行20次的均值.實驗結(jié)果圖通過實驗運行300 s來顯示出平均的有效載荷吞吐量,實驗的置信區(qū)間為95%.
實驗使用的NorNet國際測試床跨越歐、亞、美、澳四大洲,因此根據(jù)站點間的距離長短不同(跨海、跨洲等不同情況)和提供服務(wù)的供應(yīng)商情況不同(提供網(wǎng)絡(luò)帶寬高低不同分為高速網(wǎng)、低速網(wǎng)),為了展示出路徑管理算法和擁塞控制算法的設(shè)置不同帶來的影響,選擇多個站點進行實驗,最終選擇3個不同的具有代表性的測試場景進行分析.
場景1設(shè)計:測試德國杜伊斯堡-埃森大學(xué)(位于歐洲,有2個網(wǎng)絡(luò)供應(yīng)商,UDE)與中國海南大學(xué)(位于亞洲,有2個網(wǎng)絡(luò)供應(yīng)商,HU)之間的網(wǎng)絡(luò)通訊.
場景2設(shè)計:測試中國海南大學(xué)(位于亞洲,有2個網(wǎng)絡(luò)供應(yīng)商,HU) 與韓國高麗大學(xué)(位于亞洲,有1個網(wǎng)絡(luò)供應(yīng)商,KRU) 之間的網(wǎng)絡(luò)通訊.
場景3設(shè)計:測試挪威特隆赫姆師范大學(xué)(位于歐洲,有2個網(wǎng)絡(luò)供應(yīng)商,NTNU) 與挪威納威克大學(xué)(位于歐洲,有3個網(wǎng)絡(luò)供應(yīng)商,HiN) 之間的網(wǎng)絡(luò)通訊.
具體站點信息如表1所示.其中,綠色表示提供高速連接的網(wǎng)絡(luò)供應(yīng)商;而藍色表示提供低速連接網(wǎng)絡(luò)供應(yīng)商(在某些情況下網(wǎng)速高達16 Mib·s-1,ADSL連接上標標有“A”).
表1 使用站點信息
3.2測試結(jié)果分析在表2、3和4中的d表示Default算法,n表示Ndiffports算法,b表示Binder算法,f表示Fullmesh算法,c表示Cubic算法,o表示OLIA算法.
圖6 UDE->HU MPTCP 長期測試結(jié)果
圖6為UDE到 HU站點之間的MPTCP平均有效載荷吞吐量結(jié)果,表示在不同的路徑管理算法與擁塞控制算法作用下,以4條不同的初始路徑建立連接后再加入其他路徑的有效載荷吞吐量.從圖6可知,F(xiàn)ullmesh路徑管理算法展現(xiàn)了最佳傳輸性能,從傳輸性能角度分析,Cubic算法略強于OLIA算法.
表2 UDE-> HU 帶寬聚合效益B的計算結(jié)果
為了對該場景下各種情況進行更為直觀清晰的對比,根據(jù)式(2)計算B,如表2所示.其中D-C表示DFN-CERNET,D-Cn表示DFN-CnUnicom,V-C表示Versatel-CERNET,V-Cn表示Versatel-CnUnicom.從表2可知,當使用Fullmesh算法進行MPTCP多路徑傳輸時,B始終大于0,此時能獲得較高的網(wǎng)絡(luò)吞吐量;對Cubic和OLIA算法進行比較,可以看出在使用同種路徑管理算法進行MPTCP多路徑傳輸時,大部分情況下使用Cubic算法的B較大,即通常情況下,使用Cubic擁塞控制算法能獲得較高的網(wǎng)絡(luò)通信性能.
通過對比表2中的4條路徑,可以看到一個非常有意思的現(xiàn)象,在相同的情況下,V-Cn的B最大,D-Cn的B最小,以f/c為例,V-Cn的B=65,D-Cn的B=0.26,但從圖6可以明顯看出最佳路徑為D-Cn,而V-Cn是通信性能最差的路徑,此現(xiàn)象的出現(xiàn)原因是使用性能較好的路徑作為初始路徑時,其他性能差的路徑加入傳輸對帶寬聚合并沒有太大提高甚至可能降低整體的帶寬;而當用性能較差的路徑作為初始路徑,加入性能好的路徑,能夠極大的提高帶寬聚合度,對傳輸帶寬有較大的提高.當V-Cn作為初始路徑進行多路徑傳輸時,其他子流的加入均能使其B>0;但D-Cn作為初始路徑進行多路徑傳輸僅使用Fullmesh算法,其他子流加入其B>0;其他情況下,加入任何子流均對其有害無益,明顯Fullmesh算法性能更優(yōu).
通過實驗分析,可以得知Ndiffports和Binder 路徑管理算法的性能正如理論分析所示,其B基本等于0,即對帶寬并沒有什么提高,性能較差,因此以下2個場景中將其省略.
圖7 HU-KRU MPTCP 長期測試結(jié)果
圖7為HU到 KRU站點之間的MPTCP平均有效載荷吞吐量結(jié)果,可以清楚看出不同路徑管理算法和擁塞控制算法在不同初始路徑下的表現(xiàn).
表3 HU-KRU 帶寬聚合效益B的計算結(jié)果
為了從數(shù)據(jù)的角度更有力的說明路徑管理算法的優(yōu)劣,根據(jù)B公式進行計算,具體計算結(jié)果如表3.其中,C-K表示CERNET-KREONET,Cn-K 表示CnUnicom-KREONET.從表中,可以清楚看到使用default算法進行多路徑傳輸時,2條路徑的B接近于0(C-K在2種擁塞控制算法作用下B=-0.06;Cn-K使用Cubic時,B=-0.01,使用Olia時B=0.14),這是因為其類似于TCP單路徑傳輸,但另一條路徑的存在仍對其有微小的負面影響,可以推測2條路徑的性能不是太好,此時路徑管理算法性能較差.但使用Fullmesh算法進行多路徑傳輸時,由于2條路徑本身的性能相差不大,不管哪條作為初始路徑,另一條子流加入傳輸后,B>0,即2條子流的加入均能提高網(wǎng)絡(luò)的整體吞吐量,但C-K的B明顯大于Cn-K的B(使用Cubic時,C-K 的B=4.06,Cn-K的B=0.15,4.06>0.15;使用Olia時C-K的B=2.47,Cn-K的B=0.05,2.47>0.05),即Cn-K加入已存在的C-K進行多路徑傳輸?shù)玫降膸捑酆洗笥贑-K加入已存在的Cn-K進行多路徑傳輸?shù)玫降膸捑酆希馕吨鳦n-K加入多路徑傳輸能提高網(wǎng)絡(luò)的通信性能,此時的路徑管理算法性能較好.同樣,可以看出使用Cubic算法B大于使用OLIA算法的B,即使用Cubic算法時,其他子流的加入更能提高整體的網(wǎng)絡(luò)吞吐量.此2個場景下Cubic算法始終較好于OLIA算法,但并不總是這樣,下面有個反例.
圖8 NTNU-HiN MPTCP 長期測試結(jié)果
圖8為NTNU到HiN站點之間的MPTCP平均有效載荷吞吐量結(jié)果.同時,其對應(yīng)B在表4中可以找到,其中,P-B表示PowerTech-Broadnet,P-P表示PowerTech-PowerTech,P-U表示PowerTech-Uninett,U-B表示Uninett-Broadnet,U-P表示Uninett-PowerTech, U-U表示Uninett-Uninett.
表4 NTNU-HiN 帶寬聚合效益B的計算結(jié)果
從表4中可以看出當U-U為初始路徑時,B﹤0(d/c的B=-0.01,d/o的B=-0.06,f/c的B=-0.01,f/o的B=-0.01),即其他路徑的加入均降低其網(wǎng)絡(luò)整體的吞吐量.而當其他路徑作為初始路徑,使用default算法時,B接近于0,即此時的路徑管理算法性能較差;使用Fullmesh算法時,U-U加入后,B大大增加,意味著該路徑對網(wǎng)絡(luò)整體吞吐量有貢獻,即此時的路徑管理算法性能較好;但使用OLIA算法的B此時均大于Cubic算法的B,這是因為此時ADSL 路徑丟包率較高,使得路徑的擁塞窗口減小,從而產(chǎn)生了此現(xiàn)象.從性能優(yōu)劣的角度分析,在該場景下,進行多路徑傳輸時,推薦Fullmesh算法和OLIA算法.
綜上所述,針對多路徑傳輸協(xié)議MPTCP 的多個測試場景,對其測試分析,根據(jù)網(wǎng)絡(luò)帶寬聚合效益B的定義,提出B的計算公式,并從B的角度統(tǒng)計分析了路徑管理算法的性能,驗證了算法的理論分析即MPTCP使用Default路徑管理算法時僅相當于TCP單路徑傳輸,此時B基本接近于0甚至等于0;Ndiffports和 Binder路徑管理算法僅在特殊場景(網(wǎng)關(guān)負載均衡)中能得到有效的利用,因此對多路徑傳輸并貢獻不明顯,即在特殊設(shè)置的網(wǎng)絡(luò)環(huán)境下B﹥0;只有Fullmesh路徑管理算法無需在意初始路徑,能獲得較高的吞吐量,可以提供帶寬聚合的好處,使用此路徑管理算法,性能優(yōu)的子流加入傳輸B﹥0,性能差的子流加入傳輸會拖累性能好的子流,使B變小甚至小于0.
研究了MPTCP的4種路徑管理算法對多路徑傳輸呑吐量性能的影響,測試結(jié)果分析表明Fullmesh路徑管理算法在多路徑傳輸中性能最優(yōu),同時重定義了帶寬聚合效益B的內(nèi)涵,并用其評價驗證了4種路徑算法與相應(yīng)的擁塞控制算法共同作用下對傳輸呑吐量的性能的影響,結(jié)果表明B可以作為其衡量多路徑子流對整體通信性能是貢獻還是拖累的重要指標.下一步工作的重點,對不同的子流進行更細粒度地分析,使其能用B自動化地確定多路徑子流是否可以參與多路徑的并發(fā)傳輸,根據(jù)此思想改進路徑管理算法,并修改MPTCP的內(nèi)核,真正達到通過多路徑傳輸提高帶寬的目的.
[1] Eklund J. Latency Reduction for soft real-time Trac using SCTP multihoming[D]. Karlstads:Karlstads Universitet,2016.
[2] Dreibholz T. Reliable server pooling-evaluation, optimization and extension of a Novel IETF architecture[D]. North Rhine-Westphalia:University of Duisburg Essen,2007.
[3] Amer P D,Becke M, Dreibholz T, et al. Load sharing for the stream control transmission protocol (SCTP)[EB/OL]. [2016-12-24].https://www.researchgate.net/publication/260814769_Load_Sharing_for_the_Stream_Control_Transmission_Protocol_SCTP.
[4] Dreibholz T. Evaluation and optimisation of multi-path transport using the stream control transmission protocol [D]. North Rhine-Westphalia:University of Duisburg Essen,2012.
[5] Yedugundla K V, Ferlin S, Dreibholz T, et al. Is multi-path transport suitable for latency sensitive Trac?[J]. Computer Networks, 2016(105):1-21.
[6] Dreibholz T, Rwngeler I, Seggelmann R, et al. Stream control transmission protocol: past, current, and future standardization activities[J]. IEEE Communications Magazine, 2011, 49(4):82-88.
[7] Scharf M, Ford A. Multipath TCP (MPTCP) application interface considerations [EB/OL]. [2016-12-24]. http://ftp.tudelft.nl/rfc/rfc6897.txt.pdf.
[8] Ford A, Raiciu C, Handley M, et al. TCP extensions for multipath operation with multiple addresses[EB/OL]. [2016-12-30].http://ftp.vim.org/ftp/ftp/ftp/ftp/documents/rfc/rfc6824.txt.pdf.
[9] 劉鵬. 基于MPTCP的路徑管理研究[D]. 重慶:重慶郵電大學(xué), 2013.
[10] Becke M, Adhari H, Rathgeb E P, et al. Comparison of multipath TCP and CMT-SCTP based on intercontinental measurements: proceedings of Global Communications Conference (GLOBECOM), Atlanta, December 9-13, 2013[C].[S.l.]:IEEE, 2013.
[11] 劉驥, 譚毓銀, 符發(fā),等. MPTCP與CMT-SCTP擁塞控制機制研究[J]. 計算機工程, 2015, 41(4):117-124.
[12] 符發(fā), 周星, 譚毓銀,等. 多場景的MPTCP協(xié)議性能分析研究[J]. 計算機工程與應(yīng)用, 2016, 52(5):89-93.
[13] Raiciu C, Paasch C, Barre S, et al. How hard can it be? designing and implementing a deployable multipath TCP: proceedings of the 9th USENIX Conference on Networked Systems Design and Implementation (NSDI),San Jose, April 25-27,2012[C].[S.l.]:IEEE,2012.
[14] Boccassi L, Fayed M M, Marina M M. Binder: a system to aggregate multiple internet gateways in community networks: proceedings of the 2013 ACM MobiCom workshop on Lowest cost denominator networking for universal access,Miami, September 30-October 4,2013[C].[S.l.]:IEEE,2013.
[15] Dreibholz T, Bjorgeengen J, Werme J. Maintaining and monitoring the infrastructure of the NORNET CORE testbed for multi-homed systems: proceedings of International Conference on Advanced Information NETWORKING and Applications Workshops. Gwangju, March 25- 27, 2015 [C].[S.l.]:IEEE, 2015.
Abstract: In the report, the four path management algorithms of MPTCP were introduced. The quantitative formula of the MPTCP path management performance evaluation index-bandwidth aggregation benefit (B) factor was proposed, and which was used to evaluate the test data in order to help researcher quantify the bandwidth aggregation benefit of MPTCP. According to the different network scene test, the conclusion that full mesh path management algorithm has the best performance was demonstrated by the calculation of the performance evaluation index (B).
Keywords:Multipath; Multi-Path TCP(MPTCP); path management; bandwidth benefit factor; performance analysis
PerformanceAnalysisofMPTCPPathManagementAlgorithm
Wang Kun, Zhou Xing, Zhou Feng, Tan Qining, Cheng Xi, Fu Fa, Tan Yuyin, Liao Yuli
(College of Information Science and Technology, Hainan University, Haikou 570228, China)
TP 305
A DOl:10.15886/j.cnki.hdxbzkb.2017.0035
2016-05-05
國家自然科學(xué)基金(61363008,61662020)
王琨(1991-),女,山東棗莊人,海南大學(xué)信息科學(xué)技術(shù)學(xué)院2014級碩士研究生,研究方向:下一代互聯(lián)網(wǎng),E-mail:780952372@qq.com
周星(1958- ) ,女,重慶沙坪壩人,教授,主要研究方向:下一代互聯(lián)網(wǎng)協(xié)議分析,E-mail:xingzhou50@126.com
1004-1729(2017)03-0211-08