HET-NETs 2010ISBN 978-83-926054-4-7

pp. 379–390

TCP Congestion Control Algorithms Performance in 3G networkswith moving client

MACIEJ ROSTANSKI a PIOTR PIKIEWICZa

aAcademy of Businessin Dabrowa Gornicza

{mrostanski|ppikiewicz}@wsb.edu.pl

Abstract: Presented article focuses on improving performance of the TCP/IP connection inspecific condition - connection between the data server and client downloading data, using mobile(cellular) network as an Internet connection method, while driving. A way to affect mechanismsof transport layer, and achieve better performance, is method described as changing TCP’s Con-gestion Control Algorithm (CCA), which is responsible for congestion window behaviour. Today’sTCP flavours are presented. For experimental research, topology is created, and test scenarios arebeing discussed. Methodology and tools are presented, as well as comparison of different CCA per-formance in realized test runs. Presented research leads to conclusion there is a field of study oncwnd behaviour in 3G network while using a family of congestion control algorithms designed forfast networks, since those get better results than CCAs designed for wireless networks. The resultsand conclusions of this article address the infrastructure level of a typical, modern, european, urbanregion.

Keywords: : Congestion Control, TCP, CuBIC, Veno, Reno, Throughput, UMTS, 3G

1. Introduction

Presented article focuses on improving performance of the TCP/IP connectionin specific condition - connection between the data server and client downloadingdata, using mobile (cellular) network as an Internet connection method. Perfor-mance and similar parameters of a connection using GSM / WCDMA technologiesas an Internet access method is a subject widely researched. The variety of con-ditions and factors affecting performance of such connection is often a topic ofscientific reports - for example [1], [2] or [3].

Problem, addressed in this article, is (in spite of fact that conclusions of similarresearch are useful for mobile network operators nad vendors), they present little

380

value to the end-user - who doesn’t have the capability to alter any parameters of3G infrastructure he uses.

There is, however, a way to affect mechanisms of transport layer, and achievebetter performance. Method described in this article focuses on changing TCP’sCongestion Control Algorithm (CCA), which is responsible for congestion windowbehaviour. Server administrator can easily recompile and merge any CCA (even hisown) into Linux kernel and change CCAs using Linux kernel parameters.

2. TCP State of art

During data transfer, every packet is exposed to phenomenas slowing down orinterrupting its travel through computer network. This slowing down, in the caseof TCP segments in particular, may be caused by transmission channel congestionor interferences observable in wireless networks. In TCP protocol, mechanismsregulating sending data rate in dependence of network state, were introduced as asolution to network congestion problem.

First such modification was so called Tahoe [4] algorithm, including slow-start, congestion-avoidance and fast-retransmission mechanisms. In TCP Reno[5] algorithm, besides Tahoe modifications, an algorithm of Fast-Recovery of lostpackets was introduced [6], [7]. Fast-Recovery uses fast retransmission mecha-nism, in which multiple acknowledges of the same packet indicate packet loss. Socalled New Reno algorithm [8] is capable of Selective Acknowledgments (SACK),allowing TCP protocol to continue fast retransmission procedure without Slow-Start, even after getting only partial acknowledgments (allowing for some ACK toarrive later).

Today there are many known versions of TCP algorithms, altering TCP win-dow size in different manner, that are in majority modifications of Reno mecha-nism, but focusing on different problems of modern networks - some address spe-cific wireless/satellite networks issues, other, for example, deal with TCP prob-lems on Long Fat Networks. Algorithms BIC TCP (Binary Increase Conges-tion Control)[9] and CuBic [10], designed for use with networks with large BDP(Bandwidth-Delay Product), distinguish themselves with window growth function,specific around link saturation point. Mentioned CCAs include methods of newTCP window value designation, which cause no exaggerative growth, which inturn leads to maintaining optimal data transfer rate longer comparing to other algo-rithms. CuBIC Algorithm is used by default in modern Linux kernel.

Another approach is presented by Vegas algorithm [2] - Vegas tries to accom-plish better bandwidth saturation, avoiding retransmissions, with appropriate flowreduction. Algorithm predicts (or tries to predict) congestion before it happens and

381

reduces packet sending rate, hoping to reduce packet delay, and, in effect, increaseperformance. This is known as proactive behaviour. Around 2003, Veno algorithmwas proposed [11] - an attempt to merge the advantages of Reno and Vegas al-gorithms. Veno algorithm relies on Vegas proactive mechanism only to identify,whether specific packet loss incident is caused by network congestion or is it effectof random wireless environment issues. Congestion window regulation is madesimilar to Reno behaviour.

Using such algorithms as Veno or Vegas should bring good results in wirelessnetworks, where packet loss probability is much higher compared to wired net-works. In addition to those, specifically for application in wireless networks, wherepotential packet loss is a result of transmission error rather than network conges-tion, and network load is highly dynamic nature, Westwood algorithm [12] was alsodesigned. In Westwood algorithm, the stream of acknowledgments is analyzed forestimation of Eligible Rate value, used in turn for congestion window optimizationand accurate setting up ssthresh value in case of packet loss event discovery. Im-portant difference between Westwood and Reno is a method of congestion windowreduction. Westwood, contrary to Reno (which halves the cwnd - value of conges-tion window, after congestion event), uses information of last available bandwidthwith window reduction calculation.

Another CCA worth mentioning, YeAH algorithm[13], is quite fair with com-peting Reno flows, and doesn’t cause significant performance loss in case of ran-dom packet loss event. YeAH assumes cooperation of two phases - ”quick” phase,when cwnd is increased following procedures like in STCP [14], and ”slow”, dur-ing which algorithm YeAH behaves like Reno algorithm. The state of algorithmphases is conditioned on predicted packet number in log queue.

3. 3G technologies

As forementioned, the performance of the connection to the Internet via cel-lular/mobile networks is a subject of vast scientific research, specifically for tech-nologies in scope of this paper, articles like [15], [16], [17] . Some reason forthis, and an important fact is that while using mobile terminal for data connectionwith the Internet, different cellular data transfer technologies may be used. Thisis also dependable of the distance between base stations and client, base stationsand/or client capabilities, radio conditions etc. [18],[19]. Therefore, typical 3Gcellular network offers its clients a gradable performance, deploying specific tech-nologies for infrastructure of crowded cities rather than suburban region, or ruralareas, downgrading when necessary to 2.5G or even 2G technologies.

In table 1 we placed main cellular access technologies with their key perfor-

382

Technologies Available bandwidth / Observable packet loss Latency Jitter(generation) throughput at end-user (end-to-end Internet conn.) (RTT values)

GPRS (2.5G) [22], [25] Very Low up to 10%, due to Bad (up to 2000ms) High(115kbps / 40kbps) timeouts and delay spikes

EDGE (2.5G) [26],[27] Mediocre up to 10%, due to Bad (up to 1500ms) Medium(474kbps / 100-130kbps) timeouts and delay spikes

UMTS (3G) [27] High low (sometimes timeouts Good Low(2Mbps / 300kbps) due to poor radio conditions)

UMTS - HSDPA (3.5G) Relatively very high very low, Good (20-100ms) Low[28], [29] (1,5Mbps-4Mbps / 900kbps ) omittable

Table 1. Cellular data connection comparison

mance metrics, judging from user and transport layer perspective. As described in[20], [21] we concentrate on RTT, throughput, packet loss and jitter - those are thekey factors of a TCP connection performance [22]. In research presented herein,mostly UMTS technology was available during test trials.

One must note that the classification herein (Table 1) is not in any way compre-hensive - we concentrate on the packet-switched technologies, and GSM-originated(deployed mostly european-wide). More information was presented in our recentpapers, e.g. [22].

In addition, one must have in mind that the scope of this paper is limited -discussed technologies are continuously advancing, especially 3.5G for examplesuch as HSPA+, MIMO HSDPA [23] and there are first commercial realizationsof 4G family, based on LTE technology. Good presentation of all 3GPP standardsmay be found on [24].

4. Experimental setup

4.1. Methodology and tools

As the thesis of the article claims, effective throughput depends among othersof applied congestion control algorithm at the sender side and may be significantin wireless 3G network. So, the test topology should realize following scenario:(1) The server (sender side) should be capable of using many pluggable CCAs, (2)Mobile client should be able to download data using 3G connection with the server,(3) The case is, there should be disturbances caused by moving client.

Figure 1 shows created topology.As a traffic generator, nuttcp application was used - known and widely de-

ployed in Solaris and Linux systems measurement application [31]. Nuttcp is ca-pable of creating data transfer in any direction (client-to-server or server-to-client)which makes it very useful in researched network, as there is no possibility ofcreating connection with open ports (server) at the mobile operator (client) side.

383

Fig. 1. Test research topology

Transfer tests were measured at the mobile station side, recorded using WindowsXP and Wireshark, open source network analyzer, that permits analysis of networktraffic as well.

Congestion window has to be observed on the sender-side (server). For this, inLinux system, TCP Probe module was used. Module is capable of saving TCP con-nection state, cwnd and ssthresh values, and packet sequence numbers in observedconnection.

4.2. Topology setup

The testbed topology consists of three key elements (see Fig. 1): wireless(celullar) client with 3G capable modem, the Internet server, and a car. Wirelessclient, connected to the 3G operator is put in the car, allowing testing while driving.Regardless of the set up topology, some moving client conditions had to be put up toexpress typical moving client behavior. We propose a simple example of recreatinggood, average and bad conditions, as follows.

4.2.1. Good conditions case

In order to create good conditions scenario, cellular client was placed in aslow cruising car. To ensure there are no roaming events during tests, cruising path

384

was carefully traced in vicinity of an operator access point. Speed did not exceed30kmph, and there were frequent stops.

4.2.2. Average conditions case

Creating an average conditions scenario we assumed there should be roamingevents involved; speed of movement should vary between 20-60kmph and there willbe stops, e.g. on the red lights. In other words, case would be about transferringdata in average city traffic. The path of test was therefore placed between cities ofDabrowa Gornicza and Sosnowiec, mainly an urban area.

4.2.3. Bad conditions case

Naturally bad conditions case is about data transfer during fast travel - test in-volves a highway run (80-100 kmph). In this research, the case was tested betweenDabrowa Gornicza and Katowice cities in Silesia metropolis region.

Naturally, one of the main issues is the effect of 3G infrastructure level in testedareas on our research (this includes an effects of roaming, attenuation, disturbancesand unknown quality of service rules at the operator network). This research doesnot address the problem of base stations localization and configuration, though.Suffice to say is that one has to have in mind that results and conclusions of thisarticle address the infrastructure level of a typical, modern, european, urban region.

5. Results and conclusions

Tests were conducted with few distinct congestion control algorithms (Reno,CuBIC, Veno, Westwood) and analyzed for (1) congestion window behaviour,(2)RTT values, (3)achieved througput with given CCA. Results are given as fol-lows.

5.1. Congestion window behaviour

As expected, CCAs try to achieve maximum allowable throughput veryquickly. Such action is shown on Fig. 2 for three algorithms. CuBIC’s specificgrowth function near saturation point effect can be seen. Worth noting is, algo-rithms predestined for wireless networks (such as Westwood or Veno) achieve stu-ration point longer than aggresive CCAs, like CuBIC, when beginning with slow-start phase.

385

Fig. 2. Example of cwnd adjustment for different CCAs: A) CuBIC, B)Westwood, C)Reno

5.2. RTT values

Round-Trip Time values are consistent for every CCA; average RTT is low- around 20ms. A small, but observable jitter exists. This is very important forany TCP CCA since cwnd may be altered by algorithm once every RTT occurance.Also, timeout values are derived from RTT.

5.3. Throughput comparison

For clearance, throughput achieved using CCAs diagrams were split onto threeexemplary comparisons.

Fig.3 shows throughput achieved in similar operating conditions and time byusing Westwood, and later, CuBIC algorithm. Even disregarding radio problemsaround 55th second for Westwood, it is clear that CuBIC achieves better throughputin any circumstance.

As shown on Fig. 4, comparing Veno to Cubic shows interesting difference.On this figure, first 30 seconds is bad radio conditions period, and other half isgood conditions period. Under good conditions scenario, both algorithms performsimilar and achieve similar results. The difference lies in bad conditions handling.Veno, using proactive mechanisms, predicts problems and stays within lower cwndvalues. This causes uninterrupted transfer (with little jitter), but is not as effectiveas aggresive behaviour of CuBIC.

When comparing CuBIC to Reno results, it becomes obvious that in this sce-nario, CuBIC modifications perform very well. CuBIC achieves better performance

386

Fig. 3. Westwood and Cubic throughput comparison

Fig. 4. Veno and Cubic throughput comparison

with this type of connection. Reno doesn’t handle RTT jitter very well.Main problems of experimental research are:a) tests involving moving (driving) are hard to reproduce in identical manner

- the only solution seems to be performing statistically big number of test runs,which leads to another problem:

b) 3-minute test requires around 10MB of data transfer, which leads to notifi-able cost of research,

387

Fig. 5. Reno and Cubic throughput comparison

c) there is a possibility of many concurrent users in researched area, which willlead to lower maximum throughput allowed by an operator. Tests then have to berepeated to be comparable to other results.

Nevertheless, conducted tests lead to interesting conclusions.Unlike technologies of lower mobile generations (2, 2.5G), scenario of Internet

access using 3G connection delivers IP parameters similar to wired connection -low RTT, high throughput, almost no packet loss probability. Therefore, we observebetter performance using congestion control algorithms designed with Long FatNetworks in mind - especially CuBIC. Wireless - friendly CCAs, as Westwood orVeno, do not improve throughput at all in this circumstances.

Presented research leads to conclusion there is a field of study on cwnd be-haviour in 3G network while using a family of congestion control algorithms de-signed for fast networks - such as HS-TCP, Hamilton, YeAH. Also, should trials beconsistent with observation, detailed study may be produced.

References

[1] Inamura H., et al.: TCP over Second (2.5G) and Third (3G) GenerationWireless Networks, IETF RFC 3481, February 2003

[2] Brakmo L., O’Malley S., Peterson L., TCP Vegas: New techniques for con-gestion detection and avoidance, Proceedings of SIGCOMM ’94 Symposium,1994

388

[3] Ghaderi M., Boutaba R.: Mobility Impact on Data Service Performance inGPRS Systems, TR-CS University of Waterloo, Canada, 2004

[4] M. Allman, V. Paxson, W. Stevens: TCP Congestion Control, Network Work-ing Group, IETF RFC 2581, April 1999

[5] V. Jacobson: Berkley TCP evolution from 4.3-Tahoe to 4.3 Reno, Proceedingsof the 18 th Internet Engineering Task Force, University of British Colombia,Vancouver, Sept. 1990

[6] Stevens W.: RFC 2001 - TCP Slow Start, Congestion Avoidance, Fast Re-transmit, and Fast Recovery Algorithms, http://www.ietf.org/rfc/rfc2001.txt,webpage version of June 2008

[7] S. Floyd, T. Henderson: RFC 2582: The New Reno Modification to TCP’sFast Recovery Algorithm, 1999

[8] Floyd S., Mahdavi J., Mathis M., Podolsky M.: RFC 2883: An Extension tothe Selective Acknowledgement (SACK) Option for TCP

[9] Lisong X., Harfoush K., Rhee I.: Binary Increase Congestion Control forFast, Long-Distance Networks in proc. of IEEE Infocom 2004

[10] Rhee I., Xu L.: CUBIC: A New TCP-Friendly High-Speed TCP Variant, inproc. of PFLDnet 2005, February 2005, Lyon, France

[11] Fu C., Liew S., TCP Veno: TCP Enhancement for Transmission Over WirelessAccess Networks, IEEE Journal on Selected Areas in Communications, Vol.21, No. 2, February 2003

[12] Chen J., Paganini F., Wang R., Sanadidi M. Y., Gerla M.: Fluidflow analysisof TCP Westwood with RED, Computer Networks: The International Journalof Computer and Telecomunication Networking, Vol. 50, Iss. 9, June 2006

[13] Baiocchi A., Castellani A., Francesco Vacirca F.: YeAH-TCP: Yet AnotherHighspeed TCP, http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf,webpage version of June 2008

[14] Tom Kelly, Scalable TCP: Improving Performance in Highspeed Wide AreaNetworks. Computer Communication Review 32(2), April 2003

[15] Chakravorty R., Cartwright J., Pratt I.: Practical Experience with TCP overGPRS, in proc. IEEE GLOBECOM Conference, 2002

[16] Bhandarkar S., Reddy A.L.N., Allman M., Blanton E.: Improving the Robust-ness of TCP to Non-Congestion Events, Network Working Group Request forComments: RFC 4653, 2006

389

[17] Benko P., Malicsko G., Veres A.: A Large-scale, Passive Analysis of End-to-End TCP Performance over GPRS, Ericsson Research, in proc. INFOCOMConference, 2004

[18] Halonen T., Romero J., Melero J.: GSM, GPRS, and EDGE performance.Evolution Towards 3G/UMTS, John Wiley & Sons, England 2003

[19] Park K.: QoS in Packet Networks, wyd. Springer, USA 2005

[20] Blum R.: Network Performance: Open Source Toolkit, Wiley and Sons, USA2003

[21] Hassan M., Jain R.: High Performance TCP/IP Networking, Wiley 2004

[22] M. Rostanski: Poprawa wydajnosci przesylu w bezprzewodowej, radiowej,pakietowej transmisji danych, PhD thesis, Institute of Theoretical and AppliedComputer Science, Gliwice, Poland 2009

[23] MIMO HSDPA Throughput Measurement Results in an Urban Scenario, Inproceedings of VTC2009 conference, Anchorage USA, Sept. 2009

[24] 3G Americas Standard Page,http://www.3gamericas.org/index.cfm?fuseaction=page&sectionid=345

[25] Heine G., Sagkob H.: GPRS: Gateway to Third Generation Mobile Networks,Artech House, USA 2003

[26] Rostanski M.: Symulacja przesylu danych GPRS, in: Internet w spoleczenst-wie informacyjnym, w WSB Dabrowa Gornicza, Poland 2005

[27] The 3rd Generation Partnership Project (3GPP) Webpage:http://www.3gpp.org/

[28] J. Derksen, R. Jansen, M. Maijala and E. Westerberg: HSDPA performanceand evolution, Ericsson 2006

[29] Spirent Communications White Paper: HSDPA Throughput: Do Today’s De-vices Really Perform? http://spcprev.spirentcom.com/documents/4683.pdf,January 2007

[30] Hiroyuki Ishii: Experiments on HSDPA Throughput Performance in W-CDMA Systems, IEICE Transactions on Fundamentals of Electronics, Com-munications and Computer Sciences archive, Volume E89-A , Issue 7 (July2006), pp. 1903-1912

[31] Nuttcp man page: http://www.die.net/doc/linux/man/man8/nuttcp.8.html

390