基于TCP Vegas的LTE網(wǎng)絡(luò)擁塞控制算法性能分析

劉 靖

（中國(guó)電信股份有限公司廣東分公司 廣州 510641）

引 言

上世紀(jì)六十年代，為了使數(shù)據(jù)在網(wǎng)絡(luò)上傳輸?shù)酶?、更?zhǔn)確，計(jì)算機(jī)網(wǎng)絡(luò)應(yīng)運(yùn)而生。到上世紀(jì)七八十年代，計(jì)算機(jī)網(wǎng)絡(luò)就已經(jīng)小具規(guī)模。研究人員主要集中解決數(shù)據(jù)傳輸過(guò)程中的控制和協(xié)調(diào)的問(wèn)題，并提出了大量的協(xié)議和控制算法，主要包括傳輸協(xié)議（TCP、UDP等）以及擁塞控制算法。

目前，國(guó)內(nèi)外學(xué)者及研究人員針對(duì)不同環(huán)境下的TCP Vegas進(jìn)行研究，并提出改進(jìn)方案。TCP的擁塞控制是基于丟包對(duì)擁塞窗口進(jìn)行調(diào)整，但由于丟包不一定是網(wǎng)絡(luò)擁塞引起的，因此TCP Vegas通過(guò)監(jiān)測(cè)往返時(shí)間（RTT）來(lái)判斷網(wǎng)絡(luò)是否擁塞，進(jìn)而調(diào)整擁塞控制窗口[1]。

1 TCP Vegas簡(jiǎn)介

TCP Vegas提高吞吐量、降低丟包的技術(shù)有三種，即快速重傳機(jī)制、擁塞避免機(jī)制和改進(jìn)的慢啟動(dòng)機(jī)制，在這三種技術(shù)的支持下TCP Vegas相比傳統(tǒng)TCP Reno協(xié)議具有更高的吞吐量[2]。

TCP Vegas擁有更加先進(jìn)的擁塞控制機(jī)制，其利用往返時(shí)間（RTT）作為主要參數(shù)來(lái)監(jiān)控?fù)砣闆r，提高TCP的性能[3]。TCP Vegas是在初期階段檢測(cè)擁塞，因此可以提前獲知數(shù)據(jù)包是否丟失，而TCP Reno是在擁塞發(fā)生之后進(jìn)行處理，不能有效預(yù)防網(wǎng)絡(luò)擁塞的發(fā)生[1]。

TCP Vegas采用更先進(jìn)的帶寬估計(jì)方案，它使用預(yù)期流量和實(shí)際流量之間的差值來(lái)估算網(wǎng)絡(luò)中的可用帶寬。Vegas的主要思想是，當(dāng)網(wǎng)絡(luò)不擁塞時(shí)，實(shí)際流率將接近預(yù)期的流速，否則，實(shí)際流率會(huì)比預(yù)期的流速小。Vegas利用實(shí)際流率與預(yù)期流速之間的差異來(lái)估計(jì)所屬網(wǎng)絡(luò)的擁堵等級(jí)，并相應(yīng)地更新窗口的大小。Vegas使用兩個(gè)閾值來(lái)適當(dāng)調(diào)整擁塞窗口的大小，并在源主機(jī)控制擁塞窗口的調(diào)整。在擁塞避免階段，Vegas發(fā)送者操作如下：

一條新建連接的cwnd被初始化為一個(gè)數(shù)據(jù)包大小，也就是說(shuō)TCP源只允許發(fā)送一個(gè)數(shù)據(jù)包，等待確認(rèn)后，再傳輸?shù)诙€(gè)數(shù)據(jù)包。每收到一個(gè)ACK確認(rèn)，就將cwnd增加一個(gè)數(shù)據(jù)包的發(fā)送量，直到達(dá)到某個(gè)最大值為止。圖1以慢啟動(dòng)階段和擁塞避免階段為例示出了不同參數(shù)對(duì)控制器行為的影響，它也顯示了如何控制預(yù)期吞吐量和實(shí)際吞吐量之間的差異。

圖1 TCP Vegas慢啟動(dòng)階段和擁塞避免階段參數(shù)的影響Fig.1 Influence of parameters in slow start phase and congestion avoidance phase for TCP Vegas

2 網(wǎng)絡(luò)仿真工具NS-2

NS是一種針對(duì)網(wǎng)絡(luò)技術(shù)的源代碼公開的、免費(fèi)的軟件模擬平臺(tái)，具有良好的可擴(kuò)充性。通過(guò)控制TCP Vegas的兩個(gè)參數(shù)α和β確定排隊(duì)網(wǎng)絡(luò)中處于穩(wěn)定狀態(tài)的包的數(shù)量，并在半包單元中予以表示[1]。在默認(rèn)配置中，Vegas試圖保持排隊(duì)網(wǎng)絡(luò)中數(shù)據(jù)包的數(shù)量在1～3之間，通常通過(guò)調(diào)整cwnd的值來(lái)滿足此約束。這只是初始配置，當(dāng)我們改變參數(shù)后，Vegas排隊(duì)網(wǎng)絡(luò)中數(shù)據(jù)包的數(shù)量出現(xiàn)波動(dòng)，但也始終保持在0～2個(gè)數(shù)據(jù)包[4]。這是好事，因?yàn)榻?jīng)常會(huì)有零延時(shí)排隊(duì)。我們使用α和β中較大的那個(gè)值，來(lái)確保高速鏈接。對(duì)于TCPVegas在NS-2上仿真，需要解決兩個(gè)主要問(wèn)題：慢啟動(dòng)閾值的設(shè)定和α值的設(shè)置。如果在檢測(cè)前Vegas有延遲虧損，閾值就按照丟失恢復(fù)算法中的cwnd/2進(jìn)行設(shè)置。若流程退出慢啟動(dòng)并具有相對(duì)較大閾值（大于2），則閾值應(yīng)該高于cwnd。

3 TCP Vegas擁塞避免機(jī)制的改進(jìn)算法

TCP Vegas算法是通過(guò)監(jiān)測(cè)RTT值的改變來(lái)估計(jì)網(wǎng)絡(luò)擁塞狀況，這是在擁塞發(fā)生之前采取的預(yù)防措施，它前瞻性地預(yù)測(cè)網(wǎng)絡(luò)帶寬的使用情況，并對(duì)小緩存有較強(qiáng)的適應(yīng)性，其公平性及效率都較好。研究表明，Vegas吞吐量相比Reno提高37%～71%，丟包率減少20%～50%。盡管TCP Vegas具有很多優(yōu)點(diǎn)，但要在實(shí)際網(wǎng)絡(luò)中廣泛應(yīng)用還有很多問(wèn)題[5]。

此處針對(duì)TCP Vegas在有線網(wǎng)絡(luò)環(huán)境中不能公平與NewReno共存、持續(xù)擁塞問(wèn)題以及路由變更問(wèn)題進(jìn)行了改進(jìn)，提出了新的算法TCP Vegas-H。

這里我們給出算法改進(jìn)部分的代碼：

其中，incr為窗口增量；succ為計(jì)數(shù)器，初始值為0。

4 仿真實(shí)驗(yàn)及分析

一個(gè)簡(jiǎn)單的LTE結(jié)構(gòu)如圖2所示，它由一個(gè)HTTP/FTP服務(wù)器組成，并且提供了TCP協(xié)議源連接的拓?fù)浣Y(jié)構(gòu)。在LTE系統(tǒng)中，研究重點(diǎn)是路由器?？刂品?wù)器流量的用戶設(shè)備（UE）被稱為進(jìn)化的基站（ENB），這些網(wǎng)絡(luò)節(jié)點(diǎn)負(fù)責(zé)緩沖數(shù)據(jù)包。各ENB通過(guò)5Mb/s有線帶寬連接到相應(yīng)的AGW，并且有2ms的延遲。

圖2 簡(jiǎn)單的LTE結(jié)構(gòu)Fig.2 Simple LTE structure

LTE拓?fù)浣Y(jié)構(gòu)如圖3所示，其中有6個(gè)UE被使用，并通過(guò)恒定帶寬1Mb/s、延遲2ms的鏈路直接連接到ENB。這意味著我們使用兩個(gè)ENB將來(lái)自所有UE的12個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)的數(shù)據(jù)流通過(guò)一個(gè)瓶頸鏈路轉(zhuǎn)移。事實(shí)上這并不是真正的瓶頸鏈路，這里的帶寬達(dá)到100Mb/s。

圖3 LTE拓?fù)浣Y(jié)構(gòu)Fig.3 LTE topology structure

表1 LTE拓?fù)浣Y(jié)構(gòu)仿真參數(shù)Table1 Simulation parameters of LTE topology

仿真參數(shù)如表1所示，從表中我們可以看出，所有的鏈路都有2ms的傳輸延遲，并且Vegas的最大數(shù)據(jù)包大小為1500字節(jié)，最小窗口大小為100字節(jié)。路由器中雙鏈接服務(wù)器的帶寬為100Mb/s，延遲為2ms。

6個(gè)UE節(jié)點(diǎn)通過(guò)有線鏈路連接到相應(yīng)的ENB，但這些節(jié)點(diǎn)之間必須是無(wú)線鏈接。之所以忽略流動(dòng)性是因?yàn)镋NB不動(dòng)，如果我們支持這些節(jié)點(diǎn)的運(yùn)動(dòng)，則必須添加一個(gè)切換場(chǎng)景的拓?fù)浣Y(jié)構(gòu)，這超出了本文的研究范圍，因此我們忽略ENB之間的接口。

實(shí)驗(yàn)?zāi)康氖橇私釺CP Vegas在基于LTE系統(tǒng)的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)的性能。

在圖3所示的仿真模型中，節(jié)點(diǎn)0～5和7～12使用相同的參數(shù)，它們都使用TCP Vegas和TCP Reno。在我們的實(shí)驗(yàn)中使用NS-2網(wǎng)絡(luò)仿真工具，并且使用TCPVegas在LTE連接的缺省值和擁塞控制算法的各個(gè)參數(shù)。圖4給出了在帶寬、延遲、數(shù)據(jù)包的大小、窗口的大小以及其他所有的鏈路參數(shù)都相同，僅改變TCP Vegas參數(shù)的情況下，TCPVegas和TCPReno的cwnd值比較。在圖4（a）中，我們假定α和β值相同，均為20。實(shí)際上，α和β的默認(rèn)值設(shè)置為40，如圖4（b）所示。如果窗口大小的數(shù)字設(shè)為4～5之間，很容易得出這樣的結(jié)論：當(dāng)重復(fù)的值從20變化到40，窗口的大小相應(yīng)從24字節(jié)變化到48字節(jié)。

由圖4（a）～圖4（e）可以看到，我們?cè)黾应梁挺碌闹?，最好的性能不是發(fā)生在默認(rèn)的參數(shù)值，而是當(dāng)α=β=120時(shí)，此時(shí)窗口最大，為118字節(jié)。

在獲得相同的擁塞窗口cwnd的前提下，TCP Vegas比TCP Reno具有更好的性能。如果在相同的拓?fù)浣Y(jié)構(gòu)下比較TCP Vegas和TCP Reno的性能，可以看到，TCP Vegas的吞吐量和窗口的大小都有所提高。

在圖4（a）和圖4（b）中，TCP Reno的性能優(yōu)于TCP Vegas，TCP Vegas的cwnd分別是20和40。但隨著α和β值增加，TCPVegas的窗口大小逐漸優(yōu)于TCP Reno。圖4（e）中，TCP Vegas的窗口大小已經(jīng)是TCPReno窗口大小的兩倍。

在圖4（f）和圖4（g）中，我們假設(shè)α和β值不相等，可以更加明顯地發(fā)現(xiàn)窗口大小的較大改變。

通常，每個(gè)共享或組合的窗口在連接尺寸和大小方面是獨(dú)一無(wú)二的，因此我們?cè)谶x擇參數(shù)值時(shí)，必須保持各參數(shù)的獨(dú)立。

5 結(jié)束語(yǔ)

本文評(píng)估了TCP Vegas在不同參數(shù)下的LTE網(wǎng)絡(luò)模型。一些研究表明，TCP Vegas比TCP Reno性能更高，數(shù)據(jù)包重傳次數(shù)更少，但對(duì)較長(zhǎng)RTT的連接效果更差。本文研究表明，默認(rèn)擁塞窗口參數(shù)無(wú)法體現(xiàn)TCP Vegas的真實(shí)性能，而采用合適的參數(shù)可以提升TCP Vegas性能，使其優(yōu)于TCP Reno。

圖4 TCP Reno和Vegas的cwnd比 較Fig.4 Comparison of cwnd for TCPReno and Vegas

[1]Srijith K N，Lillykutty Jacob，Ananda A L.TCP Vegas A：Improving the Performance of TCP Vegas[J].Computer Communications，2005，28（4）：429～440.

[2]Brakmo L S，Peterson L L.TCP Vegas：End to End Congestion Avoidance on a Global Internet[J].IEEE Journal on Selected Areas in Communications，2003，3（10）：12～36.

[3]S.Floyd.RFC3649.High Speed TCPfor Large Congestion Windows[S].IETF，2003，2（12）：23～48.

[4]江 勇，林 闖，吳建平.網(wǎng)絡(luò)傳輸控制的綜合性能評(píng)價(jià)標(biāo)準(zhǔn)[J].計(jì)算機(jī)學(xué)報(bào).2002，4（8）：869～877.Jiang Yong，Lin Chuang，Wu Jianping.Comprehensive Performance Evaluation Standard of Network Transmission Control[J].Chinese Journal of Computers，2002，4（8）：869～877.

[5]Vanichpun S，F(xiàn)eng Wuchun.On the Transient Behavior of TCP Vegas[C]//Proceedings of Eleventh International Conference on Computer Communications and Networks.USA：Mary land Univ.IEEE，2002：504～508.