王 琨,周 星, 周 峰,譚齊寧,程 璽,符 發(fā),譚毓銀,廖宇力

( 海南大學(xué) 信息科學(xué)技術(shù)學(xué)院，海南 ?？?570228)

基于MPTCP路徑管理算法性能分析

王 琨,周 星, 周 峰,譚齊寧,程 璽,符 發(fā),譚毓銀,廖宇力

( 海南大學(xué) 信息科學(xué)技術(shù)學(xué)院，海南 海口 570228)

介紹了MPTCP的4種路徑管理算法，給出了MPTCP路徑管理性能評價(jià)指標(biāo)-帶寬聚合效益(B)因子量化公式，并用其評價(jià)測試數(shù)據(jù)結(jié)果以幫助MPTCP協(xié)議研究者定量分析MPTCP的多路徑傳輸性能,最后根據(jù)不同網(wǎng)絡(luò)場景測試，通過性能評價(jià)因子(B)的計(jì)算證明了Fullmesh路徑管理算法在多路徑傳輸中性能最優(yōu).

多路徑傳輸； MPTCP； 路徑管理； 帶寬聚合效益因子； 性能研究

隨著云計(jì)算、大數(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è)界的高度重視，越來越多的研究機(jī)構(gòu)及個(gè)人正在從事此研究工作.研究者提出多個(gè)多路徑傳輸協(xié)議:流控制傳輸協(xié)議(Stream Control Transmission Protocol，SCTP)[1-2]支持多宿主[3-5]，基于SCTP擴(kuò)展的并發(fā)多路徑傳輸協(xié)議(Concurrent Multipath Transfer-Stream Control Transmission Protocol, CMT-SCTP)[6]和MPTCP(Multi-path TCP)[7-9]等. MPTCP及CMT-SCTP是關(guān)于多路徑傳輸?shù)?個(gè)具體協(xié)議實(shí)現(xiàn)，受到了IETF的高度重視.

由于MPTCP能很好地兼容TCP協(xié)議上的應(yīng)用，筆者首先分析了基于MPTCP協(xié)議的4種路徑管理算法對多路徑傳輸性能的影響，其次在此基礎(chǔ)上給出MPTCP帶寬聚合效益因子的量化公式，量化MPTCP的帶寬聚合效益，最后判斷參與并發(fā)傳輸?shù)淖恿魇欠衲軐Χ嗦窂讲l(fā)傳輸?shù)膮淄铝啃阅茉鲩L作貢獻(xiàn).

1 MPTCP

MPTCP能夠提供SCTP和TCP相同的功能，其重要的優(yōu)點(diǎn)是向后兼容性，能夠兼容現(xiàn)有TCP[10]的所有應(yīng)用，并提供一個(gè)類似中間件的功能，如防火墻、網(wǎng)絡(luò)/端口地址轉(zhuǎn)換路由器，使網(wǎng)絡(luò)能平穩(wěn)地運(yùn)行.MPTCP是目前在傳輸層上較為成熟且成為研究熱點(diǎn)的多路徑傳輸協(xié)議，也是IETF重點(diǎn)關(guān)注的研究熱點(diǎn).MPTCP是傳統(tǒng)TCP的擴(kuò)展.傳統(tǒng)TCP僅支持單路徑傳輸，多路徑傳輸機(jī)制的引入使得不改變TCP基礎(chǔ)架構(gòu)能實(shí)現(xiàn)多宿主資源的同時(shí)利用與共享.MPTCP以資源共享的方式，將數(shù)據(jù)流分發(fā)到多條路徑上進(jìn)行并行傳輸，以此來提高網(wǎng)絡(luò)吞吐量，支持并行多路傳輸，且兼容TCP和現(xiàn)有網(wǎng)絡(luò)應(yīng)用，滿足網(wǎng)絡(luò)中間件的要求.因此，MPTCP具有廣闊的應(yīng)用前景.但MPTCP仍處于研究階段，一部分研究者通過仿真設(shè)計(jì)來部署實(shí)驗(yàn)，對其性能進(jìn)行評估[11]；另一部分研究者的關(guān)注點(diǎn)主要在協(xié)議本身，如協(xié)議的體系結(jié)構(gòu)，筆者研究分析數(shù)據(jù)則是基于真實(shí)的大規(guī)模多路徑傳輸NorNet國際測試床.目前，MPTCP 處于大規(guī)模實(shí)測研究階段，但用帶寬聚合效益因子評價(jià)多路徑管理算法并進(jìn)行實(shí)測的研究并不多見.

1.1路徑管理算法及工作原理現(xiàn)有的MPTCP路徑管理只提供了建立、添加與刪除子流(1條TCP 路徑)的方法，其建立路徑連接的工作原理如下：每個(gè) MPTCP 終端都有1個(gè) IP 地址列表，由各接口的IP 地址表組成，是多宿主主機(jī)接入的基礎(chǔ).端設(shè)備利用源主機(jī) IP 地址列表和目的主機(jī)IP 地址列表，分別構(gòu)建多個(gè)IPS(源IP地址)到 IPD(目標(biāo)IP地址)地址對的 TCP 子流，將數(shù)據(jù)進(jìn)行分段，然后通過不同的 TCP 子流并行傳輸.2個(gè) MPTCP端設(shè)備先建立正常的 TCP連接，在此過程中， MPTCP使用 MP_CAPABLE TCP 選項(xiàng)告訴對方可使用多路徑傳輸，當(dāng)初始連接建立完成后，若對方仍有可用子流，則再使用 ADD_ADDR[12]選項(xiàng)建立連接子流并加入到初始建立的連接中傳輸數(shù)據(jù).在MPTCP連接生命周期里，若某個(gè)IP地址突然失效不可使用，用REMOVE_ADDR可選項(xiàng)將失效的IP地址從MPTCP連接中刪除，從而斷開跟該IP地址相關(guān)的所有子流.

關(guān)于多路徑傳輸?shù)穆窂焦芾恚怯蒑PTCP定義.在Linux MPTCP[13]中有4種路徑管理算法.

Default 路徑管理算法 Default 路徑管理算法是MPTCP默認(rèn)的路徑管理算法. Default路徑管理算法既不會公布不同的IP地址，也沒有啟動創(chuàng)建新子流的功能，但會被動接受創(chuàng)建新子流.MPTCP使用Default路徑管理算法時(shí)，與TCP傳輸相比，并不能提高網(wǎng)絡(luò)吞吐量，在此種情況下，多路徑傳輸?shù)腂接近于0甚至等于0，即相當(dāng)于TCP單路徑傳輸. Default路徑管理算法雖然不能增加帶寬聚合效益B的大小，但被動接受創(chuàng)建新子流的能力可以提升路徑冗余的恢復(fù)能力，工作原理示意圖如圖1所示.

圖1 Default 路徑管理工作原理

Fullmesh 路徑管理算法 Fullmesh 路徑管理算法將所有可以利用的子流全部利用起來，從而達(dá)到匯聚子流帶寬實(shí)現(xiàn)并行傳輸?shù)哪康腫10].使用此路徑管理算法，性能優(yōu)的子流加入傳輸會使B﹥0，性能差的子流加入傳輸會拖累性能好的子流，使B變小甚至小于0.Fullmesh的工作原理示意圖如圖2所示，MPTCP端設(shè)備HostA和HostB先建立正常的TCP連接，在此過程中，MPTCP使用 MP_CAPABLE TCP 選項(xiàng)告訴對方可以使用多路徑傳輸，當(dāng)初始連接建立完成后，若對方仍有可用子流，ADD_ADDR選項(xiàng)會將其加入到初始建立的連接中并發(fā)傳輸數(shù)據(jù).最終HostA和 HostB將有PA1—B1，PA1—B2，PA2—B1和PA2—B24條路徑同時(shí)并發(fā)傳輸數(shù)據(jù).

圖2 Fullmesh 路徑管理工作原理

Ndiffports 路徑管理算法 Ndiffports 路徑管理算法利用多個(gè)不同的應(yīng)用服務(wù)端口來實(shí)現(xiàn)并發(fā)傳輸. Ndiffports 路徑管理算法始終使用相同的IP地址與不同的基于TCP的應(yīng)用端口來同時(shí)多路復(fù)用TCP.理論上只有當(dāng)每條子流負(fù)載平衡時(shí)，B﹥0，即此算法有效，其工作原理示意圖如圖3所示.

Binder[14]路徑管理算法 Binder路徑管理算法將松散源路由(Loose Source and Record Routing，LSRR)選項(xiàng)添加到MPTCP，以確保MPTCP子流使用所有可用的網(wǎng)關(guān)，即采用LSRR分發(fā)子流的數(shù)據(jù)包. Binder路徑管理算法允許用戶終端設(shè)備從網(wǎng)關(guān)直接獲得更高的網(wǎng)絡(luò)吞吐量，而不需要進(jìn)行任何修改，可用圖4 a和b說明其工作原理.理論上，只有在網(wǎng)絡(luò)中設(shè)置了LSRR選項(xiàng)，才能使其B﹥0，從而使得Binder路徑管理算法發(fā)揮良好的效果.

圖3 Ndiffports 路徑管理工作原理

圖4 Binder 路徑管理工作原理

1.2擁塞控制算法除路徑管理算法外，擁塞控制算法也是對網(wǎng)絡(luò)中流量與負(fù)載均衡進(jìn)行控制的協(xié)議.擁塞控制算法不僅對網(wǎng)絡(luò)資源進(jìn)行更合理分配和利用，并能更好地確保在進(jìn)行多路徑傳輸時(shí)保持其流量的公平性.目前用于多路徑傳輸?shù)膿砣刂扑惴ㄓ卸喾N，如Cubic，Reno，Dctcp，Bic，Hybla，Balia，Lia，Olia和Vegas等.為了更好地分析子流的加入對B的影響，筆者主要使用2種擁塞控制算法：

1) Cubic是基于Linux的TCP和MPTCP的默認(rèn)擁塞控制算法，屬于非耦合算法，但對于多路徑傳輸來講，當(dāng)不同的子流共享共同瓶頸時(shí)，是不公平的，具有資源搶占性.

2) OLIA (Opportunistic LIA)是LIA算法的更新版，是 Linux MPTCP中耦合算法之一，其基本思路是通過共享瓶頸解決非耦合算法的不公平性問題.

2 性能評價(jià)指標(biāo)

2.1帶寬聚合效益B定義評價(jià)多路徑傳輸帶寬聚合性能的指標(biāo)叫帶寬聚合效益因子，用B表示.B為與單路徑傳輸(如TCP)相比，多路徑傳輸?shù)膸捑酆闲б娴拇笮。淙≈悼稍?∞～+∞ 之間，即當(dāng) MPTCP 的帶寬高于 TCP 時(shí)，B>0；當(dāng) MPTCP 的帶寬等于 TCP 時(shí)，B=0；當(dāng) MPTCP 的帶寬小于 TCP 時(shí)，B<0，其數(shù)學(xué)表達(dá)

(1)

圖5給出了帶寬聚合效益因子B的圖示說明，解釋了多路徑并發(fā)傳輸協(xié)議應(yīng)當(dāng)考慮如何基于整體多路徑傳輸性能的提高而采取相應(yīng)的措施.圖5中第一象限區(qū)域是B﹥0的子流，意味著該子流可以加以利用，并能改進(jìn)或提高帶寬聚合效益，應(yīng)當(dāng)充分利用并激活該子流；而B<0落入第二象限區(qū)域的子流對整體性能的提升是不利的，不應(yīng)當(dāng)加以利用.

圖5 帶寬聚合效益度量指標(biāo)B 示意圖

綜上所述，期待每個(gè)子流的加入提高整體的聚合帶寬.但根據(jù)文獻(xiàn)和實(shí)驗(yàn)分析得知，并不是所有的子流的加入都會提高整體的聚合帶寬，如何根據(jù)當(dāng)前使用的路徑管理算法判斷加入傳輸?shù)淖恿髀窂綄Χ嗦窂絺鬏斒欠裼胸暙I(xiàn)，筆者重定義了MPTCP路徑管理性能評價(jià)指標(biāo)-帶寬聚合效益(B)的內(nèi)涵，并用其評價(jià)了測試數(shù)據(jù)結(jié)果來評判路徑管理算法的優(yōu)劣，并幫助MPTCP協(xié)議研究者量化MPTCP的多路徑傳輸性能.

2.2帶寬聚合效益B量化設(shè)計(jì)B為帶寬聚合效益因子，表示與單路徑傳輸(如TCP)相比，多路徑傳輸?shù)膸捑酆闲б嬉蜃拥拇笮?因此，B的數(shù)學(xué)量化

(2)

其中，MPTCP_APT (MPTCP Application Payload Throughout)表示使用MPTCP多路徑傳輸時(shí)網(wǎng)絡(luò)應(yīng)用的有效載荷吞吐量；TCP_APT (TCP Application Payload Throughout)表示使用TCP單路徑傳輸時(shí)網(wǎng)絡(luò)應(yīng)用的有效載荷吞吐量.

3 實(shí)驗(yàn)設(shè)計(jì)與結(jié)果分析

本文所獲得的研究分析數(shù)據(jù)均來源于NorNet國際測試床[15]的測試結(jié)果.NorNet是由挪威Simula國家實(shí)驗(yàn)室主導(dǎo)構(gòu)建的一個(gè)大規(guī)模分布式國際測試平臺，海南大學(xué)擁有亞洲第一個(gè)在該測試床上上線的測試站點(diǎn)HU-NNC-Site(HainanUniversity NorNet Core-Site)，以下簡稱HU.

3.1測試場景設(shè)計(jì)實(shí)驗(yàn)的帶寬通過工具NetPerfMeter測量，能為多個(gè)協(xié)議提供傳輸連接的性能對比，包括支持MPTCP.實(shí)驗(yàn)數(shù)據(jù)結(jié)果都是通過GNU R進(jìn)行處理，每組實(shí)驗(yàn)結(jié)果為運(yùn)行20次的均值.實(shí)驗(yàn)結(jié)果圖通過實(shí)驗(yàn)運(yùn)行300 s來顯示出平均的有效載荷吞吐量，實(shí)驗(yàn)的置信區(qū)間為95%.

實(shí)驗(yàn)使用的NorNet國際測試床跨越歐、亞、美、澳四大洲，因此根據(jù)站點(diǎn)間的距離長短不同(跨海、跨洲等不同情況)和提供服務(wù)的供應(yīng)商情況不同(提供網(wǎng)絡(luò)帶寬高低不同分為高速網(wǎng)、低速網(wǎng))，為了展示出路徑管理算法和擁塞控制算法的設(shè)置不同帶來的影響，選擇多個(gè)站點(diǎn)進(jìn)行實(shí)驗(yàn)，最終選擇3個(gè)不同的具有代表性的測試場景進(jìn)行分析.

場景1設(shè)計(jì)：測試德國杜伊斯堡-埃森大學(xué)(位于歐洲，有2個(gè)網(wǎng)絡(luò)供應(yīng)商，UDE)與中國海南大學(xué)(位于亞洲，有2個(gè)網(wǎng)絡(luò)供應(yīng)商，HU)之間的網(wǎng)絡(luò)通訊.

場景2設(shè)計(jì)：測試中國海南大學(xué)(位于亞洲，有2個(gè)網(wǎng)絡(luò)供應(yīng)商，HU) 與韓國高麗大學(xué)(位于亞洲，有1個(gè)網(wǎng)絡(luò)供應(yīng)商，KRU) 之間的網(wǎng)絡(luò)通訊.

場景3設(shè)計(jì)：測試挪威特隆赫姆師范大學(xué)(位于歐洲，有2個(gè)網(wǎng)絡(luò)供應(yīng)商，NTNU) 與挪威納威克大學(xué)(位于歐洲，有3個(gè)網(wǎng)絡(luò)供應(yīng)商，HiN) 之間的網(wǎng)絡(luò)通訊.

具體站點(diǎn)信息如表1所示.其中，綠色表示提供高速連接的網(wǎng)絡(luò)供應(yīng)商；而藍(lán)色表示提供低速連接網(wǎng)絡(luò)供應(yīng)商(在某些情況下網(wǎng)速高達(dá)16 Mib·s-1，ADSL連接上標(biāo)標(biāo)有“A”).

表1 使用站點(diǎn)信息

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站點(diǎn)之間的MPTCP平均有效載荷吞吐量結(jié)果，表示在不同的路徑管理算法與擁塞控制算法作用下，以4條不同的初始路徑建立連接后再加入其他路徑的有效載荷吞吐量.從圖6可知，F(xiàn)ullmesh路徑管理算法展現(xiàn)了最佳傳輸性能，從傳輸性能角度分析，Cubic算法略強(qiáng)于OLIA算法.

表2 UDE-> HU 帶寬聚合效益B的計(jì)算結(jié)果

為了對該場景下各種情況進(jìn)行更為直觀清晰的對比，根據(jù)式(2)計(jì)算B，如表2所示.其中D-C表示DFN-CERNET，D-Cn表示DFN-CnUnicom，V-C表示Versatel-CERNET，V-Cn表示Versatel-CnUnicom.從表2可知，當(dāng)使用Fullmesh算法進(jìn)行MPTCP多路徑傳輸時(shí)，B始終大于0，此時(shí)能獲得較高的網(wǎng)絡(luò)吞吐量；對Cubic和OLIA算法進(jìn)行比較，可以看出在使用同種路徑管理算法進(jìn)行MPTCP多路徑傳輸時(shí)，大部分情況下使用Cubic算法的B較大，即通常情況下，使用Cubic擁塞控制算法能獲得較高的網(wǎng)絡(luò)通信性能.

通過對比表2中的4條路徑，可以看到一個(gè)非常有意思的現(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)原因是使用性能較好的路徑作為初始路徑時(shí)，其他性能差的路徑加入傳輸對帶寬聚合并沒有太大提高甚至可能降低整體的帶寬；而當(dāng)用性能較差的路徑作為初始路徑，加入性能好的路徑，能夠極大的提高帶寬聚合度，對傳輸帶寬有較大的提高.當(dāng)V-Cn作為初始路徑進(jìn)行多路徑傳輸時(shí)，其他子流的加入均能使其B>0；但D-Cn作為初始路徑進(jìn)行多路徑傳輸僅使用Fullmesh算法，其他子流加入其B>0；其他情況下，加入任何子流均對其有害無益，明顯Fullmesh算法性能更優(yōu).

通過實(shí)驗(yàn)分析，可以得知Ndiffports和Binder 路徑管理算法的性能正如理論分析所示，其B基本等于0，即對帶寬并沒有什么提高，性能較差，因此以下2個(gè)場景中將其省略.

圖7 HU-KRU MPTCP 長期測試結(jié)果

圖7為HU到 KRU站點(diǎn)之間的MPTCP平均有效載荷吞吐量結(jié)果，可以清楚看出不同路徑管理算法和擁塞控制算法在不同初始路徑下的表現(xiàn).

表3 HU-KRU 帶寬聚合效益B的計(jì)算結(jié)果

為了從數(shù)據(jù)的角度更有力的說明路徑管理算法的優(yōu)劣，根據(jù)B公式進(jìn)行計(jì)算，具體計(jì)算結(jié)果如表3.其中，C-K表示CERNET-KREONET，Cn-K 表示CnUnicom-KREONET.從表中，可以清楚看到使用default算法進(jìn)行多路徑傳輸時(shí)，2條路徑的B接近于0(C-K在2種擁塞控制算法作用下B=-0.06；Cn-K使用Cubic時(shí)，B=-0.01，使用Olia時(shí)B=0.14)，這是因?yàn)槠漕愃朴赥CP單路徑傳輸，但另一條路徑的存在仍對其有微小的負(fù)面影響，可以推測2條路徑的性能不是太好，此時(shí)路徑管理算法性能較差.但使用Fullmesh算法進(jìn)行多路徑傳輸時(shí)，由于2條路徑本身的性能相差不大，不管哪條作為初始路徑，另一條子流加入傳輸后，B>0，即2條子流的加入均能提高網(wǎng)絡(luò)的整體吞吐量，但C-K的B明顯大于Cn-K的B(使用Cubic時(shí)，C-K 的B=4.06，Cn-K的B=0.15，4.06>0.15；使用Olia時(shí)C-K的B=2.47，Cn-K的B=0.05，2.47>0.05)，即Cn-K加入已存在的C-K進(jìn)行多路徑傳輸?shù)玫降膸捑酆洗笥贑-K加入已存在的Cn-K進(jìn)行多路徑傳輸?shù)玫降膸捑酆?，意味著Cn-K加入多路徑傳輸能提高網(wǎng)絡(luò)的通信性能，此時(shí)的路徑管理算法性能較好.同樣，可以看出使用Cubic算法B大于使用OLIA算法的B，即使用Cubic算法時(shí)，其他子流的加入更能提高整體的網(wǎng)絡(luò)吞吐量.此2個(gè)場景下Cubic算法始終較好于OLIA算法，但并不總是這樣，下面有個(gè)反例.

圖8 NTNU-HiN MPTCP 長期測試結(jié)果

圖8為NTNU到HiN站點(diǎn)之間的MPTCP平均有效載荷吞吐量結(jié)果.同時(shí)，其對應(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的計(jì)算結(jié)果

從表4中可以看出當(dāng)U-U為初始路徑時(shí)，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ò)整體的吞吐量.而當(dāng)其他路徑作為初始路徑，使用default算法時(shí)，B接近于0，即此時(shí)的路徑管理算法性能較差；使用Fullmesh算法時(shí)，U-U加入后，B大大增加，意味著該路徑對網(wǎng)絡(luò)整體吞吐量有貢獻(xiàn)，即此時(shí)的路徑管理算法性能較好；但使用OLIA算法的B此時(shí)均大于Cubic算法的B，這是因?yàn)榇藭r(shí)ADSL 路徑丟包率較高，使得路徑的擁塞窗口減小，從而產(chǎn)生了此現(xiàn)象.從性能優(yōu)劣的角度分析，在該場景下，進(jìn)行多路徑傳輸時(shí)，推薦Fullmesh算法和OLIA算法.

綜上所述，針對多路徑傳輸協(xié)議MPTCP 的多個(gè)測試場景，對其測試分析，根據(jù)網(wǎng)絡(luò)帶寬聚合效益B的定義，提出B的計(jì)算公式，并從B的角度統(tǒng)計(jì)分析了路徑管理算法的性能，驗(yàn)證了算法的理論分析即MPTCP使用Default路徑管理算法時(shí)僅相當(dāng)于TCP單路徑傳輸，此時(shí)B基本接近于0甚至等于0；Ndiffports和 Binder路徑管理算法僅在特殊場景(網(wǎng)關(guān)負(fù)載均衡)中能得到有效的利用，因此對多路徑傳輸并貢獻(xiàn)不明顯，即在特殊設(shè)置的網(wǎng)絡(luò)環(huán)境下B﹥0；只有Fullmesh路徑管理算法無需在意初始路徑，能獲得較高的吞吐量，可以提供帶寬聚合的好處，使用此路徑管理算法，性能優(yōu)的子流加入傳輸B﹥0，性能差的子流加入傳輸會拖累性能好的子流，使B變小甚至小于0.

4 結(jié)束語

研究了MPTCP的4種路徑管理算法對多路徑傳輸呑吐量性能的影響，測試結(jié)果分析表明Fullmesh路徑管理算法在多路徑傳輸中性能最優(yōu)，同時(shí)重定義了帶寬聚合效益B的內(nèi)涵，并用其評價(jià)驗(yàn)證了4種路徑算法與相應(yīng)的擁塞控制算法共同作用下對傳輸呑吐量的性能的影響，結(jié)果表明B可以作為其衡量多路徑子流對整體通信性能是貢獻(xiàn)還是拖累的重要指標(biāo).下一步工作的重點(diǎn)，對不同的子流進(jìn)行更細(xì)粒度地分析，使其能用B自動化地確定多路徑子流是否可以參與多路徑的并發(fā)傳輸，根據(jù)此思想改進(jìn)路徑管理算法，并修改MPTCP的內(nèi)核，真正達(dá)到通過多路徑傳輸提高帶寬的目的.

[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ī)制研究[J]. 計(jì)算機(jī)工程, 2015, 41(4):117-124.

[12] 符發(fā), 周星, 譚毓銀，等. 多場景的MPTCP協(xié)議性能分析研究[J]. 計(jì)算機(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