趙靜靜,衷璐潔
(首都師范大學 信息工程學院,北京 100048)
不同于傳統TCP,MPTCP[1]是一種端到端的多路通信,它將一條數據流劃分為多條子流,通過多條鏈路同時進行傳輸實現吞吐量提升。在無線移動網絡不斷進步的今天,智能手機終端普遍同時支持LTE和Wi-Fi[2]。針對MPTCP與TCP資源共享公平性問題,需要將子流往返時延不同的情況納入考慮,根據各子流RTT的不同情況來控制擁塞窗口變化速度。同時,應充分考慮子流間擁塞程度差異,避免在子流間出現跳躍引起鏈路抖動問題,而通過對RTT進行主動探測,在數據流未擁塞至丟包狀態時即實施擁塞控制,調整擁塞窗口大小,可有效減少分組丟失,對此,本文提出PPQD擁塞控制算法。通過在每條鏈路上使用一個窗口強度增長控制因子,實現各子流擁塞窗口的適時動態調整,避免擁塞窗口大波動的出現,提高鏈路帶寬利用率。
目前,MPTCP的多路徑特性對擁塞控制算法提出了新的要求,對此IETF工作組在制定MPTCP規范時對吞吐量、公平性及擁塞控制等方面提出了幾點要求請參見文獻[3]。
針對如何利用多條可用路徑進行高效數據傳輸的問題,直接的方案是對已有單路徑傳輸控制協議[4]進行功能上的擴展,即針對每條可用路徑上的各條子流,都獨立地執行單路徑傳輸控制協議。但由于n條子路徑的多路徑流占用的瓶頸帶寬一般為單路徑流的n倍,當瓶頸帶寬幾乎完全被多路徑流霸占時,就會產生單路徑流帶寬饑餓現象,這樣的情形會引發公平性問題。
目前關于多路徑公平性的相關研究中,Uncoupled的算法思想請參見文獻[4],該算法在當這些子流共享同一瓶頸帶寬時,會表現出較為嚴重的侵略性,令網絡環境惡化。C.Raiciu等[5]提出的LIA算法,根據擁塞窗口大小wr、 總擁塞窗口大小wtotal和侵略因子α的值來動態分配各子流的擁塞窗口,實現了子流侵略性避免的動態控制。在該算法中,侵略因子考慮各子流RTT不相等的情況,用1/wr來控制擁塞窗口增長的上限,可有效制止各子流搶占更多的TCP鏈路流量,保障瓶頸鏈路上公平的帶寬競爭。但LIA算法在子流擁塞程度差異不大時,會產生子流間的跳躍現象,引發“抖動性”問題。因此,提前探知網絡狀態減少擁塞窗口的抖動是提升吞吐量性能的重要前提。
擁塞反映機制是擁塞控制研究中的重要環節。傳統基于丟包作為網絡擁塞的信號反映不夠及時[6,7],而RTT更具可變性,反應也更為靈敏[8]。Brakmo等[9]提出一種單路徑TCP擁塞控制算法TCP Vegas,通過測量鏈路RTT來進行擁塞區分。該算法在RTT變大時,認為網絡擁塞發生,隨后開始減小擁塞窗口,當探測到RTT減小時,認為網絡擁塞逐步解除,當前鏈路傳輸性能轉好,于是增大擁塞窗口提高發送速率。Cao等將Vegas的思想引入至MPTCP中,提出了基于時延的MPTCP擁塞控制算法w Vegas(weighted Vegas)。w Vegas算法思想請參見文獻[10]。對于存在緩存、RTT增大的網絡環境,w Vegas算法仍會在網絡未擁塞的情況下降低相應子流的擁塞窗口,而由于網絡未擁塞,單路徑TCP不會降低自己的擁塞窗口,如此反復,w Vegas會引起帶寬競爭力下降,傳輸效率也會隨之受到影響。
在無線移動網絡場景中,一個移動用戶可同時通過Wi-Fi和4G等多種方式訪問互聯網。發送端(sender)和接收端(receiver)之間傳輸數據的往返時延RTT計算方法請參見文獻[11]。
圖1給出了在無線移動網絡場景中MPTCP的一條鏈路i從連接到接收ACK確認的過程。其中,Qd,i(t) 和Pd,i(t) 分別表示t時刻數據在路由器緩存的排隊時延和系統處理時延;Td,i(t) 表示t時刻數據在鏈路i上的傳播時延;d為往返時延。

圖1 鏈路i上的數據傳輸時延
定義1 前向時延(the forward delay,FD):假定子流s上數據從發送端S流經了n-1個路由達到接收端R,t時刻前向時延記作FD(t),如式(1)所示
(1)
定義2 后向時延(the backward delay,BD):假定子流s上數據從接收端S通過m-1個路由器將ACK反饋給發送端R,t時刻后向時延記作BD(t),如式(2)所示
(2)
往返時延RTT由前向時延及后向時延組成,如式(3)所示
RTT(t)=FD(t)+BD(t)
(3)
在不考慮路由改變的情況下,網絡中排隊時延可以用來感知網絡擁塞的狀態。為了計算鏈路的排隊時延需先計算往返時延RTT。對此,本文提出將TCP Vegas基于時延的擁塞窗口動態調整方法與MPTCP融合,設計并實現了基于主動探測排隊時延的MPTCP擁塞控制方法PPQD,方法框架如圖2所示。PPQD方法采用二次指數平滑預測法對往返時延實施平滑預測,然后根據往返時延預測排隊時延,以排隊時延與其均值的比較結果反映網絡擁塞情況,并據此指導擁塞窗口的動態調整。

圖2 PPQD整體框架設計
基于主動探測排隊時延的MPTCP擁塞控制(congestion control based on proactive probing of queuing delay,PPQD)方法由:(Ⅰ)RTT主動探測(RTT_Probing);(Ⅱ)RTT平滑處理(RTT_Smoothing);(Ⅲ)排隊時延主動探測(QRTT_Probing)及(Ⅳ)擁塞窗口自適應調整(Cwnd_Adjusting)幾個部分組成。其中,RTT_Probing主要負責主動探測鏈路RTT信息的提取,主要實現方式為:開啟時間戳,記錄數據包發送及到達時間對RTT信息進行主動探測;RTT_Smoothing主要負責平滑預測鏈路RTT,實現RTT平滑化,并在對RTT完成平滑處理后,將二次指數平滑后的值RTTpre反饋給QRTT_Probing;QRTT_Probing主要負責主動探測鏈路排隊時延信息的提取,通過計算緩沖區中數據包數量和鏈路帶寬,對排隊時延信息進行求解預測,然后將排隊時延與通過RTT均值計算出的排隊時延均值進行對比來提前探測鏈路狀態,并反饋鏈路狀態信息給Cwnd_Adjusting;Cwnd_Adjusting則主要負責完成擁塞窗口的自適應調整,使用一個窗口強度增長控制因子,動態調整每一條鏈路的擁塞窗口。
提前探測排隊時延信息,需要主動探測鏈路RTT,RTT_Probing模塊使用基于時間戳的主動探測方法。首先向MPTCP網絡注入一定長度的探測包并設置一個時間戳,然后等待來自于接收端的響應。通過計算探測包的到達時間與發出時間差值獲取鏈路響應時間。在此過程中,為更準確地獲取鏈路RTT,需要將發送端發送對應ACK前所消耗的響應時間納入考慮。圖3給出了考慮發送端響應時間的RTT主動探測過程。圖中T1表示發送端發送探測包的時刻;T2表示接收端接收探測包的時刻;T3表示發送端接收到探測包及ACK到發送對應的ACK前所消耗的時間段,即發送端的響應時間;T4表示發送端發送該探測包的ACK的時刻。

圖3 考慮發送端響應時間的RTT主動探測
一個有效考慮發送端響應時間的RTT(i) 主動探測過程由一個4元組組成,RTT(i)={P,I,R,T3},其中:
(1)P是一個探測包的有限序列的集合,p(i) 是P中的第i個探測包。
(2)I是單調增函數,定義為:I∶P→S。S為發送端發送探測包的時間,I決定發送探測包到潛在的接收端的時間序列。
(3)R為所有響應包的時間戳函數,定義為:R∶P→T。T為發送端接收探測包和ACK后向接收端響應ACK的時間,R決定了發送端接收探測包和ACK后向接收端響應ACK時的帶有時間戳的探測包時間序列[12]。
(4)T3(i)表示發送端接收到探測包i及ACK到發送對應的ACK前所消耗的時間段。
考慮發送端響應時間的RTT(i) 的計算方法如式(4)所示
RTT(i)=R(p(i))-I(p(i))-T3(p(i))
(4)
為避免因丟包導致探測值產生大幅度的波動,保障RTT的平滑性,本文采用二次指數平滑預測模型對RTT_Probing模塊獲取的RTT探測值進行平滑處理。RTT平滑處理模塊RTT_Smoothing主要由一次指數平滑處理和二次指數平滑處理兩個階段組成。
(1)一次指數平滑處理(RTT_Smoothing_FP)
為消除RTT探測值的短期上升或下降波動,首先對呈線性變化趨勢的RTT時間序列進行一次指數平滑處理。定義RTT_Probing模塊探測所得到的樣本值為時間序列觀測值,假設時間序列為x1,x2,…,xn(n為時間序列長度),區間[1,n]為時間序列的觀測期,當時間序列的觀測期n>n0時 (n0=15,經過大量實驗驗證,當觀測期大于15時,誤差較小且趨于穩定,探測精度更高),初始值對預測結果的影響很小,此時選取第一次觀測值作為初始值,之后,根據鏈路RTT的進一步探測結果,選取BaseRTT作為平滑往返時延的初始值,BaseRTT的計算方法如式(5)所示
BaseRTT=min{RTT(i),T0}
(5)
式中:RTT(i) 由式(4)計算所得,T0為路由器緩存為空時的往返時延,也是所有觀測往返時延的最小值。

(6)
(2)二次指數平滑處理(RTT_Smoothing_SP)


(7)
之后,計算第t+T時刻的RTT預測值

(8)
式中:α為平滑系數,T為t時刻到預測時刻的間隔時刻數。RTTpret+T預測結果由RTTpre表示。具體算法描述如算法1所示。
算法1: RTT_Smoothing

輸出: 第t時刻的RTT二次平滑值
(1) for 任一MPTCP連接的子流ido
(2) if 子流i收到ACK then
(3) 獲取RTT_Probing模塊RTT探測值;
(4) RTT探測值進行一次指數平滑處理;
(5) RTT探測值進行二次指數平滑處理;
(6) 更新RTT序列;
(7) end if
(8) returnRTTpre;
(9) end for
其中,行(3)~行(5)完成對獲取的RTT的探測值進行平滑化處理;行(6)、行(7)負責對處理后的RTT觀測區間值進行更新存儲;行(8)負責將計算完成后的最終平滑處理結果RTTpre傳遞給QRTT_Probing模塊,用于排隊時延的主動探測。
在實時無線移動網絡中,網絡反饋時延的情況不可避免,傳統MPTCP“加性增、乘性減”算法在執行一段時間后,各子流上的排隊時延將存在巨大差異,導致周期性的振蕩。為削弱反饋時延,弱化由此引起的振蕩,本文提出采用排隊時延的平滑預測值而不是實測值來驅動擁塞控制算法。考慮到數據傳輸過程中數據包的發送、詢問、響應等一系列動作都與鏈路排隊時延相關,而排隊時延均值相較于最大排隊時延及最小排隊時延具有相對穩定,可更好反映網絡性能優勢,故在排隊時延主動探測模塊QRTT_Probing中將包含鏈路排隊時延探測值計算、RTT均值計算以及排隊時延均值計算等3個部分。
(1)排隊時延探測值計算
鏈路i的排隊時延主動探測值QueuingDelaypre計算方法如式(9)所示
(9)
式中:B表示當前占用緩沖區的大小為D的數據包數量,RTTpre為經RTT_Smoothing平滑處理后的反饋值。wr表示擁塞窗口大小。
(2)RTT均值計算


(10)
式中:m_sumRTT表示鏈路i從傳輸開始到傳輸結束的RTT總和,m_cntRTT表示在傳輸過程中RTT的增量。
(3)排隊時延均值計算


(11)

算法2: QRTT_Probing
輸入: B,S,wr,RTTpre

(1) for 任一MPTCP連接的子流ido
(2) if 子流i收到ACK then
(3) 計算QueuingDelaypre;
(4) 計算RTT均值;
(5) 由RTT均值計算排隊時延均值;
(6) end if
(7) returnQueuingDelaypre;

(9) end for
MPTCP擁塞控制通常采用“加性增、乘性減”的策略對擁塞窗口wr進行調整,采用各個子流獨立進行擁塞控制的原則,依照各個子流傳輸情況,當收到接收端響應的新的ACK消息,其對應子流的wr將呈線性增加,當收到3個重復的ACK消息后,觸發擁塞控制算法,調整子流wr按比例減少。這種策略聚合每條子流的可用帶寬,當MPTCP多路徑流與TCP單路徑流同時使用某網絡資源時,MPTCP流占用的容量應不多于TCP流所占用的容量,以保證MPTCP的公平性要求。但各子流的時延由于wr的調整會出現巨大差異,導致周期性的振蕩發生,令有效吞吐量急劇下降。
為了削弱因為時延差異所引起的鏈路震蕩,提升MPTCP的有效吞吐量,本文提出一種基于排隊時延主動探測的擁塞控制策略,在每條鏈路上使用一個擁塞窗口強度增長控制因子δ(δ取經驗值0.9),并根據鏈路擁塞程度實施擁塞窗口的自適應調整。
若排隊時延探測值大于排隊時延均值,即使發送端沒有收到3次重復的ACK,也會實施相應的擁塞窗口減小策略。若排隊時延的探測值小于排隊時延均值,實施擁塞窗口自適應調整策略,動態增加擁塞窗口。具體方法如下:

(12)

(13)
其中,wr表示擁塞窗口大小,wr+1表示下一時刻的擁塞窗口值,1/wr用來控制擁塞窗口增長的上限,確保與TCP流之間的公平性,wtotal表示所有子流實時擁塞窗口之和,α表示控制MPTCP流對TCP流侵略性的常量因子,定義如下
(14)
算法具體描述如算法3所示。
算法3: Cwnd_Adjusting
初始化:BaseRTT

輸出: 完成擁塞窗口的自適應調整
(1) for 任一MPTCP連接的子流ido
(2) if 子流i收到ACK then
(3) //對比預測排隊時延及其均值

(5) //則判斷鏈路無擁塞,增加擁塞窗口:

(7) }else
(8) {//則判斷鏈路擁塞,減小擁塞窗口:

(10) }end if
(11) end if
(12) end for
其中,行(2)、行(3)負責子流i收到ACK后的預測排隊時延及其均值的對比;行(4)~行(7)根據排隊時延預測值及其均值的對比判斷結果實施擁塞窗口的增加策略;行(8)~行(10)負責實施擁塞窗口的減小策略。
本文實驗環境為Intel(R) Core(TM) i7-4790 CPU @ 3.6 GHz,搭載8 GB內存,操作系統使用Ubuntu16.04,仿真實驗平臺采用NS-3,實驗拓撲及參數設定如圖4所示。

圖4 實驗拓撲及參數
實驗拓撲包含雙接口的手機終端,采用Wi-Fi和LTE雙路徑進行并行傳輸,其中:路徑1上的平均帶寬設置為15 mbps,2 ms的傳播時延,路徑2上的平均帶寬設置為10 mbps,1 ms的傳播時延。仿真中有線鏈路的帶寬設置為2.4 Gbps,時延設置為10 ms,分組大小固定為1000 Byte。實驗以FTP業務數據傳輸為例,仿真覆蓋慢啟動、擁塞避免及快重傳階段,以1 s為單位實施擁塞窗口及時延統計。
4.2.1 鏈路狀態評估
在無線移動網絡中,時延是一項重要的網絡服務質量性能指標。對連續的實時應用而言,時延方差大小可以作為鏈路狀態評估的指標,時延方差越小鏈路狀態越好。本文選取LIA和Uncoupled作為比較對象,對多路徑鏈接下的時延方差進行了對比,如圖5所示。其中,PPQD算法的時延方差為7 896 490.816;LIA算法的時延方差為7 903 261.904;Uncoupled算法的時延方差為7 900 358.802。相較于LIA和Uncoupled算法,由于RTT的提前探測和平滑化處理,PPQD算法可更好地減弱RTT振蕩,抑制RTT波動。

圖5 RTT方差對比
4.2.2 公平性評估
圖6給出了網絡共享瓶頸場景的相關設置。其中,S1、S2代表數據發送端,F1、F2代表多路徑兩條子流;單路徑流TCP和兩條子流共享一條瓶頸路徑;瓶頸路徑帶寬B設置為15 Mbps;時延D設置為2 ms;丟包率P設置為0.1%。3條路徑同時進行數據傳輸。

圖6 共享瓶頸場景
圖7給出了共享瓶頸處TCP流及兩條PPQD子流PPQD-F1和PPQD-F2的吞吐量數據。其中,TCP單路徑流平均吞吐量為7.52 Mbit/s,PPQD-F1和PPQD-F2多路徑流的平均吞吐量為7.49 Mbit/s。MPTCP各子流的平均吞吐量與TCP單路徑流的平均吞吐量接近,相差甚微。

圖7 共享瓶頸處TCP流和PPQD子流吞吐量
此外,本文還分別統計了PPQD、LIA和Uncoupled這3種算法的多路徑連接吞吐量數據,如圖8所示。其中,PPQD算法所獲得的平均吞吐量為6.58 Mbps,LIA算法所獲得的平均吞吐量為5.17 Mbps,PPQD算法的平均吞吐量性能優于LIA算法。與此同時,Uncoupled算法平均吞吐量為10.63 Mbps,占用了約70.8%的帶寬容量,相較于LIA算法和PPQD算法,該算法在共享瓶頸處表現出了較強的侵略性。

圖8 實時吞吐量
4.2.3 網絡性能評估
(1)丟包后吞吐量變化
在表1中給出了PPQD、LIA和Uncoupled在發生鏈路丟包前后的實時吞吐量數據。其中,在[14 s,16 s]區間內,PPQD算法的實時吞吐量從6.4 Mbps增加至6.82 Mbps,增量為6.56%,LIA算法的實時吞吐量從4.9 Mbps變化為5.01 Mbps,增量為0.11%,Uncoupled算法的實時吞吐量從11 Mbps變化為11.32 Mbps,增量為2.9%;之后的兩次丟包,PPQD算法的實時吞吐量增量分別為26.1%和17.4%,LIA算法的實時吞吐量增量分別為6.94%和4.07%,Uncoupled算法的實時吞吐量增量分別為6.18%和9.22%。相較于LIA算法和Uncoupled算法,PPQD算法表現出了更好的網絡狀態應對及性能恢復能力。

表1 鏈路丟包后實時吞吐量增量
(2)擁塞窗口變化
擁塞窗口在MPTCP建立新的連接和慢啟動階段的原理請參見文獻[13],當網絡發生擁塞進入擁塞避免階段后,擁塞窗口會迅速減小,當數據包超時時,重新進入慢啟動,擁塞窗口會慢慢恢復。
在數據傳輸過程中,PPQD算法的實時擁塞窗口整體大于LIA算法和Uncoupled算法。如圖9所示,在12.6153 s,15.7773 s和24.9913 s時鏈路發生丟包現象,各算法的擁塞窗口及吞吐量均有所下降。在12.6153 s到15.7773 s的時間區間內,PPQD算法的擁塞窗口從72 285 bit上升至85 615 bit,增量為13 330 bit;Uncoupled算法的擁塞窗口從67 519 bit上升到74 659 bit,增量為7140 bit;LIA算法的擁塞窗口從62 753 bit上升至65 182 bit,增量僅為249 bit。第2次丟包發生后,PPQD算法的擁塞窗口增量為24 146 bit;Uncoupled算法擁塞窗口增量為14 121 bit;LIA算法擁塞窗口增量僅為5049 bit;第3次丟包發生后,PPQD算法的擁塞窗口增量為17 253 bit;Uncoupled算法的增量為10 306 bit;LIA算法的增量僅為3360 bit。總體而言,PPQD算法表現出了較Uncoupled算法和LIA算法更強的擁塞窗口調節能力。

圖9 擁塞窗口變化
本文針對多路傳輸中因網絡擁塞所引發的排隊延遲導致的分組延遲抖動及公平性問題,提出一種基于排隊時延主動探測的擁塞區分鏈路質量優化協議PPQD,以滿足多路徑流公平性為基礎,實施鏈路RTT主動探測,以排隊時延預測結果及其均值比較為依據提前探知網絡狀態,并相應實施擁塞窗口動態調整,以解決鏈路抖動問題。仿真實驗結果表明,PPQD相較于LIA和Uncoupled能夠更好地實現TCP單路徑流和多路徑流在共享瓶頸處可用帶寬的公平分配,減少時延抖動,提升吞吐量。