衛(wèi)星網(wǎng)絡(luò)環(huán)境下TFRC與窗口協(xié)議的比較

江波　胡谷雨　金鳳林　吳兆峰

摘 要： 為了比較傳輸控制協(xié)議在衛(wèi)星網(wǎng)絡(luò)環(huán)境下的性能，研究了傳統(tǒng)的基于窗口的協(xié)議和基于速率中使用最廣泛的TFRC（TCP Friendly Rate Control，TCP友好速率控制）協(xié)議，在衛(wèi)星網(wǎng)絡(luò)應(yīng)用環(huán)境下，通過(guò)仿真實(shí)驗(yàn)比較了窗口協(xié)議與TFRC。仿真實(shí)驗(yàn)表明，TFRC協(xié)議的性能要優(yōu)于傳統(tǒng)的基于窗口的傳輸控制協(xié)議。

關(guān)鍵詞： 衛(wèi)星網(wǎng)絡(luò)； 擁塞控制； 窗口協(xié)議； 傳輸友好速率控制

中圖分類號(hào)：TP393 文獻(xiàn)標(biāo)志碼：A 文章編號(hào)：1006-8228（2016）03-31-05

Comparison between TFRC and window-based protocols in satellite network

Jiang Bo， Hu Guyu， Jin Fenglin， Wu Zhaofeng

（PLA University of Science and Technology， Academy of Command Information System， Nanjing， Jiangsu 210007， China）

Abstract： In order to compare the performance of the transmission control protocol in satellite network environment， the traditional window-based protocols and the most widely used rate-based protocol TFRC （TCP Friendly Rate Control） are studied and applied to a satellite network environment， and through the simulation experiments compared the window-based protocols with TFRC. The simulation experiments show that the performance of TFRC protocol is better than the traditional window-based transmission control protocols.

Key words： satellite network； congestion control； window-based protocol； TFRC

0 引言

目前網(wǎng)絡(luò)的數(shù)據(jù)量處于持續(xù)上升階段，特別是網(wǎng)絡(luò)中多媒體業(yè)務(wù)流在大量的增加。如何做到在網(wǎng)絡(luò)中高效傳輸多媒體數(shù)據(jù)同時(shí)又不影響網(wǎng)絡(luò)的穩(wěn)定性，是目前需要解決的問(wèn)題。

網(wǎng)絡(luò)在世界范圍內(nèi)使用，網(wǎng)絡(luò)需求呈多樣化，其中衛(wèi)星網(wǎng)絡(luò)成為人們使用的一大需求。網(wǎng)絡(luò)中流量持續(xù)增加，特別是多媒體業(yè)務(wù)流比重增多，網(wǎng)絡(luò)中主要使用的TCP協(xié)議在應(yīng)用到衛(wèi)星網(wǎng)絡(luò)環(huán)境下，出現(xiàn)性能的下降。

對(duì)于上述問(wèn)題，已有眾多學(xué)者和研究機(jī)構(gòu)提出了多種傳輸多媒體的擁塞控制機(jī)制。在這些解決方案中，被認(rèn)為傳輸多媒體數(shù)據(jù)最好的方案是基于速率擁塞控制機(jī)制的TFRC協(xié)議。目前TFRC已經(jīng)形成相關(guān)的RFC文檔[2]。本文換個(gè)角度去分析在衛(wèi)星網(wǎng)絡(luò)環(huán)境下存在的問(wèn)題，將基于速率的擁塞控制機(jī)制與傳統(tǒng)的窗口協(xié)議比較，找出其存在的問(wèn)題并進(jìn)行分析，為下一步工作打好基礎(chǔ)。

1 衛(wèi)星網(wǎng)絡(luò)環(huán)境下TCP的相關(guān)研究

1.1 TCP相關(guān)介紹及衛(wèi)星網(wǎng)絡(luò)環(huán)境下TCP存在的問(wèn)題

TCP協(xié)議被設(shè)計(jì)的時(shí)候就是考慮到了鏈路的低比特錯(cuò)誤率（低于10-8），TCP數(shù)據(jù)丟失或出現(xiàn)差錯(cuò)主要是由于網(wǎng)絡(luò)擁塞造成的。這些前提條件在衛(wèi)星網(wǎng)絡(luò)中已經(jīng)不成立。衛(wèi)星信道所具有的特性使得其能夠降低TCP的性能，這些特性包括高傳播時(shí)延（靜止軌道衛(wèi)星信道的往返時(shí)延大概在550ms左右）、高帶寬不對(duì)稱、高比特誤碼率以及由于遮擋和同移動(dòng)相關(guān)的多徑衰減鏈路而產(chǎn)生的突發(fā)錯(cuò)誤，這些特性對(duì)TCP的影響是巨大的。

1.2 針對(duì)TCP在衛(wèi)星網(wǎng)絡(luò)環(huán)境下存在的問(wèn)題，提出的部分解決方法

1.2.1 加速傳輸

TCP-Peach[8]， 在每個(gè)連接的開(kāi)始，采用突發(fā)開(kāi)始算法，該算法基于假的報(bào)文段。為了探測(cè)可用的帶寬，假的報(bào)文段不攜帶任何新的信息，并且以低優(yōu)先級(jí)在網(wǎng)絡(luò)中傳輸。多個(gè)TCP連接方法[14]，采用N個(gè)TCP連接能夠從下面幾個(gè)方面提高吞吐量。性能增強(qiáng)代理（PEP）[17]，能夠區(qū)分衛(wèi)星鏈路和陸地鏈路，且能夠在任意協(xié)議實(shí)現(xiàn)。對(duì)于衛(wèi)星鏈路來(lái)說(shuō)，PEP能夠緩解大的端到端時(shí)延和鏈路出錯(cuò)所帶來(lái)的影響。

1.2.2 調(diào)整ACK的反饋

周期性ACK[6]，接收方并不對(duì)每個(gè)數(shù)據(jù)包發(fā)送確認(rèn)。在RTT的基礎(chǔ)上，ACK以一定的速率發(fā)送。分析了協(xié)議在不同的不對(duì)稱鏈路下的性能，并確定了最佳ACK頻率。ACK的擁塞控制[14，21]，TCP接收端維持一個(gè)動(dòng)態(tài)可變的延遲ACK因子d，通過(guò)改變d的值來(lái)控制ACK的發(fā)送頻率。文獻(xiàn)[14]和文獻(xiàn)[15]分別提出了AF和AR兩種機(jī)制， AF機(jī)制在瓶頸鏈路的路由器實(shí)現(xiàn)，用于丟棄冗余的ACKs。為了保持一個(gè)恒定的速率，AR機(jī)制在報(bào)文段離開(kāi)慢的反向鏈路的路由器上實(shí)現(xiàn)，用于重建ACKs。

1.2.3 傳輸差錯(cuò)進(jìn)行區(qū)分

顯式擁塞通知（ECN）[14]。通過(guò)在IP數(shù)據(jù)包頭部設(shè)置ECN比特位，路由器能夠通知發(fā)送端中間發(fā)生的擁塞。因此發(fā)送端收到擁塞通知，發(fā)送速率就減少，否則發(fā)送速率不會(huì)發(fā)生變化。文獻(xiàn)[16]提出了一種發(fā)送方算法，該算法采用了固定大小的窗口，以解決衛(wèi)星網(wǎng)絡(luò)由于隨機(jī)和突發(fā)錯(cuò)誤產(chǎn)生的丟包。TCP Westwood[18]協(xié)議最明顯的特征是它是TCP擁塞窗口算法的發(fā)送方的改進(jìn)，發(fā)送端不斷地監(jiān)測(cè)ACKs的接收速率，估計(jì)當(dāng)前的可用帶寬。在發(fā)送端監(jiān)測(cè)到丟包或者傳輸超時(shí)的情況下，發(fā)送端用其估計(jì)值設(shè)置cwnd和ssthresh值的大小。

2 TFRC的相關(guān)介紹

TFRC為了可以和TCP流公平的競(jìng)爭(zhēng)網(wǎng)絡(luò)流量，TFRC采用了TCP的流量方程，方程大概描述了TCP發(fā)送速率和時(shí)間丟失率、往返時(shí)延、數(shù)據(jù)片段大小等之間的關(guān)系。TFRC的功能模塊（如圖1所示）簡(jiǎn)要反應(yīng)發(fā)送方與接受方的功能，TFRC的工作過(guò)程分以下幾個(gè)步驟：①接收端估算丟失事件率并將其反饋給發(fā)送端；②發(fā)送端通過(guò)得到的反饋估算環(huán)回時(shí)間RTT；③發(fā)送端將丟失事件率與環(huán)回時(shí)間代入擁塞控制等式計(jì)算出當(dāng)前的適當(dāng)?shù)陌l(fā)送速率；d.發(fā)送端依據(jù)計(jì)算出來(lái)的速率調(diào)整實(shí)際發(fā)送速率。

TFRC擁塞控制中的TCP吞吐率公式即：

具體參數(shù)意義：x為吞吐率（bytes/s）；S為數(shù)據(jù)包大小（bytes）；R為往返時(shí)間RTT（s）；p為丟包率，值在[0，1]內(nèi)；t_RTO為重傳時(shí)鐘；b為TCP接收端一次確認(rèn)的包數(shù)。

TFRC發(fā)送方數(shù)據(jù)包信息如下：序列號(hào)、時(shí)間戳、發(fā)送端估計(jì)的當(dāng)前鏈路往返時(shí)延、發(fā)送端的當(dāng)前發(fā)送速率。

TFRC接收方的反饋數(shù)據(jù)包信息如下：序列號(hào)、時(shí)間戳、時(shí)延。估計(jì)的丟失事件率、估計(jì)的接收速率。

TFRC的數(shù)據(jù)包頭部如圖2所示。

[序列號(hào)＼&時(shí)間戳＼&往返時(shí)延＼&…＼&數(shù)據(jù)＼&][序列號(hào)＼&時(shí)間戳＼&時(shí)延＼&丟失事件率＼&接收速率＼&][發(fā)送方][接收方]

圖2 TFRC的數(shù)據(jù)包頭部

3 仿真和分析

本文采用NS2進(jìn)行仿真。在傳統(tǒng)的基于窗口的傳輸協(xié)議方面，本文采用了使用廣泛的TCP-Reno、TCP-NewReno、SACk、XCP協(xié)議，從正向鏈路、反向鏈路、傳輸時(shí)間、丟失率、突發(fā)丟失率等多個(gè)方面進(jìn)行仿真，通過(guò)全面的比較，然后進(jìn)行分析。

我們采用了文獻(xiàn)[3]網(wǎng)絡(luò)仿真環(huán)境，如圖3所示，在此環(huán)境中，兩個(gè)地面站通過(guò)GEO衛(wèi)星傳輸用戶數(shù)據(jù)。地面站的網(wǎng)關(guān)復(fù)用N條數(shù)據(jù)流，其緩存大小是50個(gè)數(shù)據(jù)包。用戶和衛(wèi)星站之間的鏈路大小為10Mbits/s，地面站和衛(wèi)星之間雙向鏈路的容量大小分別為10Mbit/s。衛(wèi)星鏈路的往返時(shí)延大小為550ms，地面鏈路的往返時(shí)延大小為10ms，報(bào)文段大小為1000bytes，窗口協(xié)議的默認(rèn)擁塞窗口rwnd大小為64個(gè)報(bào)文段。

3.1 無(wú)錯(cuò)誤情況下，性能的仿真

圖4所示為各協(xié)議在前向鏈路上的吞吐量。由于窗口協(xié)議受到擁塞窗口大小64的限制，所以單個(gè)連接的吞吐量最大只能約為0.898Mbit/s（計(jì)算的方法是最大傳輸數(shù)據(jù)除傳輸時(shí)間即64*1000*8/（0.57*106））。當(dāng)N<10時(shí)，所有的協(xié)議的吞吐量隨著N的增大而增大，當(dāng)N>10時(shí)，由于最大輸出的輸入數(shù)據(jù)速率大于輸出數(shù)據(jù)速率，地面站1開(kāi)始發(fā)生擁塞，除TFRC、XCP外，其他協(xié)議的吞吐量會(huì)有所下降。

反向鏈路的帶寬如圖5所示。當(dāng)N<10時(shí)，TCP等窗口協(xié)議需要的反向鏈路帶寬增長(zhǎng)速度比TFRC快。當(dāng)N>10時(shí)，TCP等窗口協(xié)議的帶寬逐漸地保持在300Kbit/s。由于TFRC是采用NACK（對(duì)錯(cuò)誤的數(shù)據(jù)包發(fā)送確認(rèn)）機(jī)制，反向鏈路的帶寬不會(huì)很大，所以TFRC本身對(duì)帶寬的不對(duì)稱有較好的處理。

如圖6，為了比較各協(xié)議在傳輸不同大小文件的傳輸時(shí)間，我們仿真了N=1的場(chǎng)景?？梢钥闯鲈趥鬏斝∥募倪^(guò)程中，XCP所需時(shí)間最短，TCPs次之，TFRC最長(zhǎng)。產(chǎn)生這樣的結(jié)果主要原因是TFRC的慢啟動(dòng)階段速率增長(zhǎng)的比較緩慢。從表1中可以看出在傳輸大文件時(shí)耗時(shí)是最短的，其原因在圖4的比較分析中可知TFRC的吞吐量最大。

3.2 具有隨機(jī)錯(cuò)誤情況下性能的仿真

在N=1的情況下吞吐量如圖7所示，這種情況，鏈路不會(huì)發(fā)生擁塞，錯(cuò)誤是丟包的惟一原因。當(dāng)丟包率低于10-4的時(shí)候，基于窗口的協(xié)議可以保持在比較穩(wěn)定的吞吐量，雖然TFRC的吞吐量高，但隨著錯(cuò)誤率的增加，TFRC的吞吐量下降嚴(yán)重。在相同的試驗(yàn)場(chǎng)景下，反向鏈路的帶寬如圖8所示?？梢钥闯?，TFRC反向鏈路需要的帶寬非常少，原因是TFRC采用的NACK反饋機(jī)制，同時(shí)也可以看出，TFRC反向鏈路的吞吐量與前向鏈路的吞吐量不成比例或者可以說(shuō)是相互獨(dú)立。

具有隨機(jī)錯(cuò)誤的鏈路上的吞吐量

具有隨機(jī)錯(cuò)誤的反向鏈路上的吞吐量

為了在鏈路出現(xiàn)擁塞和隨機(jī)錯(cuò)誤的情況下評(píng)價(jià)不同協(xié)議的性能，我們?cè)谟须S機(jī)錯(cuò)誤的鏈路上設(shè)置了20個(gè)連接，圖9顯示的是前向鏈路的吞吐量。TFRC和基于窗口的協(xié)議在錯(cuò)誤率低時(shí)<10-4，可以保持一定的吞吐量，當(dāng)錯(cuò)誤率增大>10-3，幾個(gè)協(xié)議都受到嚴(yán)重的影響。圖10與圖8不同的地方在于，圖10是在多個(gè)連接數(shù)的情況下，可以看出TFRC在反向鏈路上具有一定的優(yōu)勢(shì)，即使在多個(gè)連接的和高錯(cuò)誤率的情況下，反向鏈路還是保持比較低的吞吐量。

具有隨機(jī)錯(cuò)誤的鏈路上的吞吐量

具有隨機(jī)鏈路錯(cuò)誤的反向鏈路上的吞吐量

3.3 具有突發(fā)錯(cuò)誤的情況下性能的仿真

為了仿真突發(fā)錯(cuò)誤的情況，本為使用了文獻(xiàn)[11]所描述的模型，文獻(xiàn)[11]用二個(gè)狀態(tài)的馬爾科夫模型研究衛(wèi)星通信系統(tǒng)中在突發(fā)錯(cuò)誤或信號(hào)中斷情況下的鏈路。Dg和Db分別表示信道在兩個(gè)狀態(tài)中的平均持續(xù)時(shí)間。在信道較差的情況下，數(shù)據(jù)會(huì)在鏈路上丟失，而在信道好的情況下，數(shù)據(jù)就能夠到達(dá)接收端。在本文仿真中，Dg的持續(xù)時(shí)間為1000個(gè)數(shù)據(jù)包，而Db的持續(xù)時(shí)間為0-100個(gè)數(shù)據(jù)包。仿真結(jié)果如圖11到圖12所示，每幅圖是10次試驗(yàn)的平均值。

具有突發(fā)錯(cuò)誤的鏈路上的吞吐量

具有突發(fā)錯(cuò)誤的反向鏈路上的吞吐量

為了在有擁塞和突發(fā)錯(cuò)誤情況下評(píng)估各種協(xié)議的性能，我們?cè)诙€(gè)狀態(tài)的馬爾科夫錯(cuò)誤模型的衛(wèi)星鏈路上設(shè)置了20條連接。在圖11中，實(shí)驗(yàn)表明窗口協(xié)議，隨著Db的增加，吞吐量會(huì)迅速的減少，而TFRC受到的影響比較小。

圖12顯示的是在有擁塞和突發(fā)錯(cuò)誤情況下各個(gè)協(xié)議在反向鏈路上占用的帶寬的大小，從圖中可以看出，TFRC所受的影響最小。

4 總結(jié)與展望

本文將地面網(wǎng)絡(luò)中傳輸多媒體數(shù)據(jù)的TFRC協(xié)議應(yīng)用到了衛(wèi)星網(wǎng)絡(luò)的環(huán)境下，并通過(guò)實(shí)驗(yàn)比較得出以下結(jié)論。TFRC的優(yōu)勢(shì)方面有：TFRC的速率變化比較平緩適于傳輸對(duì)媒體，當(dāng)網(wǎng)絡(luò)擁塞是可以保持一定的吞吐量，前向鏈路的帶寬比較高，反向鏈路的帶寬使用比較少，使用NACK的反饋方式反向鏈路對(duì)于鏈路錯(cuò)誤的有很好的處理，對(duì)于突發(fā)錯(cuò)誤有較好的處理。但TFRC在應(yīng)用到衛(wèi)星網(wǎng)絡(luò)環(huán)境下也存在多種問(wèn)題，這也正是我下一步改進(jìn)的地方，如：慢啟動(dòng)階段速率增長(zhǎng)比較緩慢，隨機(jī)錯(cuò)誤對(duì)其性能影響比較大，和TCP一樣認(rèn)為所有的丟失都是擁塞沒(méi)有丟失區(qū)分的算法。

參考文獻(xiàn)（References）：

[1] Floyd S. Congestion control principles[J]，2000.

[2] Handley M， Floyd S， Padhye J， et al. TCP friendly rate

control （TFRC）： Protocol specification[R]，2002.

[3] Jiong L， Zhigang C， Junaid K M. TP-Satellite： a new

transport protocol for satellite IP networks[J]. Aerospace and Electronic Systems， IEEE Transactions on，2009.45（2）：502-515

[4] 孫偉.TCP友好性流媒體傳輸速率控制協(xié)議中若干問(wèn)題研究[D].

東北大學(xué)，2010.

[5] 鄒軍.VoIP中音頻編解碼選擇與QoS研究[D].北京郵電大

學(xué)，2006.

[6] Akyildiz， I. F. Research issues for transport protocols in

satellite IP networks[J]. IEEE Personal Communications，2011.8（3）：44-48

[7] 徐偉.TCP協(xié)議的性能建模研究[D].中國(guó)科學(xué)技術(shù)大學(xué)，

2012.

[8] Akyildiz I F， Morabito G， Palazzo S. TCP-Peach： a new

congestion control scheme for satellite IP networks[J]. IEEE/ACM Transactions on Networking （ToN），2001.9（3）：307-321

[9] Padmanabhan V N， Katz R H. TCP fast start： A technique

for speeding up web transfers[J]，1998.

[10] Glover D， Allman M. Enhancing TCP over satellite

channels using standard mechanisms[J]，1999.

[11] Lutz E， Werner M， Jahn A. Satellite systems for personal

and broadband communications[M]. Springer Science & Business Media，2012.

[12] 岳鵬.因特網(wǎng)擁塞控制機(jī)制若干問(wèn)題的研究[D].西安電子科

大，2006.

[13] 劉擁民.下一代Internet擁塞控制策略研究[D].中南大學(xué)，

2009.

[14] Allman， M.， Dawkins， S.， Glover， D.， et al. Ongoing TCP

research related to satellites （No. RFC 2760），2000.

[15] Balakrishnan H， Padmanabhan V N， Katz R H. The

effects of asymmetry on TCP performance[J]. Mobile Networks and applications，1999.4（3）：219-241

[16] Minei I， Cohen R. High-speed Internet access through

unidirectional geostationary satellite channels[J]. Selected Areas in Communications， IEEE Journal on，1999.17（2）：345-359

[17] Border J， Griner J， Montenegro G， et al. Performance

enhancing proxies intended to mitigate link-related degradations[J]，2001.