胡 慶,鄒 然,劉 鵬
(重慶郵電大學軟件技術中心,重慶 400065)
多路徑傳輸協(xié)議(multipath transmission control protocol,MPTCP)以資源共享的方式,把數(shù)據(jù)流分發(fā)到多條鏈路上來提高網(wǎng)絡帶寬。其思想最早是由Christian Huitema于1995 年在一篇 IETF 的 daft[1]中提出。2009年,IETF為此專門成立了MPTCP工作組,主要致力解決MPTCP體系結構、擁塞控制、路由、API、安全方面[3-5]的問題。在2011年3月形成rfc文案[2]。本文主要針對包調度功能進行研究并提出一種改進算法。
W-SCTP(westwood stream control transmission protocol)利用一次RTT(round trip time)中發(fā)送的所有數(shù)據(jù)建立算法估計帶寬[7],但是不能很好地考慮傳輸時延的影響;CMT(concurrent multipath transfer)協(xié)議中提出流與路徑綁定策略[8],但是妨礙了與標準SCTP(stream control transmission protocol)和現(xiàn)有CMT傳輸?shù)募嫒菪浴T?009年,針對MPTCP提出的數(shù)據(jù)調度方案有2種:①數(shù)據(jù)從應用層到達后馬上分配給各個路徑傳輸;②利用各個子路徑的擁塞窗口數(shù)來分配數(shù)據(jù)給可用路徑。這2種方法都非常簡單,對于解決鏈路擁塞和緩沖擁塞幾乎沒有太大作用。2011年,在MPTCP的rfc文案[2]中提出利用數(shù)據(jù)序號映射結合數(shù)據(jù)段在不同子路徑中的鏈接級序號編號,數(shù)據(jù)以輪詢的方式分配給每條子路徑進行傳輸。然而,以上調度方案都處于起草階段,只是提出了調度思想,現(xiàn)在MPTCP協(xié)議中大多還是采用的輪詢方式對數(shù)據(jù)進行分配。
在本文中,筆者提出一種基于MPTCP的數(shù)據(jù)調度算法,利用對子路延遲時間(round trip time,RTT)和接收端成功接收到的數(shù)據(jù)包個數(shù)為參數(shù),對傳輸性能進行估計,利用這些參數(shù)以動態(tài)預留方式進行調度,減少接收端緩存壓力,提高MPTCP的傳輸速率和帶寬利用率。
在這部分中,首先,筆者分析了影響MPTCP協(xié)議傳輸性能的因子:RTT、丟包率、接收窗口大小等,當中RTT尤其重要,它是鏈路性能的主要參數(shù)之一;然后,筆者綜合考慮每條子路徑接收端成功接收到的數(shù)據(jù)包個數(shù),針對MPTCP提出了一種新的數(shù)據(jù)調度算法,即動態(tài)預留數(shù)據(jù)調度(dynamic resource reservation data scheduling,DR-RS)算法。
在MPTCP協(xié)議中,由于各條子路徑性能的差異,不能使得各子路徑達到最佳性能,將引起傳輸吞吐量下降,即MPTCP的適應性問題。各條子路徑可能具有不同的特點,如帶寬、延遲和錯誤率等,當子路徑之間的性能差異較大時,會使數(shù)據(jù)包不能按序到達接收端,引起數(shù)據(jù)包的亂序,其問題的根源在于MPTCP協(xié)議的數(shù)據(jù)流控制機制,當接收端的接收窗口小于發(fā)送端的擁塞窗口時,發(fā)送端發(fā)送數(shù)據(jù)包的速率受接收窗口大小的影響。當接收窗口大小為0時,發(fā)送端將停止發(fā)送數(shù)據(jù)。
MPTCP協(xié)議的傳輸性能與路徑相關系數(shù)、丟包率、延遲接收窗口大小相關。首先,影響MPTCP協(xié)議整體性能的關鍵因素是路徑的RTT,它是路徑傳輸速度的重要體現(xiàn)。其次,丟包率也是影響MPTCP協(xié)議整體性能的原因,丟包主要分為2種情況:一是丟包引起快重傳,可能會降低另一條子路徑的速率;二是丟包引起超時,另一條子路徑需要等待丟失包重新傳輸并達到接收端。最后,接收窗口大小也是造成適應性問題的因素。MPTCP協(xié)議中接收窗口分為MPTCP總接收窗口和子路徑TCP的接收窗口,前者會影響其整體性能,它是所有已接收到的數(shù)據(jù)包最終的緩存,發(fā)生適應性問題主要是由于總接收窗口的緩存空間被占滿;后者會影響該子路徑的整體性能,當總接收窗口被占滿后,子路徑中發(fā)送的數(shù)據(jù)會被緩存在子路徑的緩存中,所以,子路徑TCP接收窗口的大小也會影響MPTCP的整體性能。
在MPTCP中建立一種有效調度機制是十分必要的,筆者提出一種針對MPTCP的數(shù)據(jù)調度的DRRS算法。該算法首先預測每條子路徑接收端成功接收到的數(shù)據(jù)包個數(shù),結合該條子路徑的性能參數(shù)RTT,對所有子路徑進行排序并預留空間,依次分配數(shù)據(jù)包傳輸。以下為該算法的具體內容。
1)當需要為各子路徑分配數(shù)據(jù)包時,首先分別估算出每條子路徑接收端成功收到的數(shù)據(jù)包個數(shù)
2)將各子路徑按照比例:N/RTT(成功傳包數(shù)與延遲的比值)為參數(shù)進行排序,并分別計算出各子路徑發(fā)送窗口剩余空間:Cwndi。
3)以Ni/RTTi最小的子路徑作為基準路徑,在每條子路徑的接收緩存中依次分配預留的空間大小。數(shù)據(jù)包的分配會按Ni/RTTi由大到小的順序分配給各子路徑。
算法的偽代碼如下。
其中,R為子路徑的RTT;E為子路成功傳包數(shù)量;S為預留空間;B為最小傳輸包的大小;F為兩路徑的關聯(lián)系數(shù)。
2011年,在MPTCP的rfc文案[2]中提出利用路徑管理原件中提供的可用路徑,數(shù)據(jù)包按照輪詢的方式,及RRS(round robin scheduling)數(shù)據(jù)調度策略,依次將請求調度的數(shù)據(jù)包按照公式i=(i+1)mod n進行調度。該算法的優(yōu)點是簡潔易實現(xiàn)。但它并沒有考慮各條子路徑之間的性能差異,是一種無狀態(tài)調度,所以,它無法滿足多路徑并行傳輸?shù)倪m應性,降低了整體鏈路的傳輸性能。
筆者提出的DR-RS算法,對在接收端成功接收到數(shù)據(jù)包的個數(shù)進行預測,結合性能參數(shù)RTT來進行數(shù)據(jù)調度,是一種動態(tài)預留算法,它滿足了MPTCP的適應性,提高了整理吞吐量及整體鏈路的性能。
采用NS-3仿真工具對DS-RS算法進行性能評估。方案如下:假定主機H1,H2間已建立多路徑傳輸通道,主機H1需要同時利用各條子路徑給主機H2傳輸一個 FTP數(shù)據(jù)流,主機之間同時使用MPTCP中現(xiàn)有RRS數(shù)據(jù)調度方案和改進后的DRRS數(shù)據(jù)調度方案持續(xù)傳輸同樣的數(shù)據(jù)流。設定2條子路徑間路徑延遲比例為1∶4和1∶6,拓撲采樣時間設為30 s。
圖1為2種方案在不同時延下,接收端成功接收到的數(shù)據(jù)包個數(shù)的對比,圖1中RRS 1-6和RRS 1-4表示RRS中子路徑延遲的比率分別設置為1∶6和1∶4時的情況,DR-RS算法中同理。DR-RS中子路徑接收端的成功收包數(shù)更高于RRS機制中子路徑接收端的成功收包數(shù)。
圖1 不同機制中成功傳包數(shù)量Fig.1 Number of packets delivered by different mechanisms’settings
圖2為2種方案的擁塞窗口數(shù)Cwnd對比,DRRS估計網(wǎng)絡中端到端間的成功傳包數(shù)和延遲,使得包在子路徑上有效傳輸,因此,擁塞窗口更加穩(wěn)定,增長速度更快且更高。
圖2 延時比率為1∶4時的擁塞窗口增長情況Fig.2 Cwndgrowth pattern with delay ratio 1∶4
另一方面,RRS方案下的擁塞窗口增長穩(wěn)定性并不理想。因為傳播延遲在path-2(RRS Path2)上比在path-1(RRS Path1)大,path-2上的包傳輸比path-1上的包傳輸時間更長,同時傳輸?shù)陌黳ath-2比path-1后抵達。
在圖3對比了2種方案的吞吐量。在DR-RS中,吞吐量更高;另一方面,RRS方法中由于失序數(shù)據(jù)從而發(fā)生快重傳,使得擁塞窗口一直很小,導致堵塞,降低了吞吐量。
圖3 延時比率為1∶4時的吞吐量情況Fig.3 Throughput achieved with path delay ratio 1∶4
本文分析了在MPTCP中影響數(shù)據(jù)傳輸質量的因素,在MPTCP現(xiàn)有數(shù)據(jù)調度機制上提出綜合考慮子路徑的往返時延和接收端成功接收到的數(shù)據(jù)包個數(shù)的DR-RS算法。通過使用NS-3進行驗證,對比結果表明,提出的調度機制減少了MPTCP中的重傳數(shù),提高了吞吐量。下一步深入MPTCP數(shù)據(jù)調度的研究,嘗試建立一個完整的數(shù)據(jù)調度方案,從而達到更好的負載均衡。
[1]HUITEMA C. Multi-homed TCP draft-huitema-multihomed-0 [S].[s.l.]:IETF,1995.
[2]FORD A,RAICIU C,HANDLEY M,et al.Architectural Guidelines for Multi-path TCP Development[S].[s.l.]:RFC 6182,2011.
[3]FORD A,RAICIU C.Draft-ietf-mptcp-multiaddressed-07[S].[s.l.]:IETF,2012.
[4]RAICIU C,HANDLEY M,WISCHIK D,et al,Draftietf-mptcp-congestion-07[S].[s.l.]:IETF,2011.
[5]BAGNULO M.Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses[S].[s.l.]:RFC8181,2011.3
[6]AHMED Abd El Al,TAREK Saadawi,LEE Myung.Bandwidth Aggregation in Stream Control Transmission Protocol[EB/OL].(2004-12-12)[2012-06-21].http://libra.msra.cn/Publication/2200111/bandwidth-aggregation-in-stream-control-transmission-protocol.
[7]CASETTI C,GAIOTTO W.Westwood SCTCP:load balancing over multipaths using bandwidth-aware source scheduling[EB/OL].(2004-12-24)[2012-06-21].http://www.researchgate.net/publication/4127846_Westwood_SCTP_load_balancing_over_multipaths_using_bandwidth-aware_source_scheduling.
[8]吳曉丹,秦亞娟.流與路徑綁定的CMT研究與實現(xiàn)[D].北京:北京交通大學,2008.WU Xiaodan,Tai Yajuan.Research and Implementation of flow path bound under CMT[D].Beijing:Beijing Jiaotong University.2008.