congestion control in wireless cellular networks990348/fulltext01.pdf · puting power therefore...

LICENTIATE T H E S I S

Luleå University of TechnologyDepartment of Computer Science and Electrical Engineering

Division of Computer Science and Networking

:|: -|: - -- ⁄ --

:

Congestion Control in WirelessCellular Networks

Sara Landström

Congestion Control in WirelessCellular Networks

by

Sara Landstrom

Division of Computer Science and NetworkingDepartment of Computer Science and Electrical Engineering

Lulea University of TechnologyS-971 87 Lulea, Sweden

March 2005

SupervisorLars-Ake Larzon, Ph.D.,

Lulea University of Technology and Uppsala UniversityAssistant supervisors

Ulf Bodin, Ph.D., Lulea University of TechnologyKrister Svanbro, Ericsson Research AB

Published 2005Printed in Sweden by University Printing Office, Lulea

To Peter and Emelie

Abstract

Through the introduction of the third generation of mobile cellular networktechnologies a major step towards ubiquitious and wireless access to the In-ternet has been taken. There are however still challenges due to the differentcharacteristics and prerequisites of wired and wireless networks.

An important network element is congestion control. The purpose of con-gestion control is to ensure network stability and achieve a reasonably fair dis-tribution of the network resources among the users. TCP is a well-establishedprotocol, which offers reliable transport of data and applies congestion control.With regards to TCP it is of interest to follow up on proposed changes to theprotocol and to learn how to tune wireless networks for optimal TCP perfor-mance, since its usage is wide spread. We have performed a study of buffermanagement for TCP with High Speed Downlink Packet Access (HSDPA) andevaluated the effect of reducing the lower bound of the retransmit timeout in-terval in an environement with varying capacity.

A number of the features that TCP consists of introduce arbitrarily delay,therefore reliable transport is sometimes traded for less delay variations by ap-plications with strict timing requirements. Until recently UDP has been themain alternative to TCP. UDP does not provide any service guarantees, norcongestion control, but does on the other hand not introduce any delay in itself.

There are however concerns that increased usage of UDP would cause net-work instability and starve the TCP flows that reduce their send rate whencompetition intensifies. Therefore a new transport protocol called the DatagramCongestion Control Protocol (DCCP) is being designed to provide applicationsthat do not desire the service model of TCP with an alternative. Currently,DCCP includes two profiles for congestion control, TFRC and TCP-like. Forthese new algorithms verifying the design, identifying weaknesses and suggestingimprovements, as I have done, is important in order to drive the developmentforward.

Through the studies that comprise this thesis, I contribute to the stableoperation of the future Internet and the merging with wireless cellular dataarchitectures.

i

Contents

Abstract i

Publications v

Acknowledgments vii

Thesis Introduction 11 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1 The Internet . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Wireless Wide-area Networks . . . . . . . . . . . . . . . . 5

2 Research Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Continuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Papers 15

1 Congestion Control in a High Speed Radio Environment . . . . . 17

2 On the TCP Minimum Retransmission Timeout in a High-speedCellular Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3 Buffer management for TCP over HS-DSCH . . . . . . . . . . . . 45

4 Properties of TCP-like congestion control . . . . . . . . . . . . . 67

iii

Publications

The following papers are included in this thesis:

• Paper 1

Sara Landstrom, Lars-Ake Larzon and Ulf Bodin, “Congestion Controlin a High Speed Radio Environment”. In Proceedings of the InternationalConference on Wireless Networks, pages 617-623, Las Vegas, Nevada,USA, 21-24 June 2004.

• Paper 2

Mats Folke, Sara Landstrom and Ulf Bodin, “On the TCP Minimum Re-transmission Timeout in a High-speed Cellular Network”. To be presentedat 11th European Wireless, Nicosia, Cyprus, April 10-13 2005.

• Paper 3

Sara Landstrom and Lars-Ake Larzon, “Buffer management for TCP overHS-DSCH”. Technical report, LTU–TR–05/09–SE, Lulea University ofTechnology, Sweden, February 2005.

• Paper 4

Sara Landstrom, Lars-Ake Larzon and Ulf Bodin, “Properties of TCP-likecongestion control”. In Proceedings of the Swedish National ComputerNetworking Workshop, pages 13-18, Karlstad, Sweden, 23-24 November2004.

Furthermore, a report describing the ns-2 module for simulating HSDPA will beavailable as a technical report during 2005 with the title “Description of HSDPAmodule for ns-2”, with me and Mats Folke as authors. The user manual willalso be made available at http://www.csee.ltu.se/∼saral.

v

http://www.csee.ltu.se/%E2%88%BCsaral%00

http://epubl.ltu.se/1402-1536/2005/09/index.html

Acknowledgments

The first person that I would like to thank is my supervisor, Lars-Ake. Lars-Ake has believed in me from the start and he has always invited me to askquestions, share ideas and discuss everything that remotely relates to being aPh.D., student. To Ulf and Krister, who have been my assistant supervisors,I’d like to say that I appreciate our discussions and your involvement in myeducation.

Among my colleagues in the Computer Science and Networking hallway,Mats deserves a special thank you. His help and willingness to discuss everydayproblems and ideas have been a valuable asset to me. My fellow Ph.D., studentsall have one thing in common, they are helpful and nice company. I would alsolike to direct a thank you to Arne Simonsson at Ericsson Research AB, foralways taking the time to answer my questions.

Waiting for me to come home each day is my daughter Emelie. Thankyou for reminding me that there is a world, where entirely different things areimportant than the things I struggle with at work. I would also like to thankmy husband Peter for all his love, support, and patience.

My research has mainly been supported by Vinnova, the Swedish Agencyfor Innovation Systems, but also by the PCC++ graduate school and EricssonResearch AB. Thank you for your financial support and for providing me withthe opportunity to work with you.

vii

Thesis Introduction

Thesis Introduction 3

1 Introduction

In this section a short introduction to networking and wireless wide-area net-works is given. It also serves to set the stage for the research presentation thatfollows.

1.1 The Internet

“The Internet was conceived in the era of time-sharing, but has survived intothe era of personal computers, client/server and peer-to-peer computing, and thenetwork computer.” [40]There was a time when computers were expensive and rare, sharing their com-puting power therefore seemed appealing. Others, like J.C.R Licklider1, foundthe novel ways through which humans would be able to communicate througha computer network to be a driving force.

It was quickly realized that computers communicate in a different way thanhuman beings, therefore the circuit-switched approach that is used in ordinaryphone systems was deemed unsuitable. Instead of circuits, packet-switching wasconsidered to support the bursty computer communication pattern. The firstpaper on packet-switching theory was published in 1961 [36]. Information thatis to be sent is gathered into packets before being sent towards the destinationand each packet is handled individually, not as part of a sequence of packets,by the nodes relaying traffic in the network. The internal network nodes bufferdata if the outgoing link is occupied when a packet arrives for it. The mannerin which the buffers are managed affects network performance.

In short, the Internet can be thought of as a network of roads, where cars(packets) share the road along certain routes. The degree to which the trafficfrom different connections are mixed together is called the degree of statisticalmultiplexing.

The transport and forwarding service of the Internet was first intended to becarried out by one protocol, called the Transmission Control Protocol (TCP) [8].However, it was hard to support all the application requirements within oneframework. For instance early work on voice applications revealed that packetlosses in some cases were better dealt with by the application. Therefore, theaddressing and forwarding of individual packets was removed from TCP andthe Internet Protocol (IP) was formed to provide these services.

IP and its datagrams represent the minimum building block of a computernetwork, as illustrated in Figure 1.1. The User Datagram Protocol (UDP)was also created to give access to the services of IP, which are best effort, andto provide process multiplexing. The significance of the best effort paradigm isthat a packet, may or may not arrive at its destination depending on the currentstatus of the network. For instance, no guarantees are given neither regardingthe delay and integrity of a packet, nor the order in which packets will arrive.This model was adopted since few assumptions about the underlying network

1J.C.R Licklider has been attributed the first recorded description on the social interactionsthat may be possible through interconnecting computers.

4 Congestion Control in Wireless Cellular Networks

Network

IP

TCP UDP

Application

Figure 1.1: A simple illustration of the layering principle of the Internet.By Network I refer to network technologies such as Ethernet, token ring andIEEE802.11.

technologies had to be made. As a result, networks can be built on top of verydiverse technologies. The choice of placing advanced algorithms and state in theend-nodes, instead of in the internal network nodes, has strongly contributed tothe success of the Internet.

In the spirit of academic tradition the specifications of the computer networkprotocols were made available for free. A dynamic forum for the exchange ofideas was created by Crocker in 1969 when he started the request for comments(RFC) series [9]. The RFCs have become Internet standardization documentsand the standardization documents of concern for this thesis are now beingproduced within the Internet Engineering Task Force (IETF).

IETF stems from a board of researchers created by the Advanced ResearchProjects Agency (ARPA) to give technical advice on the Internet program in1981. Due to the heterogeneity of the Internet, one of the technical beliefs ofthe IETF is that tight engineering optimizations are generally not feasible.

The first TCP versions included a method for the receiver to control the rateat which the sender was transmitting, but no algorithms for handling dynamicnetwork conditions [54]. As the number of hosts connected to the Internet grew,the need for dealing with the variable network conditions arose [47]. In the late1980s the Internet suffered from the first of a series of congestion collapses,i.e., the network became overwhelmed by the traffic load, which prevented itfrom doing useful work. In order to ensure the operability of the network, aTCP sender should attempt to adapt its send rate to a level which can behandled by the network under the current circumstances. Thus, a numberof algorithms under the name of “Congestion Avoidance and Control” wereproposed by Jacobson for TCP in 1988 [33] to achieve network stability.

The congestion signals, which the algorithms are to respond to, can be eitherimplicit, such as packet losses or increasing round trip times, or explicit, as wheninternal network nodes signal congestion by setting a dedicated bit in a packet


header. The current Internet architecture can not disregard from implicit signalssince it is not possible to assume that explicit signaling is supported along theentire network path between two communicating network nodes.

The flows representing the majority of the long-lived sessions in the end ofthe 1980’s ran on top of TCP, therefore congestion control was made part ofTCP. However, the user and application behaviors are different today. Newapplications, like streaming and gaming applications, with realtime demands onthe transport service have lead to longer lived UDP sessions. The TCP proto-col includes mechanisms, such as a reliable in-order delivery service guarantee,which introduce variations in delay and less control over the data flow froman application point of view. Therefore UDP is preferred by applications withstrict timing requirements.

Out of concern for the changing traffic patterns, an initiative to provide UDPflows as well with congestion control was taken. The effort lead to the designof the Datagram Congestion Control Protocol (DCCP) [19]. The protocol hasbeen built as a toolbox from which a suitable congestion control profile can bechosen. The limitation of the protocol is foremost the existing congestion con-trol profiles. One of the problems with designing congestion control algorithmsis that this mechanism also performs resource allocation when resources becomescarce. Thus it is desirable that the algorithms are fair to other existing con-gestion control schemes, i.e., that of TCP, and avoid starving other flows alsoimplementing congestion control.

The future of DCCP depends on whether it will gain acceptance by thewider network community or not. For application designers it is a big step tochange from UDP to DCCP. As a measure of complexity it can be mentionedthat UDP is defined in about ten pages, whereas DCCP consists of a minimumof three specifications where the largest is almost two hundred pages. A barrierfor deployment is the use of Network Address Translation (NAT) tools andfirewalls, which have to be extended to correctly handle DCCP.

Meanwhile, the Internet has become a gathering of both wired and wirelessnetworks. In the next section I will discuss the history of the mobile telephonynetworks and their approach to providing data services.

1.2 Wireless Wide-area Networks

The Internet started out as a project for sharing computer resources, whereasmobile telephony grew out of a desire to provide voice communication while onthe move. These different incentives lead, as we will see, to different designs.

The type of wireless systems that I consider in this thesis are often referred toas wireless wide-area networks (WWANs). They accommodate a large numberof users over a large geographic area, within a limited frequency spectrum2.The land area is divided into cells and the communication within each cell issupported by a base station. The system allows a user to move at a relatively

2The radio frequency spectrum is controlled by governments, therefore techno-politics hasa major impact on this industry.


high speed while being engaged in a session and switching cells over a widearea. The mobile switching center (MSC) coordinates the activities of all thebase stations and connects the cellular system to the public switched telephonenetwork (PSTN).

It all began in 1895 – Nikola Tesla was ready to transmit a radio signal50 miles to West Point, New York, when a fire consumed his lab. MeanwhileGuglielmo Marconi had been granted a patent for the wireless telegraphy inEngland in 1896. One year later, he used the Tesla oscillator to demonstratethe usability of radio in mobile communication through keeping in contact withships sailing on the English channel [55]. The world’s first wireless cellularsystem was however not implemented until 1979 in Japan by Nippon Telephoneand Telegraph company (NTT). The invention of the cellular concept enabledlarge-scale radio communications and was refined by many telecommunicationcompanies working in parallel. The idea is to split the coverage zone into smallcells and reuse portions of the spectrum to increase spectrum usage at theexpense of a larger infrastructure.

Here in Scandinavia, the Nordic Mobile Telephone (NMT) system was intro-duced in 1981. It belongs to the first generation of mobile systems, which weregenerally incompatible in Europe due to the use of different frequencies andprotocols. The first universal digital cellular system (2G) that gained world-wide acceptance was the Global System for Mobile (GSM) deployed in the early1990s. GSM was designed before the Internet became a commodity and hencethe data rate requirements were low, since voice produces relatively low bit ratetraffic. In order to increase the 2G data rates for Internet type of services anumber of techniques under the name of 2.5G were developed. For GSM, HighSpeed Circuit Switched Data (HSCSD), General Packet Radio Service (GPRS)and/or Enhanced Data rates for GSM (or Global) Evolution (EDGE) are viableextensions.

The third generation of GSM technology (3GSM) has a Wideband-CDMA(W-CDMA) air interface, which has been developed as an open standard byoperators in conjunction with the 3GPP standards development organization.Already over 85% of the world’s network operators have chosen 3GSM’s under-lying technology platform to deliver their third generation services [24]. Anothername for W-CDMA is Universal Mobile Telecommunications Service (UMTS).W-CDMA includes a shared high-speed channel for traffic from the base stationto the mobile users. This high-speed shared downlink packet access (HSDPA)mode is the focus of several of the studies in this thesis. Figure 1.2 illustratesthe evolution of the mobile cellular networks.

The telecommunication industry has not been able to agree on one global3G standard. Therefore a second partnership project (3GPP2) is developinganother 3G standard in parallel to W-CDMA, which is called cdma2000 and isnot building on GSM technology. The partners are from North America, Japan,Korea and China.

The roots of the wireless wide-area networks are in the telephone industry,from which users have come to expect a high quality of service and a high degreeof stability. Telecommunication is often referred to as having 6 nines, 99.9999%,


2G IS-95 GSM IS-136 & PDC

2.5GGPRS

IS-95B HSCSD EDGE

3Gcdma2000-1xRTT

cdma2000-1xEV, DV, DO

W-CDMA

EDGE

TD-SCDMA

HSDPA

Figure 1.2: The evolution of different WWAN technologies.

availability. Requirements of the emergency services are one of the reasons forthe high demands.

From being a voice call communication systems, the mobile wireless cel-lular systems have evolved in the direction of the Internet. Since the systemwas originally designed for voice traffic with circuit-switching as the means fordistributing capacity, certain changes have been necessary to connect to the In-ternet and allow data traffic to be transferred. The core business is however stillvoice calls. The quality of this service must therefore also be ensured henceforth.Different types of messaging services, like the short message service (SMS) andthe multimedia message service MMS, have also become popular.

Wireless local-area networks (WLANs) on the other hand have a backgroundin data services. In general they provide higher data rates at the expense ofmobility compared to WWANs. The user is required to stay close to an accesspoint to achieve the high data rates. Followers of the successful IEEE802.11standard, IEEE802.16 and IEEE802.20, are currently being designed to allowincreased coverage [57], e.g., wireless broadband to residents and for small officeuse. The primary standardization organs for WLANs are the Institute of Elec-trical and Electronics Engineers (IEEE) and the European TelecommunicationsStandards Institute (ETSI).

The wireless media and user mobility challenge some of the implicit assump-tions that were made when designing the congestion control and avoidance mech-anisms of TCP. Transmission errors are more frequent [2] and round trip timesmay vary to a larger extent than in a wired network [41]. Another key issue isthe efficient utilization of the available frequencies, since the licenses for the ra-dio spectrum is relatively expensive. This is in contrast to the IETF philosophy


that tight optimizations are virtually impossible due to heterogeneity.

2 Research Area

There are many challenges to the Internet and the telecommunication industry.In this section I will briefly touch upon a few of them, which are related to myresearch.

Transporting both voice and data traffic as packet-switched services at theIP layer would allow the efficient deployment of new services, such as real-timemultimedia with integrated voice and video. Furthermore, having an all-IPnetwork instead of separate voice and data networks means that fewer pieces ofequipment need to be deployed and maintained.

Voice over IP (VoIP) is the key to a common IP platform for wire line andwireless networks. Still, the traditional circuit-switched voice networks havebeen well tuned for efficient spectrum utilization, thus VoIP has a lot to provein regards to its cost effectiveness. Nonetheless a first step was taken on the25th of August, 2003, when a specification for Push to talk over Cellular (PoC)was submitted to the Open Mobile Alliance (OMA) [48].

The interest for VoIP over wired networks is also growing. This trend hasthe potential to change the traffic patterns on the Internet. A larger share oflong-lived UDP sessions is undesirable from a network point of view, since noregulation of the traffic flows is performed by UDP. The network may thereforebecome unstable and perform a high degree of useless work.

Congestion control performs resource allocation when competition for re-sources is intense. Therefore the problem of delivering service assurances andperforming congestion control are related. Time-constrained services using UDPare pushing the development of congestion control profiles that combine satis-factory service delivery and network stability. For flows with strict timing re-quirements, there is a send rate threshold below which the data stream will beuseless to the receiver and there is also a maximum delay that can be tolerated.

A forum for exchanging ideas in this area has been the IETF working groupfor DCCP [31]. DCCP is a new transport protocol which offers no deliveryguarantees. The objective is to create an alternative to UDP for long-lived trafficflows, which applies congestion control. I have followed the standardizationprocess of DCCP, whose main weakness is the usability of the congestion controlprofiles it currently provides. This is a key question to resolve for the successof DCCP.

IP-based traffic is often characterized as bursty, especially when TCP isused as transport protocol. To maintain high system utilization for IP-basedtraffic over WWANs, gathering data from multiple users may be beneficiary.Shared channel solutions of which HSDPA is one example are therefore likely tobecome more common. The problem with service multiplexing is to be able togive service assurances when mixing data from many users and/or of differenttraffic types.

The level of service quality required is tied to peoples’ expectations and


habits and it comes into focus when a service is to be offered building on an-other technology than before. For example telephone services are now beingprovided over the Internet and wireless cellular mobile networks are offeringdata services. With this development follows culture clashes. We expect a cer-tain call reliability, whereas we are quite familiar with the best-effort thinking ofthe Internet. We are used to pay different taxes for our telephone calls, but wedo not usually get a differentiated bill for our Internet usage. Thus, in workingwith technology we must be aware of these conceptions and allow the marketto mature.

2.1 Focus

My work is related to the heterogenous platforms and diverse applications, as-piring to become part of the global Internet. In my research I attempt to findsolutions for applications in an all-IP network that involves both wired and wire-less links. There may still be links requiring special attention and techniquesto enhance performance. In such situations I believe that solving the problemslocally is often preferable if the technology is widely spread. When new inven-tions are being made it is important to be there from the start and develop ageneric solution.

I am particularly interested in how congestion control can be used to allow acontinued profileration of applications, in a way that does not disturb the currentcore activities of a subnet. Furthermore, understanding how new services canbe introduced in cellular systems and how applications can co-exist in a cellularenvironment is of interest to me. Therefore I have studied the existing congestioncontrol algorithms and those that are under development, as well as generaldesign of transport protocols.

My research around HSDPA aims to widen the understanding of the specialcharacteristics of a wireless cellular system with channels especially designed fordata transport. There are many points in common between HSDPA and thenext generation of WLAN technologies as well.

Producing implementations is an important part of networking research,since much of the research is applied and theoretical analysis usually does notallow design choices to be critically tested in a wide range of settings. I haveworked with implementing HSDPA, DCCP and a queue management techniquecalled PDPC. The existence of implementations makes it easier to perform re-search into these areas and pushes development forward.

3 Methodology

The eligible tools for performance analysis of computer systems are measure-ment, simulation and analytical modeling. The system must be studied underan appropriate workload and its performance evaluated by a suitable metric.


3.1 Data Collection

My approach in this thesis has been mainly experimental. I have used sim-ulations and modeling. Several factors have lead to the wide-spread use ofsimulation within the networking discipline. Firstly, networks are large andheterogeneous, making it difficult to derive a theoretical model. Secondly, theresults of a study should be repeatable, but certain network elements like theradio media inherently introduce variations.

Analytical modeling and simulation can be used in any stage of the life-cycle of a product, but measurement requires that a prototype exists and accessto the system, which is often restricted. Measurement may seem the mostaccurate evaluation method, but environmental parameters, which are oftenuncontrollable, may make it difficult to generalize from the results [34]. Theimportance of measurement is nevertheless its unique potential to provide acrucial “reality check”.

Compared to measurement, simulation allows a wider range of parametersettings and environments to be explored – often at a lower cost. Simulationgenerally requires less assumptions than analytical modeling and can includemore details, thus often resulting in a higher accuracy. It is also an importanttool for developing intuition. Preferably, a combination of methods should beused in collaboration to strengthen the results of a performance evaluation study.

In order to elevate the state-of-the-art in Internet simulation, an effort wasmade in the late 1990s to extend and advance the Network Simulator, ns-2.The key goal being to facilitate studies of scale and protocol interactions [52].I have used ns-2 as my simulation platform throughout this thesis. It containsdetailed models of the transport layer protocols and queuing strategies I haveidentified as important to study. Also, since the simulator is frequently usedby many researchers bugs are likely to be discovered and studies can be madecomparable. In most cases some modifications have been necessary to bring thecode up-to-date and create the simulation scenarios. A firm recommendationwhen dealing with ns-2 is to make sure by yourself that the codes simulateswhat you think it does and to also check all the parameter settings.

When performing simulations I have consulted the rich literature describingthe particular difficulties associated with networking simulation studies and alsooffering some advice [52], [61], [21], [51], [13] and [17]. I have also tried tovalidate the simulation results through detailed analysis of the protocols andtechniques under study. Therefore I have often started with relatively simplescenarios, where it is easy to fore say the outcome with knowledge of the elementsunder study. Another advice is to begin by retrieving a lot of data from thesystem for validation and to provoke important events. In [28] current validationtechniques are outlined.

Dr. Ulf Bodin implemented the first version of a ns-2 module for simulatingHSDPA. This module has later been extended and refined by me and MatsFolke. In this work, we have been confronted with many decisions regardingthe appropriate level of detail. A lack of detail can cause wrong answers bybeing incorrect or simply inapplicable (not moving within a relevant part of the


design space). On the other hand it takes time to implement additional details,debug and change as development continues. Foreseeing the future is virtuallyimpossible. Details may also distract from the research problem at hand andeven make the effects less distinct. In order to enable large-scale simulationsthe appropriate level of detail must therefore be chosen with care [27].

If you have knowledge of the situation that you are to study it is easier tochoose an appropriate level of detail, since then it is possible to reason aboutthe effects that a certain part might have in that particular setting. By clearlystating which assumptions that we have made and which scenario the modelis intended for, we guard against misuse of the model and encourage others togive us feedback on our simplifications.

In addition to the simulation experiments, I have put forward and supervised“real-world” projects:

• Within the frameworks of a network project for undergraduate students akernel version of DCCP for FreeBSD was implemented [12]. The resultingcode has been built into FreeBSD Kame and is still maintained throughthem [30].

• A Master Thesis student, Magnus Erixzon, implemented a down-scaledversion of DCCP called DCCP-Thin in Symbian OS. This implementationwas tested over a mobile cellular link (GPRS) and its performance wasrelated to that of TCP under similar conditions [11].

In theory, experimentation may seem straightforward, but when designingan experiment there is suddenly a lot of hard questions to resolve before eventhe first experiment can be carried out - knowing which data to extract, whichparameters to vary (if possible), their relevant values, configure the protocolsright etc. Experimentation requires an infinite amount of patience and judi-cious planning, as well as an observant practitioner during the execution of theplans. Furthermore, experience with the environment and experimental work isa factor, which I have seen the effect of in my work. And still, data gatheringis only a first step.

There are no absolute guarantees when it comes to simulation. I have care-fully selected the methods used, applied them and scrutinized the outcome.

4 Contribution

My research contribute to bridging the gap between wire line and wireless net-works, by ensuring that new transport protocol mechanisms are evaluated forthe wireless realm. Parts of my research aim at widening the understanding ofhow shared WWAN channels can be used and identifying issues that need to beconsidered when managing these networks. Finally, research into appropriatecongestion control algorithms for time-constrained services is important to thenetwork community as a whole and its potential for further growth.


Seen from a larger perspective this type of research may in the end resultin better user perceived performance regarding the quality and availability ofservices in WWANs. This requires efficient service implementations.

Paper 1

The first paper, Congestion Control in a High Speed Radio Environment, wasalso the first paper in time. It is an evaluation of TFRC and TCP in HS-DPA. The purpose of the evaluation was to detect any weaknesses in the designof TFRC and whether any interactions between radio-block scheduling at thelink layer and congestion control algorithms at the transport layer would beproblematic.

By exposing TFRC to many different environmental conditions, as this studyis an example of, we will arrive at a robust design suitable for wireless environ-ments as well.

As part of this evaluation I updated the TFRC code in the widely spreadnetwork simulator, ns-2, to conform to the RFC standard. The earlier imple-mentation was produced prior to its standardization.

Paper 2

On the Minimum Retransmission Timeout of TCP in a High-speed cellular en-vironment is a continuation of the work in the previous paper. Except for a fewcorner cases TCP works rather well in wireless networks. One of its weaknessesis the use of a timer to determine when a packet is to be retransmitted. Delayvariations are inherent to a radio environment and the timer may prematurelytrigger retransmissions if there are sudden delay variations. A lower bound onthe retransmission timer has historically been motivated by poor clock granu-larity and the “conservation of packets” principle described in [33], but lately amuch reduced lower bound has been adopted in modern implementations [26].

We have evaluated the effect of decreasing the minimum retransmit timeoutinterval on TCP performance for HSDPA. The importance of the minimumretransmit interval to the performance of the retransmit timer has previouslybeen pointed out in [13]. Since TCP is a central part of the current networkarchitecture, optimizing its behavior for a particular environment may lead to anoverall performance degradation. It is therefore important to evaluate the effectof proposed changes to the protocol under conditions which may be problematic.

I contributed with the idea of investigating the impact of changing the lowerbound on the retransmission timeout interval, assisted in interpreting the resultsand participated in the writing process.

Paper 3

Buffer management has previously been shown to have a significant effect onTCP performance over both wired and wireless links. In the paper BufferManagement for TCP over HS-DSCH I study the problem of finding a robust


and efficient buffer configuration for a high-speed shared channel, when data isbuffered for each user individually. A similar problem was studied for dedicated3G links in [10] and its companion papers. I wanted to see if their findings alsoapplied to a shared wireless high speed channel and I also contribute throughidentifying a number of factors that must be considered when performing buffermanagement for HSDPA.

The buffer strategy called Packet Discard Prevention Counter (PDPC) pro-posed in [59] for low statistical multiplexing environments was implemented forns-2 by me as part of this study.

Paper 4

In the last paper, Properties of TCP-like Congestion Control, I have analyzedthe design of a congestion control algorithm that attempts to imitate the con-gestion control and avoidance behavior of TCP, but within an unreliable serviceconcept. TCP-like congestion control is currently being standardized by theIETF and a sanity check of the algorithm was therefore motivated before de-ployment can be recommended.

I have supervised a Master’s Thesis worker named Nils-Erik Mattsson, whileimplementing a substantial part of the Datagram Congestion Control Protocol(DCCP) protocol into the network simulator, ns-2. Among other features DCCPincludes TCP-like congestion control. The code is available and has been handedout to a number of interested parties.

The work presented here is part of a larger evaluation of DCCP and islinked to the TFRC study in Paper 1. Comparing the use of TFRC and TCP-like congestion control for streaming and real-time applications is the next step.We have also made an implementation of DCCP-Thin for Symbian OS. Theobservations made for DCCP-Thin are reported in [11] and will also be presentedin Linkoping at “Radiovetenskap och Kommunikation” (RVK 05), 14–16 June,2005. Furthermore, a kernel version of DCCP for FreeBSD and a patch forEthereal were released as part of a network project which I have proposed andsupervised [12].

My contribution

In all the papers included in this thesis, but Buffer Management for TCP overHS-DSCH, I have been the main author and carried out all the experimentalwork.

5 Continuation

My efforts up to this point have been concentrated on evaluating a number ofcongestion control mechanisms. We have observed the performance in terms ofsystem throughput, fairness and individual transfer rates. These are metrics


primarily suitable for bulk transfers, but also reasonable when studying rela-tively new algorithms, with the purpose of validating their operation. Whendata is being produced during the session itself or the client wishes to hold onlysmall portions of a flow at the time, the application behavior can be quite dif-ferent and the set of metrics used so far incomplete. Studying the performanceof new congestion control algorithms for applications with harder timing con-straints in depth, with appropriate application models and performance metricsis therefore part of my future plans.

There are a number of issues that can be seen such as congestion control re-sponse to application limited periods, start up costs, discrete send rates, packetsizes, smoothness, a minimum useful transfer rate and delay variations as per-ceived by the user. A related question is to investigate which information anetwork can provide in order to improve congestion control and thus applica-tion performance. Also, can the network use existing congestion control algo-rithms to prioritize certain services higher than others by feeding them differentinformation?

Furthermore, the multitude of applications seems to grow indefinitely. Tra-ditional cellular networks have been built and optimized for one main service,i.e., phone calls. These networks are now being transformed into a platformsupporting a magnitude of services. If optimizations are attempted for each ser-vice the network is likely to become highly complex, therefore it is interestingto investigate how the services can co-exist and where tuning of the network isnecessary.

Papers

15

Paper 1

Congestion Control in a HighSpeed Radio Environment

17

Paper published as

Sara Landstrom, Lars-Ake Larzon and Ulf Bodin, “Congestion Control in a High SpeedRadio Environment”. In Proceedings of the International Conference on WirelessNetworks, pages 617-623, Las Vegas, Nevada, USA, 21-24 June 2004.

18

Congestion Control

in a High Speed Radio Environment

Sara Landstrom†, Lars-Ake Larzon†,‡, Ulf Bodin†

†Lulea University of Technology‡Uppsala University

Abstract

This paper explores interactions between congestion control mechanismsat the transport layer and scheduling algorithms at the physical layer inthe High-Speed Down-link Packet Access extension to WCDMA. Two dif-ferent approaches to congestion control – TCP SACK and TFRC – arestudied. We find that TCP SACK and TFRC in most respects performthe same way. SIR scheduling yields a higher system throughput for bothcongestion control algorithms than RR scheduling, but introduces delayvariations that sometimes lead to spurious timeouts. The no feedbacktimeout of TFRC exhibits similar sensitivity to delay spikes as the re-transmit timeout in TCP SACK. The consequences of delay spikes arehowever different.

1 Introduction

The High-speed Down-link Packet Access (HSDPA) mode, is part of the 3GPPWCDMA specification release 5 [29]. It supports peak data rates in the order of10 Mbps with low delays. A key component of HSDPA is the channel scheduler.The channel is divided into 2 ms slots that are assigned to the users accordingto a scheduling algorithm.

A round-robin (RR) scheduler lets users take turns to transmit in an orderlyfashion, whereas a signal-to-interference (SIR) scheduler gives precedence to theuser with the best predicted signaling conditions.

As scheduling is tightly coupled to data availability - which is regulated ata higher level by the transport protocol - we study the interactions betweencongestion control in the transport layer and channel scheduling in the physicallayer.

Of the transport protocols that perform congestion control, TCP is the mostwidely deployed. Another way of performing congestion control is to applyTCP Friendly Rate Control (TFRC) in which an equation-based model of TCPReno, derived in [49], is used. TFRC has been designed to give smoother rate


changes compared to TCP and is primarily suitable for streaming media appli-cations [20]. An important factor in the send rate equation is the estimate ofthe round trip time.

In this paper, we study the performance of TFRC and TCP over a HSDPAlink layer with both a RR and a SIR scheduler. As expected, SIR is not as fairas RR, but does on the other hand give significantly larger throughput to theusers with the best SIRs. We found channel utilization helpful in explaining theobserved loads and comparing the two congestion control algorithms. TFRCand TCP performed equally well. Both protocols are however sensitive to delayspikes resulting from SIR scheduling and performance could be improved in thisrespect.

2 TFRC vs. TCP

TCP SACK (from now on referred to as TCP) is a complete transport protocolwith many different features such as congestion control, reliability and sessionmanagement. In this study, we focus on the mechanisms that affect data avail-ability in lower layers, i.e., the congestion control and avoidance mechanisms.

We compare TCP, to the alternative approach to congestion control givenby TFRC. There are a number of fundamental differences between TCP andTFRC - TCP is sender-oriented and uses a sliding window to control the sendrate whereas TFRC is receiver-oriented and uses an equation-based scheme. Inthe following sections we briefly describe the transport layer mechanisms thatwe study in this paper, and how they differ between TFRC and TCP.

2.1 Adaptive timeouts

If the sender does not receive an acknowledgment of transmitted data beforea timeout, the sending rate is reduced as timeouts are interpreted as signsof network congestion. Both TFRC and TCP use a moving average filter onRTT samples to calculate an RTT estimate that controls the timeout values.However, where TCP reduces the sending rate to a minimum after a timeoutand forces the sender into slow start, TFRC only halves the sending rate. Thereason is that this TFRC timeout, called the no feedback timeout, is only asupplement to the retransmit timeout of TCP. The TCP retransmit timeoutis instead modeled by the send rate equation that TFRC complies to. Theno feedback interval is relatively long (four times the estimated RTT) to becompared to the retransmit timeout, which is set to the estimated RTT with amargin accounting for RTT fluctuations.

The Eifel algorithm, presented in [41], has the potential to improve TCPperformance in wireless systems by making it possible to faster regain the sendrate used before a timeout if the acknowledgment causing the timeout arriveslate. Timeouts that would not have occurred if the timeout interval had beenlonger are called spurious. The appropriate actions to take after a spurioustimeout are however still being debated [26].

Congestion Control in a High Speed Radio Environment 21

2.2 Congestion avoidance

During normal operation, i.e, when the sender has left the slow start phase,the send rate is increased slowly to avoid filling up queues too fast. In TFRC,the receiver detects lost packets through the arrival of three later sent packets.Packet losses during one RTT only result in one congestion event, as in TCP.The TFRC receiver informs the sender of the perceived loss rate, p, and thereceive rate, Xrecv, which the sender uses to calculate a tentative new sendingrate, Xcalc using equation 1.1.

Xcalc =s

R + f(p), (1.1)

where s is the mean packet size, R the round trip time and f(p) is given by

f(p) =√

2 ∗ p

3+ 12 ∗

√3 ∗ p

8∗ p ∗ (1 + 32 ∗ p2). (1.2)

To determine the new sending rate, the computed sending rate is compared tothe receive rate according to equation 1.3

Xsend = min(Xcalc, 2 ∗ Xrecv). (1.3)

As TCP uses cumulative acknowledgments, a duplicated acknowledgment(dupack) indicates an out-of-order reception of data. Upon reception of foursuccessive acknowledgments, all with the same acknowledgment number, TCPassumes a packet lost and halves its sending rate.

2.3 Slow start

In the beginning of each transfer and after a timeout in TCP, the session is in aslow start phase. During this phase, the send rate increases exponentially untila lost packet is detected. In TCP, this is accomplished by increasing the windowthat controls the send rate proportionally to the number of acknowledgmentsreceived.

TFRC mimics the TCP slow start behavior when the estimated loss rateis zero by doubling the sending rate once per round trip time, if the reportedreceive rate matches the current send rate. If the receive rate is lower than thesend rate, the new sending rate is set to twice the receive rate. This means thatthe sending rate is limited only by the current values of Xsend and Xrecv untila loss event occurs.

3 Evaluation

Our evaluation of TFRC and TCP over the high speed down-link channel (HS-DSCH) in HSDPA is based on simulations. Performance is investigated bothfor an RR and a SIR scheduler using two different loads. This results in fourscenarios for each congestion control mechanism.


3.1 Model

The network simulator version 2.27 (ns-2) was complemented with a module forsimulating HSDPA [5]. We also modified the TFRC code to follow RFC3448and measures were taken to remove the bug reported in [18]. The changes aredescribed in a document retrievable from http://www.csee.ltu.se/∼saral.

Table 1.1 gives an overview of the radio models implemented and their con-figuration.

Phenomena Model/ConfigurationPath loss Exponential, propagation constant

3.5Shadow fading Stddev 8dBSelf interference Constant 10%Intra cell interference (orthogonality) Constant 40%Inter cell interference Modeled by distance and shadow fad-

ingFast HARQ No, immediately retransmittedCode multiplexing Max 3 usersBLER Uniformly distributed, 10% for SIRs

over −3.5dB, 50% for lower SIR lev-els

Table 1.1: Summary of radio models and parameters

There is no fast power control over the high speed shared channel, insteadlink adaptation is employed. The combination of coding rates and modula-tion types included in the simulator are introduced in Table 1.2 and SIR levelswere established in [50]. Note, with these combinations a maximum bit rateof 7.20 Mbps can be achieved. We assume that the number of spreading codesand the power assigned to HS-DSCH, change on long time scales compared tothe simulation time. The average power was fixed to 10 W and 12 out of 16channelization codes were used.

Coding Modulation SIR Bitrate Radio block(Rate) (Type) (dB) (Mbps) (Bytes)0.25 QPSK -3.5 1.44 3600.50 QPSK 0 2.88 7200.38 16QAM 3.5 4.32 10800.63 16QAM 7.5 7.20 1800

Table 1.2: Combinations of coding rates and modulation types

Seven cells with omni-directional antennas and a 500 m radius were simu-lated and the performance in the center cell was analyzed. A fixed delay wasused to model the delay over the wired links between the sources and base sta-

http://www.csee.ltu.se/%E2%88%BCsaral%00


tions. The delay, 75 ms, was the same in both directions. The wired links wereover provisioned such that the bottleneck was over the wireless link. Whenreaching the base station user data were stored in individual buffers, each capa-ble of keeping 90 IP packets. This means that it is possible for a single user tocapture the wireless channel with SIR scheduling. With our simulation set-up,packets can only be lost in the queue awaiting transport over the wireless link.

We varied the load by simulating either 50 or 65 (30% more) stationarymobile terminals present in the coverage area. The nodes were distributeduniformly over the seven cells. The effects of scheduling showing at this load,would probably become apparent at higher loads with better tuned schedulingalgorithms than RR and SIR. Alternatively, the load could have been varied bychanging the average waiting times between transfers.

Every session consisted of a mobile downloading a file followed by a truncatedexponentially distributed waiting time with mean 2 seconds and a minimumvalue of 0.5 seconds. The waiting time was initiated as soon as all the data hadreached the receiver1. The file sizes were randomly chosen from nine possiblesizes where the number of packets i is given by equation 1.4.

in = 2in−1 + 1, for n = 1, 2...9, i0 = 0 (1.4)

The relation between the frequencies with which the file sizes were likely to beselected was 1:2:3:4:5:6:7:8:9, where 9 corresponds to the smallest file size. Tworelatively large file sizes have been included, i.e., 740950 and 1483350 bytes. Thereason was threefold, first for the short file sizes slow start is essentially neverleft. Secondly, the behaviors of the schedulers have larger impact on longer filetransfers and finally, TFRC is targeted at longer lived sessions. A fixed payloadsize of 1450 bytes was used, in order to create the same number of packets forboth TCP and TFRC given a certain transfer size.

TFRC does not include connection establishment nor tear-down, which forshort flows result in higher throughput. Therefore, to enable comparisons, TCPwas configured to send data with the initial SYN segment. By setting the initialwindow of TCP to two segments and sending data on the SYN, the window isdoubled as if no handshake was made. A minimum retransmit timeout of 1second and a timer granularity of 0.01 seconds were used for TCP.

Five minutes system time was simulated in each run and all scenarios wererepeated twenty times. The random number generators giving the positionsof the mobiles, the starting times of the transfers and the file sizes were givendifferent seeds in each replication of the same scenario.

4 Results

When analyzing the material, we aggregated data from all the replications ofthe same scenario. The data from the first 5 simulated seconds in each run wereremoved to avoid initialization bias. Only performance in the center cell was

1We reset the transport layer endpoints after receiving the last piece of data.


studied. In most cases the results obtained for both loads were similar, hence ifnothing else is stated the figures represent the case when there are 65 mobilespresent in the system. The confidence intervals are for 95%.

We have used two approaches when performing the analysis. First, we lookat transport layer events, thereafter we study when data are available to thescheduler.

4.1 Transport layer events

Packet loss – To TFRC, which offers unreliable transport, the packet lossrate is an important metric. If the loss rate is too high the data which reachthe receiver is not going to be useful. Bursty losses may also be problematicdepending on the application. However, when we study the share of packetsthat was lost for TFRC the purpose is to detect dependencies between thetransfer sizes and their loss rates that help our analysis. For instance, thetransitions between slow start and congestion avoidance are controlled by thepacket loss events and how they are detected. An inspection of the packet lossrates experienced by TFRC reveals that there are basically three groups of filesizes, which we will call small, medium and large.

Small: In the first group, the six smallest transfer sizes fall. These flows donot loose any packets and hence never leave slow start due to packet loss.

Medium: The 369750 bytes flows form a group of their own. Approximately80% of these transfers get through intact. The remaining 20% of the flows looseless than a tenth of the data.

Large: For the two largest file sizes the transition from slow start to con-gestion avoidance can not be avoided. In the case of 740950 bytes, the flowsall reach the maximum available capacity and about 15% have high loss rates(20%), since the file sizes are still rather short. For the 1483350 byte flows theloss rate stays below 10%, except in the case of SIR scheduling and 65 mobiles,where 2% of the flows experience higher loss rates. These flows are long enoughto compensate for the high loss rates encountered when probing for an initialestimate of the capacity.

We expect to find that the TCP flows exhibit a similar behavior, since theslow start strategies are comparable.

Detection of packet losses – Long propagation delays potentially resultin each source having large amounts of data residing in the network. Only partsof this data at a given time is actually in the bottleneck buffer. If packets travelclosely together buffer overflow will occur at lower send rates. TCP is window-based and can send several segments back to back. TFRC on the other hand,space out the packets over a round trip time, thereby decreasing the probabilitythat a large part of the data in flight find itself in the queue at the edge of thewireless link simultaneously.

With TCP, the window has to be larger than the bottleneck buffer size tosustain any losses, since new data must be acknowledged before a new segment isreleased. It is most vulnerable to timeouts when quickly increasing the send rateduring slow start, since many segments can then be lost from the same window,


0

0.2

0.4

0.6

0.8

0 1 2 3 4 5 6 7 8 9 10 11 12

Num

ber

of ti

meo

uts

File size (Mbits)

SACK SIRTFRC SIRSACK RRTFRC RR

Figure 1.1: Timeout events for TCP and TFRC.

such that three duplicated acknowledgments are not generated as is needed fora fast retransmission to be made. When a timeout occurs, a parameter calledthe slow start threshold, is set to half the current window, forcing TCP intocongestion avoidance whenever the window size exceeds this value. Since TCPincreases its rate slower during congestion avoidance and the flows are bufferedindividually, later timeouts are connected to decreased bottleneck capacity -leading to an assembly of segments in the sensitive buffer.

In Figure 1.1 the average number of timeouts per transfer size with TCP isshown. The larger number of timeouts with SIR scheduling is caused by changesin the available capacity due to competing sources and not the probing behaviorof TCP. Of the total number of timeouts with TCP and SIR scheduling closeto 70% were spurious.

Due to the fact that it is enough for one packet to reach the receiver toallow the next acknowledgment to be sent in TFRC and the relatively largetimeout interval, no feedback timeouts are rare, see Figure 1.1. No timeouts ofthis type were observed for TFRC with RR. With SIR scheduling there werea few occurrences, but they were considerably fewer than the TCP retransmittimeouts. The no feedback timeouts can not be said to be spurious, since theyare to prevent data from being sent continuously at the same rate when it is notgetting through. Fine-tuning the duration of this interval such that excessivepacket loss does not occur when the bandwidth is suddenly decreased is howeverimportant and so is finding a way to allow the flow to start over relatively quickly


0

0.5

1

1.5

2

2.5

3

3.5

0 1 2 3 4 5 6 7 8 9 10 11 12

Num

ber

of c

onge

stio

n ev

ents

File size (Mbits)

TFRC SIRTFRC RR

SACK SIRSACK RR

Figure 1.2: The average number of congestion events detected through latersent packets arriving at the receiver in TFRC, or through three duplicate ac-knowledgments in TCP.

when resources become available again.

Since there is no packet reordering possible with our network configuration,the arrival of three duplicated acknowledgments in TCP usually confirms theloss of at least one segment2. TCP then has a chance to retransmit the pre-sumably lost segment, before the timeout expires. For TFRC, we observe fewcongestion events being detected by later sent packets arriving in relation to theloss rates. Hence, we conclude that the losses are often correlated and occur inbursts during a round trip time. This type of event is more frequent for TFRCfor the two largest file sizes than the fast retransmits are for TCP, which canbe explained by TFRC being slower to reduce its send rate. The situation isreversed for the 740950 byte files, which is likely to be a consequence of TCPsending its segments back to back instead of spacing them out as TFRC does.Thus, TCP encounters its first losses earlier, i.e., for a smaller file size. The threedupack events and the packet losses that lead to congestion events in TFRC aresummarized in Figure 1.2. The confidence intervals for these events are narrowand there are no apparent differences between the schedulers.

2The exception is if a large number of retransmissions triggered the duplicate acknowledg-ments.


0

0.05

0.1

0.15

0.2

0 1 2 3 4 5 6 7 8 9 10 11 12 13

Sha

re o

f the

slo

ts

Potential number of receivers in each slot

SACK SIR 50SACK RR 50SACKSIR 65SACK RR 65

Figure 1.3: Distribution of the number of potential receivers for TCP.

4.2 Data availability

For system throughput, having data to be transferred at the highest data rate inevery slot represents the optimal situation. However, only the SIR scheduler cantake advantage of having several potential receivers with different SIR conditionsto choose between. A requirement for good throughput, which is independent ofscheduler characteristics, is that there should be at least one potential receiverin each slot. Hence, we focus on the distribution of the number of potentialreceivers for this study.

The distribution of the number of potential receivers for TCP is shown inFigure 1.3 and for TFRC in Figure 1.4. As can be seen, there are few slots thatare not used. SIR scheduling gives a larger concentration around 1-2 potentialreceivers than RR scheduling does and the right tail is thinner for SIR than forRR.

In general the SIR scheduler gets more files through than the RR schedulerwith the same number of users in the system. The current application model,where the waiting period is initiated as soon as the transfer has been com-pleted, leads to high SIR users generating a larger part of the data with SIRscheduling than with RR scheduling. This is not an unlikely scenario however,since poor SIR users might wait for an indication of improved signal receptionbefore attempting transfers. The application model does however discriminateagainst the RR scheduler and we would like to try other application models in


0

0.05

0.1

0.15

0.2

0 1 2 3 4 5 6 7 8 9 10 11 12 13

Sha

re o

f the

slo

ts


TFRC SIR 50TFRC RR 50TFRC SIR 65TFRC RR 65

Figure 1.4: Distribution of the number of potential receivers for TFRC.

the future.When comparing the number of bytes transferred with TCP and SIR schedul-

ing for 50 mobiles and RR for 65 mobiles, the difference in result is smaller thanwhen comparing the system throughput with the same number of mobiles forthe two schedulers. This indicates that an RR scheduler needs a larger numberof mobiles to generate the same offered load, i.e., number of transfers. WithTFRC the RR scheduler never reaches the same levels as the SIR scheduler.Since TFRC is unreliable, the artifacts that might come of SIR scheduling, i.e.,higher loss rates, does not lead to retransmissions and as severe send rate re-ductions. Therefore it is likely that a higher offered load can be sustained andthat the limiting factor may be the influence of the loss rate on the quality.

4.3 Transfer rates

The most important metric for a file transfer is the obtained transfer rate. Thetransfer rates in Figure 1.5, puts the previously observed events into perspective.The difference between the two protocols is small, although the difference inperformance between the schedulers is big.

A metric used in [53] for determining whether the system has appropriatesettings is the 5th percentile transfer rates. According to this metric, the ob-served transfer rates for the HSDPA channel are supposed to be on a level withthe Circuit Switched Equivalent for web browsing, which means that 95% of the


0

100000

200000

300000

400000

500000

0 1 2 3 4 5 6 7 8 9 10 11 12

Bit-

rate

(bp

s)


SACK SIRTFRC SIRTFRC RRSACK RR

Figure 1.5: Average transfer rates for TCP and TFRC.

users should have a bit rate exceeding 50 Kbps. We found that this conditionwas met for both protocols. When looking at the 5th percentile bit rates on aper flow size basis, Figure 1.6 and Figure 1.7, we find that it is the small flowsthat do not reach 50 Kbps. RR scheduling results in higher transfer rates forthis group of flows than SIR, but the RR scheduler operates at a lower offeredload with the current application model.

5 Discussion

Future studies include investigating a range of propagation delays for the wiredlinks in the path and different buffer strategies at the wireless channel. Withthese additional dimensions in the evaluation follow needs to more accuratelytrack delay spikes and their influence on the probability for packet loss. Findingappropriate buffer sizes, that balance the risk of buffer overflow and long queuingdelays for wireless channels and different applications is non-trivial. Especially ifTFRC and TCP are to co-exist in an environment where the available channelcapacity can vary substantially. In this study we used the same applicationmodel for both TFRC and TCP, in the future we would like to include a modelof a streaming application for TFRC and look at other ways to distribute thetransfers among the mobiles.


0

25000

50000

75000

100000

125000

150000

0 1 2 3 4 5 6 7 8 9 10 11 12

Bit-

rate

(bp

s)


SACK RR 50SACK RR 65SACK SIR 50SACK SIR 65

Figure 1.6: 5th percentile transfer rates for TCP.

6 Conclusions

We have performed an initial investigation of how congestion control at thetransport layer, lead to different physical channel utilization patterns for a high-speed shared wireless cellular environment. We have found, that with an appli-cation model where the waiting time is initiated as soon as a transfer is finished,the observed load is the result of both the nature of the scheduling algorithmsfor the shared environment and the congestion control algorithms.

As expected, the SIR scheduler gives higher average transfer rates at theexpense of fairness compared to the RR scheduler. Since high SIR users completetheir transfers faster with the SIR scheduler, a larger part of the generated loadcomes from these users. In general, a higher load is created for the same numberof mobiles with SIR scheduling than with RR scheduling. The main reason beingthat the channel is better utilized partly because the average transfer times areshorter, which leads to a faster initialization of the following transfers.

The difference in transfer rates between TFRC and TCP is small, althoughthe system throughput is higher with TFRC. This can be explained by thedistributions of the number of the potential receivers being similar, thus theretransmissions performed by TCP take up capacity corresponding to the addi-tional transfers performed with TFRC.

We conclude that the common type of application model used in this studyleads to offered loads that depend on algorithms both at the transport and the


0

25000

50000

75000

100000

125000

150000

0 1 2 3 4 5 6 7 8 9 10 11 12

Bit-

rate

(bp

s)


TFRC RR 50TFRC RR 65TFRC SIR 50TFRC SIR 65

Figure 1.7: 5th percentile transfer rates for TFRC.

physical layer. It is however not unreasonable, since users are likely to transfermore data if they get fast responses.

Paper 2

On the TCP MinimumRetransmission Timeout in aHigh-speed Cellular Network

33

To be presented at EW 2005

Mats Folke, Sara Landstrom and Ulf Bodin, “On the TCP Minimum RetransmissionTimeout in a High-speed Cellular Network”. To be presented at European Wireless,Nicosia, Cyprus, April 10-13 2005.

34

On the TCP Minimum Retransmission Timeout

in a High-speed Cellular Network

Mats Folke Sara Landstrom Ulf BodinDivision of Computer Science and Networking

Lulea University of Technology

Sweden

Abstract

HS-DSCH is a high-speed shared radio channel for cellular mobile tele-phony. The algorithm for distributing the channel resources togetherwith the characteristics of the radio medium result in delay variations.The TCP minimum retransmission timeout has effectively alleviated delayvariations in its range from deteriorating TCP performance. But recently,this bound has been shortened in modern widely spread TCP implemen-tations. The aim of our study is to find out how a shorter minimumretransmission timeout affects TCP performance over HS-DSCH.

We have implemented a model of HS-DSCH in the network simulatorns-2. Our simulations cover a wide range of different minimum retransmis-sion timeout values and loads, two types of schedulers (Round-Robin andSignal-to-Interference-Ratio (SIR) scheduling) and two versions of TCP(TCP Sack and NewReno).

Our results show that the number of spurious timeouts increases withthe load. The SIR scheduler causes fewer spurious timeouts in general.The RR scheduler is however better than the SIR scheduler for longerminimum retransmission timeouts. The minimum retransmission timeouthas consequences for goodput fairness, but it does not affect the totalsystem throughput. The studied TCP versions produced similar results.

1 Introduction

The High-Speed Down-link Shared Channel (HS-DSCH) in Wide-band CDMA(WCDMA) release 6 has theoretical peak bit-rates for data services of 14 Mbps [38].Moreover, delays considerably shorter than for other shared data channel tech-nologies in previous releases of WCDMA are supported.

HS-DSCH is primarily shared in the time domain, where users are assignedtime slots according to a scheduling algorithm that runs independently at eachbase station. The short Transfer Time Interval (TTI) of 2 ms, enables fastlink adaptation, fast scheduling and fast Hybrid Automatic Repeat reQuest


(HARQ). The channel was designed for bursty Internet traffic, typical of webbrowsing.

TCP (Transmission Control Protocol) ensures reliable transfer of HTTPtraffic. Avoiding delay spikes is important to TCP. In particular, delay spikesmay cause spurious timeouts, resulting in unnecessary retransmissions and mul-tiplicative decreases in congestion window sizes as described by Inamura etal.[32]. There are several mechanisms in HS-DSCH that can cause considerabledelay variations appearing as delay spikes to TCP.

In HS-DSCH, the data rate depends on the Signal to Interference Ratio(SIR) of the receiving user. Consequently, fluctuations in the interference levelslead to delay variations. SIR is affected by path-loss, fading and interferencefrom other transmissions. Schedulers aiming at optimizing system throughputgive precedence to the channel to users with high SIRs. With a Round Robin(RR) scheduler the delay of an individual IP packet is determined both by thenumber of active users and by the SIR of the receiving user.

Using the network simulator version 2 (ns-2)[44] we evaluate the performanceof TCP Sack[14], [42], [4] and TCP NewReno [16] for the RR and SIR schedulerrespectively. Modern implementations of TCP have a lower minimum bound onthe retransmission timer than the customary 1 second. In this paper we evaluatethe sensitivity of TCP regarding the setting of this minimum bound and itsimpact on the number of spurious timeouts, fairness, goodput and throughput.

2 TCP fundamentals

In TCP the send rate is gradually increased and drastically decreased accord-ing to its congestion control and avoidance mechanisms, thus providing the linklayer with an irregular flow of data. Typically, a TCP source in slow start,begins by sending two to four segments [1] and then waits for the receiver toacknowledge them before releasing more data. The send rate is increased expo-nentially as long as the acknowledgments keep arriving in time. This results inTCP sources alternating between releasing bursts of data and being idle untilthey have opened their congestion window enough to always have data bufferedfor HS-DSCH1. For short transfers, TCP may never reach such a window size.When the first packet is lost, TCP leaves slow start and enters congestion avoid-ance, where the send rate is increased linearly.

When a new segment creates a gap in the receive buffer (i.e. its segmentnumber is not consecutive with respect to previous segments’), the receivergenerates a duplicate acknowledgment indicating where the beginning of the firstgap is. If three duplicate acknowledgments are consecutively received, the TCPsource assumes that the bytes pointed at have been lost due to buffer overflowsomewhere along the data path. The missing bytes are retransmitted and thecongestion window is reduced to half its current size. This retransmission iscalled a fast retransmit.

1We assume that the congestion windows and not the receiving windows limit the TCPsources’ sending windows and that HS-DSCH is the bottleneck.

On the TCP Minimum Retransmission Timeout in a High-speedCellular Network

37

For a fast retransmit to take place, at least three segments sent after the firstlost segment must arrive at their destination and trigger duplicate acknowledg-ments. If segments at the end of a transfer are lost or multiple packet lossesfrom a window occur, there might not be enough segments left to trigger a fastretransmit. The send window may also be too small to begin with. In such casesthe TCP source must rely on its timeout mechanism for recovery. If the oldestsegment is not acknowledged within a time frame, called the retransmit timeout(RTO), the TCP source starts over from congestion window of one segment andre-enters the slow start phase. It then retransmits the presumably lost segment.

The sender continuously samples the round trip time (RTT) and adjuststhe RTO. The RTO is based on the mean RTT and a factor accounting forthe fluctuations in the RTT. Traditionally, there has been a lower bound of 1second on the RTO due to poor clock granularity. We will refer to this bound asthe minRTO. The clock granularity has however improved and therefore somemodern implementations have chosen to significantly reduce the lower bound.For instance Linux version 2.4 uses a minRTO of 200 ms. This might havean impact on TCP performance over wireless links, where the lower boundhas shielded against delay spikes in the range of the lower bound. Such delayincreases can occur if the available forwarding capacity rapidly decreases andthey may cause the retransmit timer to expire prematurely.

With Selective Acknowledgments (SACKs) [14], [42], the receiver can informthe sender about all non-contiguous blocks of data that have been received, thusthe sender knows which segments to retransmit. Without the SACK optionthe sender does not know exactly which packets that have been lost. TCPNewReno [16] is the TCP variant recommended if one of the two communicatingTCP end points in a session does not support the use of SACK.

The NewReno algorithm is active during Fast recovery, i.e., from the re-ceipt of three duplicate acknowledgments to a timeout or until all the data senthas been acknowledged. In short, the NewReno algorithm considers each du-plicate acknowledgment to be an indication of a segment leaving the networkand therefore the sender is allowed to send a new segment on each duplicateacknowledgment. This variation of the TCP congestion recovery behavior ismore likely to keep the ack clock going during loss events than that of TCPReno, thereby avoiding a timeout. The difference compared to SACK-basedloss recovery [4] is that the NewReno sender, does not know where the gaps inthe receive sequence are.

3 Method

The impact of different settings of the TCP retransmit timeout lower bound(minRTO) has been evaluated through simulations. In this section we intro-duce the simulation environment, thereafter the chosen evaluation metrics arepresented.


Mobile nodes25ms/5Gbps

Traffic sources

Figure 2.1: Simplified topology illustrating the connection between the trafficsources and the mobile nodes.

3.1 Simulation Environment

A model of HSDPA has been implemented into ns version 2.27 [44]. The radiomodel includes log normal shadow fading with a standard deviation of 8 dB andexponential path loss with a propagation constant of 3.5. Self interference isassumed to be 10 percent and the interference from simultaneous transmissionswithin a user’s own cell is approximated to 40 percent. Code multiplexing forup to three users in the same slot for a given cell is supported. The interferencefrom transmissions in other cells than a user’s own cell is dampened by distance.The coding and modulation combinations, as well as the introduction of blockerrors are described in [5]. No fast HARQ is implemented; instead, damagedradio-blocks are immediately retransmitted.

When starting a simulation the mobile terminals are randomly distributedaccording to a uniform distribution for the x-axis and the y-axis on a cell planconsisting of seven cells. All cells have omni directional antennas and a radiusof 500 m. The traffic sources are at equal distance from the base stations andthe mobile users are associated with the closest base station. During a transferthe mobile node moves with a speed drawn from a low mobility model [46]. Alldirections are equally likely. Wrap-around is supported both for the movingusers and interference calculations.

A session consists of a user (mobile terminal) downloading a file followed by awaiting time drawn from an exponential distribution with a mean of 1.5 seconds.The waiting time is initiated as soon as the last data byte has reached thereceiver2. The file sizes are drawn from a Pareto distribution with a mean of25000 bytes and the shape parameter set to 1.1. The mobile node is also movedto a new position each time it starts a new transfer. A simplified model of thetopology can be found in Figure 2.1.

We vary the load by setting the total number of users for the simulation.Initial studies suggested that 20-50 users generate what can be regarded as lowload, 50-100 users gave moderate load and above 100 users the load is high.We initially used a range of up to 500 users, but we settled on 150 users asa maximum. Above this point about 50% of the transfers had a goodput of

2We reset the TCP endpoints, thus no tear down is performed, but connection establish-ment takes place for every flow.


39

less than 10 kbit/s, regardless of scheduler and minRTO setting. We consider10 kbit/s to be too low for the web traffic that HS-DSCH was designed for.

3.2 Evaluation metrics

If the RTO is set too low the risk for premature timeouts is high. With timeoutintervals larger than necessary the sender might be idle for periods waiting forthe timer to expire. When studying the effect of different minRTO settings,we count the number of spurious timeouts on a per-flow basis. Although ex-tended idle periods negatively influence the transfer rates of individual flows,they do not result in unnecessary retransmissions. We therefore consider spu-rious timeouts more destructive for system performance and focus on them forthis study.

We expect spurious timeouts to decrease the fairness between users, sinceusers that have been hit by a spurious timeout perform double work. We usethe fairness metric given by equation 2.1, where xi is the goodput experiencedduring a particular flow i to measure fairness. This metric was suggested in [34].

f(x1, x2, · · · , xn) =(∑n

i=1 xi)2

n∑n

i=1 x2i

(2.1)

We also evaluate the effect of changing the lower bound of the retransmissiontimer on system performance. The objective is to maximize system goodput,while maintaining fairness between the users. The system throughput is usefulwhen analyzing the goodput, since it gives an indication of the amount of trafficoffered to the system.

4 Results

In Figures 2.2 and 2.3 we clearly see that a longer minRTO results in a smallershare of the flows suffering from spurious timeouts3. By comparing Figures 2.2and 2.3 we find that the SIR scheduler causes fewer spurious timeouts for ashorter minRTO, however the RR scheduler is better (i.e. fewer spurious time-outs) for a longer minRTO. We see that most delay spikes do not last for morethan 0.5 seconds, because for longer minRTOs the share of flows suffering fromspurious timeouts is virtually zero.

Different values of the minRTO do not result in any significant differencesin goodput fairness, except when using an RR scheduler at high loads. For thiscase a longer minRTO is better than a short one, as shown in Figures 2.4 and 2.5.We believe that this decrease in fairness is the result of the increase in spurioustimeouts. Comparing the two schedulers, we see that the RR scheduler producesslightly higher fairness than the SIR scheduler for moderate load. Regardlessof scheduler and minRTO, the fairness steadily decreases as the load increasesabove 75 users.

3We have also looked at the total number of spurious timeouts for which the results corre-spond with the results depicted.


0

0.05

0.1

0.15

0.2

0.25

0 50 100 150

Sha

re o

f spu

rious

tim

eout

s

Number of users

minRTO=0.0sminRTO=0.1sminRTO=0.2sminRTO=0.3sminRTO=0.4sminRTO=0.5sminRTO=1.0s

Figure 2.2: SIR scheduling: The share of all flows experiencing at least onespurious timeout using TCP Sack and a specified scheduler for different valuesof minRTO. The confidence level is 90%. TCP NewReno gave similar results.

0

0.05

0.1

0.15

0.2

0.25

0 50 100 150

Sha

re o

f spu

rious

tim

eout

s

Number of users


Figure 2.3: The results for RR scheduling corresponding to Figure 2.2.


41

0.5

0.55

0.6

0.65

0.7

0.75

0.8

0 50 100 150

Fai

rnes

s in

goo

dput

Number of users

Fairness in goodput per flow for different values on minRTO


Figure 2.4: The fairness in goodput among different flows using TCP Sack and aspecified scheduler for different values of minRTO. The confidence level is 90%.TCP NewReno gave similar results.

0.5

0.55

0.6

0.65

0.7

0.75

0.8

0 50 100 150

Fai

rnes

s in

goo

dput

Number of users

Fairness in goodput per flow for different values on minRTO




1e+06

2e+06

3e+06

4e+06

5e+06

6e+06

7e+06

0 50 100 150

Thr

ough

put [

bits

/s]

Number of users

Average total throughput for different values on minRTO


Figure 2.6: The total throughput in the system using TCP Sack, averaged overten runs for different values of minRTO. The confidence level is 90%. TCPNewReno gave similar results.

Figures 2.6 and 2.7 present the throughput for the whole system. For SIRscheduling, the different values of the minRTO do not result in any differencesin throughput. We note a small difference in throughput when using an RRscheduler at high loads.

5 Discussion

The results presented raise a key question: Why is RR scheduling more sensi-tive to changes in the minRTO when compared to SIR scheduling? Spurioustimeouts occur when the delay suddenly increases, such that a packet will bedelayed causing the RTO timer to go off. In our system, increased packet delaysare the result of intensified competition at the MAC layer.

With an RR scheduler the competition is intensified for all users whenevera new user arrives to a cell, since they all compete on equal terms. However,given the slow start behavior of TCP, the traffic of one new user is not enoughto create a delay spike. There must be several new users arriving within a shortperiod of time in order for any rapid increase in competition to occur. With SIRscheduling the arriving users only compete with the users having worse SIR thanthemselves. This means that if a number of users arrive at a cell, the likelihoodof all of them contributing to the competition observed by a particular user is


43

1e+06

2e+06

3e+06

4e+06

5e+06

6e+06

7e+06

0 50 100 150

Thr

ough

put [

bits

/s]

Number of users

Average total throughput for different values on minRTO



lower for SIR scheduling, than with RR scheduling.The size of the files which the new users chose to download also affects the

outcome. The files must be big enough to capture a large amount of time slots.In our application file size distribution, small files are common and large filesrare. This makes it less probable that spurious timeouts would occur comparedto a scenario where a majority of the file sizes are large.

The effect of our file size distribution is different for the two schedulers. If ahigh-SIR user arrives to a cell which uses SIR scheduling and begins to transfera small file, other users are not affected, since the new transfer will use few timeslots. On the other hand, if RR scheduling is applied, a new user would probablyconsume more time slots since the RR scheduler does not try to optimize systemthroughput.

To conclude, in order for delay spikes to occur when an RR scheduler isused, it is sufficient that a fairly large number of users arrives at a cell. If aSIR scheduler is used, the number of users arriving must be higher and the sizeof their transfers larger (per user) than with RR scheduling to create the sameeffect.

From the results it is likely that the delay spikes when using the RR schedulerhave a duration of less than 1 second. However, no such conclusion can be drawnwhen we use the SIR scheduler. Either, it could be that delay spikes duringSIR scheduling are longer than 1 second, thus a minRTO of 1 second will notbe able to capture them, or because the SIR scheduler optimizes on systemthroughput and thus is able to process more data faster. If we would increase


the load beyond the current point we speculate that the minRTO might havean effect for SIR scheduling. The average round trip times for the same numberof users, are shorter for SIR scheduling than for RR scheduling, indicating thatthe SIR scheduler is more efficient. This is more evident during high loads.Furthermore, we have compared cumulative distributions of the RTTs for thetwo schedulers. In general the RTT for SIR scheduling is shorter, but there areseveral occurrences of really long RTTs compared to RR scheduling.

We have only studied TCP traffic and even though TCP probably will bethe protocol used by most of the applications, it is of interest to discuss itsperformance when competing with traffic using UDP. A UDP traffic source mayvery well start sending at a high rate compared to the start-up behavior of TCP.This means that a single, or a few high-rate UDP flows can cause sudden serviceinterruptions interpreted as delay spikes by the TCP flows transferring data inthe same cell.

To conclude, we see that there are differences in the number of spurioustimeouts when using the two schedulers for the minimum retransmission boundsstudied and for our application model. These differences does not seem tohave any major effect on fairness, goodput or throughput, nor do the two TCPversions.

Paper 3

Buffer management for TCP overHS-DSCH

45

Technical report, Lulea University of Technology

Sara Landstrom and Lars-Ake Larzon, “Buffer management for TCP over HS-DSCH”.Technical report, LTU–TR–05/09–SE, Lulea University of Technology, Sweden, Febru-ary 2005.

46

Buffer Management for TCP over HS-DSCH



Abstract

In this paper we investigate the influence of buffer management for TCPon performance of the High Speed Downlink Channel (HS-DSCH) intro-duced in WCDMA release 5. HS-DSCH is a shared channel, but userdata is buffered individually prior to the wireless link. Three queue man-agement principles, e.g., passive queuing, the Packet Discard PreventionCounter (PDPC) method and the Random Early Detection (RED) algo-rithm were evaluated for a number of buffer sizes and scenarios. Also, abuffer large enough to prevent packets from being lost was included forreference.

For round robin (RR) scheduling of radio-blocks, PDPC and the pas-sive approach, that both manage to keep the buffer short, gave the bestsystem goodput as well as the shortest average transfer times togetherwith the excessively large buffer. With signal-to-interference ratio (SIR)scheduling, the strategy to avoid all packet losses, resulted in a lowersystem goodput than for the short buffers.

As illustrated in this article, peak transfer rates may not be achievedwith very small buffers, but buffers of 10-15 IP packets seem to representa good trade-off between transfer rates, delay and system goodput. Wewould like to investigate how to make use of system parameters suchas the current amount of data offered for HS-DSCH in total to regulateindividual buffer sizes.

1 Introduction

On the Internet, buffering is usually performed on a per-link basis, except whenit comes to wireless cellular systems, where per-user queuing is common practice.Previous studies of buffer management over wireless cellular systems focus ondedicated channel types [59], [10].

In this paper we study how appropriate buffer management can improveperformance of HS-DSCH, which is a shared channel, when transfers are madeusing TCP as transport protocol. TCP connections in the slow start phase,alternate between sending data and waiting for acknowledgments. Improvedlink utilization may therefore be achieved through time division. With the


increased amount of data services being offered over wireless cellular networks, itis probable that the shared channel concept will become increasingly important.

In low load situations buffer management for HS-DSCH primarily targetsuser experience in terms of transfer rates. When the traffic load increases buffermanagement can help to ensure that the resources are being spent wisely, sinceit interacts with the TCP congestion and avoidance mechanism.

One of the key issues is that we do not want to transfer stale data or multiplecopies of the same data over the link. It is therefore likely that the queueshould be kept small to prevent data from aging in the queue and unnecessarilytriggering timeouts. Meanwhile, we want to minimize the number of packetsthat have to be dropped in order to keep the buffer size small. We also want toenable high transfer rates and ensure that data is available to be transferred.

We will now present the main features of HSDPA and relate them to TCPand current buffer management principles. We also expand on the differentaspects of buffering and previous work before presenting the results from asimulation study of queue management for HS-DSCH.

1.1 Radio resource management

HS-DSCH is primarily shared in the time domain, but also through code divi-sion. It supports theoretical peak data rates in the order of 14 Mbps. Thereare basically three techniques that enable these increased data rates; fast linkadaptation, fast hybrid ARQ and fast scheduling. These techniques all rely ona rapid adaptation of the transmission parameters to the instantaneous channelconditions.

In addition to increased data rates compared to earlier versions of sharedchannels in WCDMA, lower delays can be achieved. Users are scheduled on a2 ms basis, which is the length of the transmission time interval (TTI).

Enabling high link utilization and ensuring low delays are examples of re-quirements that may be counterproductive, therefore one of the purposes of ourevaluation is to determine which factors that must be considered when perform-ing buffering for HS-DSCH and what the trade-offs are. The scheduler is centralto this problem, since it largely determines how resources are distributed andthus the available bit rate from a user perspective.

In our evaluation we use two different types of schedulers. The signal-to-interference ratio (SIR) scheduler chooses the next data receiver based on whohas the most favorable signal conditions. The round robin (RR) scheduler,attempts to distribute the time slots fairly by assigning a slot to each activeuser in turn. The SIR and the RR scheduler represent two extremes from atime fairness perspective, that are often used as reference points as in [35].Most schedulers are hybrids of SIR and RR scheduling, hence any conclusionsdrawn may apply to algorithms that combine their characteristics.

The scheduling algorithm controls access to the channel, while the bottleneckbuffer strategy influences the amount of data for a given user that is availableto the scheduler. TCP regulates its send rate by interpreting congestion signals

Buffer management for TCP over HS-DSCH 49

in the form of lost packets and by the use of a timer1. The buffer strategyinteracts with these mechanisms through its drop pattern and the delay that itinduces. Choosing the appropriate buffer strategy is thus important to ensurehigh channel utilization and acceptable transfer rates.

1.2 Buffer management

The three main considerations in buffer management are; to decide on an ap-propriate buffer size, a suitable algorithm that determines when a packet needsto be dropped and a dropping policy. We will begin by introducing the buffermanagement algorithms.

Passive Queuing

The traditional approach to buffering is to set an absolute limit on the amountof data that can be buffered. Packets are then dropped when the buffer capacityis exhausted. This strategy is known as passive queue management.

Random Early Detection (RED) gateways

RED gateways belong to the class of active queue management principles and iscurrently the recommended strategy for use on the Internet [6]. It is primarilyintended for a scenario where multiple flows traverse the same queue, thereforea probabilistic approach to dropping was taken in order to avoid biases andglobal synchronization.

The original algorithm compares the average queue size against one lowerthreshold, t min, below which no packets are dropped, and a upper threshold,t max, above which all packets are dropped. The drop probability at t max isp max. In between the thresholds, the exact dropping probability depends onthe average queue size, avg, and the number of packets that have arrived sincethe last packet was dropped, count. To separate the packet drops in the timedomain, the packet dropping probability based solely on the average queue size,

pb =max p(avg − t min)

(t max − t min), (3.1)

is adjusted bypa =

pb

1 − count ∗ pb, (3.2)

yielding the final dropping probability pa.In [59] the advantages and disadvantages of basing decisions on the average

queue size were discussed in relation to the outgoing link capacity. The largerthe link bandwidth, the less importance each additional packet has in terms ofdelay in the buffer and a slower reaction to changes in the queue size can betolerated. However, wireless links can have relatively low bandwidths compared

1The network buffers can also set a bit in the IP header to signal congestion, which isreferred to as Explicit Congestion Notification (ECN).


to wired links, which means that each packet can add substantial delay and slowdown loss recovery.

We argue that whether to base decisions on the average queue size or not, alsodepends on the number of flows being handled. In the simple case when thereis only one flow, it is possible to detect when over buffering with knowledge ofthe transport protocol and the current buffer level for a given bandwidth*delayproduct. Essentially a packet should be dropped as soon as the lower thresholdis exceeded to get a prompt send rate reduction in slow start. Thereafter equallyspaced drops are preferable for the probing behavior of TCP.

With RED the likelihood of losing a packet is high close to the upper thresh-old, but rather low close to the lower threshold. Increasing the dropping prob-ability will only marginally increase the likelihood of dropping a packet at theright moment, while also increasing the risk of loosing multiple packets from thesame TCP window. Figure 3.1 illustrates this relation. Dropping more than onepacket from a TCP window complicates loss recovery [14].

0

0.2

0.4

0.6

0.8

1

0 5 10 15 20

Dro

ppin

g pr

obab

ility

Queue size in number of IP packets

=tmin =3*tmin =4*tmin

100% 3*tmin100% 4*tmin10% 3*tmin10% 4*tmin

Figure 3.1: RED dropping probabilities with different maximum drop proba-bilities and relations between the lower and the upper thresholds. The lowerthreshold is here set to 5 IP packets.

A change has later been made to the RED algorithm [15] in order to de-crease the sensitivity to the parameter settings. Instead of dropping all packetswhen the average queue size exceeds t max, the dropping probability is slowlyincreased from max p to 1 between t max and 2 ∗ t max. An evaluation of thismodified algorithm is to be found in [56].


Packet Discard Prevention Counter (PDPC)

In [59], it was shown that the Packet Discard Prevention Counter (PDPC)method outperforms RED gateways [22] and passive queuing schemes for TCPover dedicated 3G channels. PDPC takes advantage of there being only one ora few flows sharing the buffer immediately in front of the 3G link and considersthe congestion control and avoidance mechanisms of TCP. In addition to lowstatistical multiplexing, it was assumed that the wireless hop is limiting thetransfer rate when designing PDPC, which simplifies the configuration of thebuffer parameters.

Assuming that the buffer is dedicated to one user, a deterministic approachthat does not require more knowledge than RED can be used, without riskingbiases against certain connections and global synchronization. PDPC utilizesa counter to inflict packet drops regularly when the instantenous queue size islarger than the lower threshold, t min. In [58] t min is set to the estimatedpipe capacity, the counter, n, which largely determines the spacing betweenpacket drops to 2 ∗ t min and the upper threshold above which all packets aredropped to 4 ∗ t min. Figure 3.2 illustrates the relations between the droppingprobabilities and the threshold values for the discussed buffer principles.

Buffer size in IP packets

t_min t_min t_mint_max t_max0

1Passive PDPC RED

Los

s pr

obab

ility

Figure 3.2: A graphical comparison of the three queuing principles with thedropping probability on the y-axis. The proportions in this figure are not exact.

For HS-DSCH, it is not necessarily the wireless hop that dominates the pipecapacity as was the assumption for the 3G links in the previous studies [59], [10].The actual radio link round trip time is short and the available bit rate can varysubstantially, which means that other guidelines for how to set t min has to beapplied.

Dropping Policies

Data may be dropped from the tail or the front of the queue. A packet mayalso be randomly selected for dropping. Randomly selecting a packet is foremostan interesting approach when the buffer contains packets from several transfersand users. In such a case we want to distribute the packet losses among theflows and primarily drop packets belonging to flows that occupy a large share ofthe buffer, without having to keep track of individual flows. Since each buffer


is dedicated to one user in the case of HS-DSCH we will not consider randomdropping further.

In [63], the drop-from-front scheme was shown to give a shorter averagequeuing delay than drop-from-tail for passive buffering. The decrease in delayis roughly proportional to the fraction of packets dropped, since dropping fromthe front decreases the service time.

Another motivation for the use of drop-from-front is that the fast retransmitmechanism of TCP can be exploited to convey the congestion signal faster tothe sender as proposed in [39], which for instance can help to avoid a large slowstart overshoot. A large buffer overflow in slow start has been shown to be aproblem in low statistical multiplexing environments [25].

Finally, if the passive buffer only keeps data for one transfer the drop-from-front approach ensures that there are always enough segments to trigger a fastretransmit following the dropped segment (assuming that the buffer can holdat least three segments).

Although we have discussed the dropping policies from the perspective ofpassive queue management, most buffer management algorithms can be arbi-trarily combined with a drop policy. In this study we consider passive bufferingwith a drop-from-tail scheme (DT), passive buffering where packets are droppedfrom the front (DF), RED with drop-from-front (RED) and finally PDPC withdrop-from-front (PDPC). Buffer sizes are measured in IP packets. The nota-tion “DT 4”, translates to a passive queue management algorithm with packetsbeing dropped from the tail and room for at most 4 IP packets.

2 Evaluation

We use simulations to illustrate the effects of buffer management over a sharedchannel. The data has been obtained through simulations using the NetworkSimulator version 2.27 (ns-2) [44]. For the simulations the PDPC algorithm wasimplemented according to the state chart in [59] and the model of HS-DSCH,first used in [5], was extended by wrap-around for interference calculations andmoving users. See [3] for an explanation of wrap-around for moving users.The transport protocol is TCP SACK, as implemented in the ns-2 module tcp-sack1. The connection set-up, but not the tear-down was simulated. Based onthe Ethernet MTU of 1500 bytes, the TCP segment size was set to 1460 bytes.

2.1 Individual buffers

Our initial scenario was chosen to illustrate the behavioral differences of RED,PDPC and passive queuing and is similar to the scenario investigated in [58].

Simulation model

The network topology is shown in Figure 3.3. Instead of a 3G link, we use awired link with a corresponding fixed delay and bandwidth. The purpose is to


70ms

Serviceprovider

User64kbps/60ms

Figure 3.3: The network topology for the simulations of the dedicated channel.The bandwidth of the first link is over provisioned.

Parameter Setting Explanationthresh t min Size of the passive buffers.maxtresh 4*t min Distance between t max and t min.drop front true Drop packets from the front.mean pktsize 1500 The size of our TCP segments.q weight 1 Base decision on the instantaneous queue

size.linterm 10 Drop every 10th packet at t max.gentle true Slow increase of loss rate after t max.

This is the default value.limit 8*t min Absolute maximum size of the buffer.

Table 3.1: Configuration of RED parameters.

illustrate the behavior of the queue management principles when the buffer isdedicated to one flow. Knowledge of the general characteristics, such as thevariations in queue length and drop patterns, is to support our evaluation ofthe buffer management strategies for HS-DSCH.

The buffer size is given in IP packets and the maximum queue length forthe passive buffer scheme corresponds to t min in the active queue managementalgorithms. Both RED and PDPC were set to drop packets from the front. Therelation between t min and other parameters in PDPC follows the descriptionin Section 1.2.

RED is the most complex algorithm of those investigated and it includes arandom element. The configuration of the RED parameters are accounted forin Table 3.1. For comparison purposes the distance between the two thresholds,t min and t max, and the maximum dropping probability have the same settingsas in [59]. Each TCP transfer was 250 kbytes.

Results

The trend for tail drop is that the number of packets lost is increasing withthe queue size up to a buffer capacity of about 40 IP packets, see Figure 3.4.The reason is that the slow start overshoot is potentially bigger, the larger thebuffer. At larger buffer sizes the drops occur towards the end of the transfer andthus fewer segments are dropped. However, dropping segments late is costly,since a timeout is often necessary to recover, which is reflected by the noticeably


0

5

10

15

20

25

30

35

40

45

0 5 10 15 20 25 30 35 40 45 50

Num

ber

of p

acke

ts lo

st

Buffersize in number of IP packets

DTRED

DFPDPC

Figure 3.4: Number of packets dropped as a function of the buffer size.

increased transfer times in Figure 3.5(a).RED drops less packets than drop-tail, but the transfers are not always com-

pleted faster. The reason is that the RED queue reacts much later to congestionand even if a fast retransmit is made, there are often too many packets aheadin the queue for the transport layer retransmission to reach the receiver in timeto prevent a timeout. The average queuing delay gives an indication of thesize of the queue that the buffer algorithm operates at. From Figure 3.5(b) weconclude that RED results in a larger average queue than the other investigatedstrategies.

In terms of both packet losses and transfer times PDPC gives the best per-formance, closely shadowed by drop-from-front that suffers from a few morelosses when exiting slow start, than PDPC does.

Discussion

RED is difficult to configure. By reducing the distance between the upper andthe lower thresholds, the average queuing delay can be reduced but instead weincrease the risk of dropping closely-spaced packets. Another alternative wouldbe to disable the algorithm, which allows for a slow decrease of the droppingprobability between t max and 2 ∗ t max. We kept the configuration we had inthis experiment, since our focus is not on optimizing any particular algorithm,but rather on finding general guidelines that will apply for HSDPA.

We repeated the experiments with a faster outgoing link and different delays.When the bandwidth is higher and the delays shorter, loss recovery is faster andthus has less effect on the transfer times as can be expected.


32

34

36

38

40

42

44

46

48

50

52

54

0 5 10 15 20 25 30 35 40 45 50

Tra

nsfe

r tim

e [s

]


DTPDPC

REDDF

(a) Transfer times as a function of the buffer size.

0

1

2

3

4

5

6

7

8

0 5 10 15 20 25 30 35 40 45 50

Ave

rage

que

uing

tim

e [s

]


REDDT

PDPCDF

(b) The average queuing delay due to queuing as a function of the buffer size.

Figure 3.5: Buffers dedicated to one user.


2.2 HSDPA goodput

For a dedicated channel, what primarily determines the performance from asystem perspective is how long the user keeps the channel. The activity de-gree has an influence on other users, since power is a shared resource and eachtransmission also generates interference.

When the channel is shared in time, users compete for time slots. Theamount of double work that is brought about through queue management thusinfluence system goodput when resources are scarce. We define useful data as thedata that must reach the receiver for the transfer to be completed. Replicatedapplication layer data may reach the receiver as a consequence of transport layerretransmissions.

We evaluate the system performance by studying the system goodput persecond and cell. System goodput is the amount of unique application layer datathat the system has transferred.

Simulation model

The application model determines the results to a large extent. For instance, ifmost files are small enough to fit into the buffer, the dropping strategy nevercomes into play. In this section the effects of two different file size distributionsare studied. In the first scenario 250 kbytes TCP transfers are being made, inthe second simulation file sizes are drawn from a long-tail distribution wherethe majority of the transfers are short.

A fixed number of mobile users are spread out over the simulation area. Newsessions are generated independently of the perceived transfer rates, through asession generator for which the average waiting time between sessions can beconfigured. The waiting time is uniformly distributed. The destination is pickedrandomly among the idle users. If there is no idle user, the session is dropped.

The session generator enables comparisons to be made at a reasonably sim-ilar offered load as opposed to an application model where each user generatesits next session after a waiting time that is initiated when the previous transferhas been concluded. In the latter case, a higher average transfer rate results inmore transfers being generated. Even with the session generator a system withlow transfer rates has less ability to accept the offered sessions, since all the mo-bile users may be occupied. System goodput captures the results of the transferrates and the degree to which the system performs useful work. Each simula-tion corresponds to 5 minutes simulated time and each scenario was repeatedten times.

The cell plan consists of seven cells with omni directional antennas and 500 mcell radius. Initially the mobile units are spread uniformly in the plane withina circle enclosing the cell plane. For simplicity a mobile is associated with thebase station to whom it is closest to in distance. A hand-over only results inone missed transmission opportunity.

The performance is sensitive to radio conditions and positions of the mobileusers. Therefore a mobile unit is given a position, speed and direction for each


0

5

10

15

20

25

30

35

40

0 10 20 30 40 50 60 70 80 90 100

Num

ber

of u

sers

Speed in kph

Figure 3.6: The low speed and mobility model.

new session assigned to it. The speed is taken from a pedestrian and low mobilityspeed distribution as shown in Figure 3.6 and recommended in [46], whereasany direction is equally likely and positions are chosen as when initializing thesimulation.

The deterministic loss in signal strength due to distance is assumed to beexponential with a propagation constant of 3.5. The location dependent pathloss, referred to as shadow fading, is normally distributed in dB with a standarddeviation of 8 dB and there is a 0.5 correlation between base stations. Theautocorrelation profile for the shadow process is first order negative exponentialand we use a correlation distance of 40 m.

Multi-path fading leads to self interference and loss of orthogonality whendata for several users are transmitted simultaneously within a cell using codemultiplexing. These phenomena are modeled by constants, which have thevalues 0.1 and 0.4 respectively2. All transmissions in other cells contribute tothe interference level.

In Table 3.2, the combinations of coding rates and modulation types that areavailable in the simulator are summarized. We assume that 12 out of 16 codesand a power of 10W have been allocated to HS-DSCH. Code multiplexing ispossible for up to three users in one time slot and the block errors are uniformlydistributed. Lost radio blocks are immediately retransmitted.

2A value of 1 would mean that all orthogonality is lost.


Coding Modulation SIR Bit rate Radio block(rate) (type) (dB) (Mbps) (bytes)0.25 QPSK -3.5 1.44 3600.50 QPSK 0 2.88 7200.38 16QAM 3.5 4.32 10800.63 16QAM 7.5 7.20 1800

Table 3.2: Combinations of coding rates and modulation types

Service providerUsers

25 ms

Bottleneckbuffer

Data

Figure 3.7: The network topology for the simulations of HS-DSCH.

Since TCP has a bias against long round trip time connections, the serverwas placed at the same distance from all base stations. This prevents the TCPbias from affecting the results. The one-way propagation delay between the airinterface and the server was fixed to 25 ms in both directions. The topology isdepicted in Figure 3.7.

In reality active queue management will be performed at the serving radionetwork controller (SRNC) for HSDPA. We assume that the SRNC and thebasestation can transfer data seamlessly between each other and that only asmall amount of data is between the air interface and the queue that is beingactively managed at any point in time.

Statistical methods

Details of the statistical methods used in this paper can be found in [45] andthe software used for the statistical computations is R [60]. Below we brieflyaccount for the applied methods and their underlying assumptions.

For comparison of means when we have two or three samples we chose thepaired t-test with the significance coefficient adjusted for multiple comparisonsusing the method suggested by Bonferroni. The t-test assumes that the differ-ence between the data sets is normally distributed. There is a t-test for datasets with equal variance and another for unequal variance. If the data sets arenormally distributed Bartlett’s test can be used to determine whether the vari-ance are equal or not. The assumption of normality is verified through a normalprobability plot.

The null hypothesis for the paired t-test is that there are no differences inmeans and the alternative hypothesis is that there are differences in means. We


can reject the null hypothesis if the computed p-value is less than our predeter-mined significance coefficient, which we have set to 0.05.

For multiple comparisons of means (more than three means to compare inthis study), we have used analysis of variance (ANOVA). ANOVA allows us toextend our hypothesis to include more than two treatments on one populationor alternatively to ask are all the means from more than two populations equal?This is equivalent to asking whether the treatments have any overall effect. Theassumptions are that the residuals resulting from the model have equal varianceand that they are normally distributed. Thereafter Tukey’s3 test have beenperformed to detect significant differences between means and to construct 95%confidence intervals for these differences.

HS-DSCH for long transfers

In this scenario there are 60 mobile users and new sessions are generated withan average waiting time, which is varied between 0.2 and 0.4 seconds.

RR scheduling We start with the longest waiting time, 0.4 seconds, betweeninitiating new transfers and compare the system goodput for two buffer sizeswith DT. The paired t-test was performed to detect any significant difference inmean system goodput. Our reference buffer, which can keep the entire transfer,gives between 1635 and 9809 bits better system goodput per second and cellthan DT 30 with 95% confidence. The system goodput for the buffer of 4 IPpackets was not significantly different from that of the reference buffer at thisconfidence level.

For a waiting time of 0.3 seconds, we study DT, DF, PDPC and RED with4 and 30 IP packets as the maximum sizes of the passive buffers. We use a twofactor ANOVA to analyze the data. Both the queue strategy and the queue sizeeffect are significant, as well as their interaction. Therefore we have to studythe effect of the queue strategy at each queue size and vice versa. Table 3.3accounts for the 95% confidence intervals for the significant differences betweenmeans. The table reveals that all schemes are significantly better than RED4. The other short buffer configurations and the long RED queue give highersystem goodput than DT 30. DF 4, PDPC 4 and RED 30 give slightly highergoodput than PDPC 30. Tukey’s method was used to perform the multiplecomparisons. We also compared DF 4 to the reference buffer using a pairedt-test. The null hypothesis that the means are equal could not be rejected atthe 95% confidence level.

When decreasing the waiting time further, we find that it is the same dif-ferences in means that are significant and that these differences have increasedin size. There is also a small but significant difference in means between DF 30and DT 4.

3We could have analyzed the experiments using ANOVA and blocking, but the R imple-mentation does not support Tukey’s for blocked experiments. In practice this means that itis harder to detect small differences.


Strategy 1 Strategy 2 Lower limit Upper limitDF 4 RED 4 77105 101669DT 4 RED 4 70924 95487PDPC 4 RED 4 79134 103878DF 30 RED 4 82739 107303DT 30 RED 4 56849 81413PDPC 30 RED 4 71673 96237RED 30 RED 4 71637 96237DF 4 DT 30 7973 32537DT 4 DT 30 1793 26356PDPC 4 DT 30 10183 34747RED 30 DT 30 2542 27106DF 4 PDPC 30 5675 30238PDPC 4 PDPC 30 7885 32448RED 30 PDPC 30 243 24807

Table 3.3: 95% confidence intervals for the significant differences in means withRR scheduling for 0.3 seconds waiting time. The unit is bits per second andcell.

SIR scheduling As with RR scheduling at the lowest investigated load, westudy DT for different buffer sizes. The results are similar, that is the refer-ence buffer has a significantly higher system goodput than DT 30. The 95%confidence interval for the difference in means is [849, 4317] bits per second andcell.

With 0.3 seconds waiting time between new sessions, we get the significantdifferences shown in Table 3.4. DF 4 gives higher system goodput than all theother schemes but DT 4. DT 4 performs better than RED 4 and all the largebuffers. Of the large buffers DT 30 results in lower system goodput than theother strategies.

Since DF 4 performs better than the other configurations, we compare itagainst the reference buffer using a paired t-test. The small buffer improvessystem goodput by 31173 to 41178 bits per second and cell compared to thereference buffer with 95% confidence.

At the highest investigated load, the characteristics of the scheduler domi-nates and therefore no differences in means can be detected.

HS-DSCH for a long-tail distribution

Web browsing is an important service for the mobile Internet, since it stands fora large part of the transfers on the Internet today. The majority of the generatedflows are short, but the distribution of the transfers exhibits a long-tail [7].Web traffic has TCP as the underlying transport protocol and short transfersoften stay in the slow start phase of TCP throughout their existence. In thisphase sources alternate between sending data and waiting for acknowledgments.


Strategy 1 Strategy 2 Lower limit Upper limitDF 4 PDPC 4 1493 23823DF 4 RED 4 6364 28694DF 4 DF 30 9381 31711DF 4 DT 30 37631 59961DF 4 PDPC 30 10054 32384DF 4 RED 30 17410 39740DT 4 RED 4 3369 25700DT 4 DF 30 6386 28716DT 4 DT 30 34636 56966DT 4 PDPC 30 7059 29390DT 4 RED 30 14415 36745PDPC 4 DT 30 24972 47303PDPC 4 RED 30 4751 27082DF 30 DT 30 17084 39415PDPC 30 DT 30 16411 38741RED 30 DT 30 9055 31386

Table 3.4: 95% confidence intervals for the significant differences in means withSIR scheduling for 0.3 seconds waiting time. The unit is bits per second andcell.

Hence, statistical multiplexing over a shared channel is suitable to increaselink utilization. For optimal performance the shared resources of HSDPA musthowever be appropriately distributed among the users.

Simulation model We use the Pareto distribution with the average set to 25kbytes and the shape parameter to 1.1 as recommended in [46] for Web traffic.Values larger than 2 Mbytes are rounded down to 2 Mbytes. The number ofmobile units in this scenario is 200 and the performance was studied at twooffered loads; one where the average waiting time between new sessions was0.0175 seconds and one with 0.015 seconds. The results were similar in bothcases.

Results The differences in mean system goodput observed between the buffersizes in the previous scenario have been reduced and are no longer statisticallysignificant, which is to be expected since most files no longer overflow the largerbuffers. Neither the buffer strategy, nor the interaction term have any significanteffect.

Discussion

We will first discuss the results for the long TCP transfers, which are stronglyconnected to the actual buffer size that the buffer management principle oper-ates at. For RR scheduling it is the small buffers, DF 4, DT 4 and PDPC 4, that


give the best performance in terms of system goodput. RED, that often dropsthe first packet when the queue is larger than for the other schemes, results in alower system goodput for the short buffer size. With the large buffer size REDgives marginally higher system goodput than PDPC 30 that has an averagequeue length which is larger than that of the passive schemes, but smaller thanthat of RED 30.

With SIR scheduling DF 4, DT 4 and PDPC 4 distinguish themselves fromthe other configurations. It is likely that a shorter buffer contribute to a higherdegree of statistical multiplexing over the radio link and thus evens out unfair-ness problems. The total amount of data buffered for HS-DSCH is also decreasedresulting in a more dynamic system.

A drop-from-front policy is preferable to drop-from-tail for passive bufferingwhen the buffer is relatively large. For short buffers, the dropping policy hasno significant influence.

The mean system goodput for the long-tail distribution is higher than withthe large transfers for two reasons; fewer flows perform retransmissions and themajority of the flows are short. Short flows only demand capacity for shorterperiods of time and thus have less impact on other simultaneous sessions. Shortflows also increase the degree of statistical multiplexing over the bottleneck link.

2.3 HSDPA transfer rates

So far we have concentrated on system goodput under high load. In this sectionwe investigate the peak transfer rates achieved by TCP, when there is only oneuser in the center cell for various buffer configurations.

Simulation model

Three cases are studied:

• The exact same topology as before for HSDPA, see Figure 3.7.

• A one-way delay of 75 ms, instead of 25 ms.

• The same topology with 25 ms one-way delay, but randomly uniformlydistributed losses of 1% are added over the fixed link. That is, there aremore than one bottleneck link.

Results

In Figure 3.8, 3.9(a) and 3.9(b) the results are shown. The median transfertime out of 30 simulations have been plotted, since the data is not normallydistributed. Simulations have been carried out for buffer sizes of 5, 10, 15, 20,30, 50 and 100 IP packets.

In the first scenario, the median transfer times are in the range from 0.6 to2.0. PDPC gives the best performance over the entire range of buffer sizes. DTand DF perform well up to a buffer size of 15-20 IP packets. At this point the


20 40 60 80 100

0.6

0.8

1.0

1.2

1.4

1.6

1.8

2.0


Med

ian

tran

sfer

tim

e

DTPDPCREDDF

Figure 3.8: The topology in Figure 3.7 with only one TCP user.

RED buffer no longer induces any packet losses and approaches the minimumtransfer time for this scenario.

In the second scenario, Figure 3.9(a), the minimum transfer time is around1.3 seconds and the highest median transfer times are more than 3 seconds.RED results in the lowest median transfer times for all buffer sizes. The otherbuffers perform worse at small buffer sizes, than PDPC, followed by DF andDT reaches the lowest boundary.

With a low degree of losses over the wired hop, Figure 3.9(b), PDPC has thelowest transfer times of about 0.6 seconds. The highest median transfer timesare two times larger. DF and DT have relatively low median transfer timesfor buffers of 10-15 IP packets. For larger buffers their performance degrade,whereas the performance of the RED queue improves.

Discussion

Compared to the previous scenario with the individual buffers in Section 2.1, wehave a higher and varying bandwidth. A buffer size of 10-15 IP packets seemsto give a stable performance for PDPC, DF and DT in all the investigatedscenarios. It is likely that this buffer size represent a good trade-off betweenenabling high transfer rates and keeping the delay down. With shorter buffersizes, the TCP window is kept too small to allow high peak transfer rates. Onthe other hand, when the buffer is larger, variations in the channel capacity


20 40 60 80 100

1.5

2.0

2.5

3.0


Med

ian

tran

sfer

tim

e

DTPDPCREDDF

(a) A one-way delay of 75 ms, instead of 25 ms.

20 40 60 80 100

0.9

1.0

1.1

1.2

1.3


Med

ian

tran

sfer

tim

e

DTPDPCREDDF

(b) The same topology with 25 ms one-way delay, but randomly uniformlydistributed losses of 1% are added over the fixed link.

Figure 3.9: Median transfer rates for varying buffer sizes and environments.


cause many packets to be lost until the buffer becomes large enough to preventthem.

The extra degree of freedom when deciding whether to drop packets or notstrengthen the position of PDPC over channels with varying capacity. DF andPDPC had similar performance in the scenario with individual buffers for afixed link capacity, see Section 2.1, whereas PDPC exhibits better performancethan DF over HS-DSCH.

3 Discussion

We have studied a scenario where only one transfer at the time takes place foreach user, but the user can initiate several transfers at the same time. Forinstance if HTTP is used without pipelining and the browser is configured toallow more than one parallel connection. Such combined streams are moreaggressive than a single TCP session, which means that the queue sizes wouldprobably grow for RED and PDPC, possibly giving a more problematic errorrecovery even for the smallest buffer configurations. The cost of keeping thequeue at a minimum for multiple simultaneous transfers through passive queuingmay be larger than in the case of only one transfer at the time, since it maycome at the price of many packets being dropped. The full impact of severaltransfers sharing a buffer on the system is however part of our future plans.

RED was designed for a scenario where multiple flows traverse the bottleneckbuffer, which is a scenario that remains to be studied for HS-DSCH. For one flowat the time, RED performs poorly. The reason is the late reaction to increasesin the queue length, which often results in timeouts in combination with loosingmany packets. Together with a passive drop-tail queue management, RED isnot to be recommended. Instead we argue for the use of passive drop-from-frontmanagement and PDPC, which have been shown to be suitable for short buffers.It is likely that to improve buffer management further, system parameters suchas radio conditions, link utilization and the current amount of data that isbuffered for the system as a whole should be taken into account. In low loadsituations larger buffer sizes may allow higher transfer rates and high utilization,but when the load increases the buffer sizes may have to be reduced to keepbuffering delays down and to allow smooth TCP operation.

4 Conclusions

HS-DSCH is a relatively new technique and it is hard to foresee what character-istics the traffic mix for this channel will have. A queue management principlethat exhibits robustness to application parameters and handles TCP well istherefore likely to be the best choice. There is a trade-off between low queuingdelays, system goodput and peak transfer rates which has been illustrated inthis paper. In general, drop-from-front is a better choice than drop-from-tailfor passive queue management.


All the investigated buffer management principles operate at different aver-age queue lengths, which is determining for performance at high loads. A shortbuffer increases the order of statistical multiplexing and reduces the amount ofdata being buffered in the system as a whole resulting in the highest systemgoodput. The use of short buffers is further motivated by the decreased waitingtime in the buffer and a reduced risk for data aging while waiting in line. In lowload scenarios being able to avoid burst packet losses due to variations in theforwarding capacity enables high transfer rates. There seems to exist a pointwhere high transfer rates can be achieved with a relatively small buffer.

Paper 4

Properties of TCP-like congestioncontrol

67

Paper published as

Sara Landstrom, Lars-Ake Larzon and Ulf Bodin, “Properties of TCP-like congestioncontrol”. In Proceedings of the Swedish National Computer Networking Workshop,pages 13-18, Karlstad, Sweden, 23-24 November 2004.

68

Properties of TCP-like Congestion Control



Abstract

In this paper we investigate the performance of TCP-like congestion con-trol and compare it to TCP SACK. TCP-like congestion control is cur-rently up for standardization as part of the Datagram Congestion ControlProtocol (DCCP) in the IETF. DCCP offers an unreliable transport ser-vice with congestion control to upper layers.

We have found that TCP-like is fair to TCP SACK when the lossrate is low. In the high loss, low round trip time regime, TCP-like seizesmore bandwidth and is able to better maintain a smooth send rate thanTCP SACK. In low round trip time environments, the absence of a lowerbound on the transmit timeout in TCP-like, which corresponds to the re-transmission timeout in TCP, contribute to this difference in performance.Another factor is the decoupling of the congestion control state from in-dividual packets that is possible in TCP-like, since it offers an unreliabletransport service.

1 Introduction

Traditionally TCP has been the dominating Internet transport protocol, buttime constrained media services are becoming more frequent and promote theuse of UDP. Most UDP flows lack congestion control mechanisms and existon the expense of the TCP flows. The increased share of UDP flows mighteventually cause severe starvation of TCP flows or even a congestion collapse,therefore TCP-friendly rate regulation of all longer transfers is desirable from afairness perspective.

To support this ambition a new transport protocol, called the DatagramCongestion Control Protocol (DCCP) [37], has been designed. It currently of-fers the choice of two congestion control algorithms, TCP Friendly Rate Control(TFRC) [20] and TCP-like congestion control [23]. The former has been stud-ied in [20] and [62], but the latter has to our knowledge not been extensivelyevaluated.

TFRC is targeted at applications desiring a smoother send rate than cur-rently possible using TCP, whereas TCP-like congestion control is designedto closely trace the behavior of TCP SACK [14] thus prioritizing throughput.

69


There are however differences that springs out of TCP-like providing an unreli-able service while TCP enforces reliability. For instance, the delay variations areexpected to be smaller since retransmissions are not performed at the transportlayer and in order delivery has been abandoned. The removal of these featuresgives the application designer a finer grained control over which data is to besent and when, than in ordinary TCP. Thereby TCP-like may become an at-tractive option for applications like streaming media, where the time constraintsmay allow selective retransmissions.

In this paper we concentrate on mapping out the differences in the design ofTCP-like congestion control and TCP SACK. We also show, through simulationsin the Network Simulator, ns-2 [44], the impact they have on the send rate,smoothness and fairness of the protocols. TCP is used as a reference point,since TCP-like expressly attempts to imitate its behavior and also because it isone of the most prevalent protocols.

2 TCP SACK and TCP-like congestion control

In this section we will discuss general characteristics of TCP-like and TCPSACK congestion control, such as the conditions that must be fulfilled to beallowed to transmit data, when acknowledgments are sent and which informationthey include. We also compare the criteria that are used to increase the sendrate.

Thereafter we will illustrate through examples, how loss recovery and de-tection have been implemented in the two protocols and the implications ofthe behavioral differences on performance. We will also point out areas wherefurther refinements of the TCP-like algorithm are possible.

DCCP is a packet oriented protocol, whereas TCP is byte oriented. In thisstudy we will use the unit packets also when referring to TCP segments, and itis assumed that the send rate is limited by congestion rather than the resourcesof the receiver.

2.1 General algorithm characteristics

The send rate in both TCP-like and TCP SACK when competing for bandwidthis limited by the size of the congestion window, cwnd. This window representsthe number of packets which is allowed in the network for TCP-like. In TCPSACK, the window also confines a sequence of packets – only packets withsequence numbers lower than the sum of the highest acknowledged sequencenumber and cwnd can normally be sent. When the oldest outstanding packethas been acknowledged, the window can be moved past this packet. In TCP-like, the variable pipe represents an estimate of the number of packets in thenetwork and new packets may be sent as long as pipe is less than cwnd. Duringloss recovery TCP SACK deploys an algorithm similar to that of TCP-like andthe sender therefore also maintains a pipe variable in this state.

Properties of TCP-like congestion control 71

TCP uses a cumulative acknowledgment scheme, i.e., the highest in-ordersequence number received is acknowledged. With the SACK option, informationabout gaps in the sequence of received packets can be acquired. Acknowledg-ments of data carrying packets in TCP-like are normally sent for every secondpacket. The acknowledgments account for the state of all packets up-to-date,for which the acknowledgment information has not in turn been acknowledged.Acknowledgment information is reliably transferred in DCCP, thus the senderacknowledges the acknowledgments sent by the receiver. The detailed packethistory is carried in the ack vector option.

Both TCP variants have two phases, called slow start and congestion avoid-ance. During congestion avoidance TCP-like updates its send rate in the samemanner as TCP SACK, but in slow start there are differences. When the TCP-like sender is in slow start, cwnd is increased by one packet for each packetnewly reported as received. This is similar to TCP SACK with appropriatebyte counting or when the receiver acknowledges every packet. These schemesare more aggressive than a TCP connection with the delayed acknowledgmentalgorithm enabled that updates cwnd by one for each feedback packet received.Throughout this paper we configure TCP SACK to send feedback for every datapacket.

2.2 Loss detection and recovery

When TCP SACK detects a congestion event through the arrival of four con-secutive acknowledgments of the same sequence number, the indicated packet isassumed lost and retransmitted. If the SACK options report multiple lost pack-ets and pipe is less than cwnd, additional packets may also be retransmitted.Pipe is decreased for each new packet that the SACK option states have beenreceived. In the corresponding situation TCP-like also reduces pipe by one foreach packet with unknown state, for which three later sent packets have beenacknowledged. Thereby pipe is usually less in TCP-like when multiple packetsare lost from a window of data, leaving room for more packets to be sent. Inthe example below, when the acknowledgment for packet 14 reaches the senderit will give pipetcplike = pipesack − 2.

Packet 9 10 11 12 13 14

Status Not recv Not recv Recv Recv Not recv Recv

TCP SACK has a retransmission timeout, which allows the connection torecover when the loss event is severe. A similar transmit timeout exists inTCP-like, except there is no lower bound on how short it may be. Previouslyone of the reasons for the lower bound was the poor clock granularity, whichis no longer of immediate concern for modern operating systems. A secondmotivation for having a minimum retransmission timeout is foremost to avoid


injecting replicas of packets into the network when the original transmissionhas merely been delayed. In TCP-like, new packets are sent when the timeoutexpires, therefore this argument is not compelling.

The standard behavior of TCP is to restart the retransmission timer whenthe cumulative acknowledgment point is advanced. This tight coupling of thecongestion control state to individual packets increases the likelihood for time-outs. For instance, if a fast retransmit of packet p is triggered, the retransmittedpacket will be the last packet to reach the receiver if there are other packetsalready on the way. Whereas in TCP-like, p would have been assumed lost whenthe DCCP event corresponding to three duplicate acknowledgments arriving inTCP occurred. The arrival of either any of the packets already on their way orthe newly sent packet (sent instead of the retransmission) would then restartthe timer.

When a timeout occurs TCP-like resets pipe. Packets still in the networkat this point will not further reduce pipe, but could serve a purpose during thefollowing slow start period. In [13] the performance of different methods forupdating cwnd during slow start was investigated for TCP. Increasing cwnd bythe number of newly acknowledged packets, when slow start has been entereddue to a loss event, was deemed too aggressive. The reason being that after a lossevent the sender can not be certain that acknowledged packets actually left thenetwork during the last round trip time, since the reports are cumulative theymay have left the network long ago1. In TCP-like, there is enough informationto deduce when a packet left the network and we therefore suggest to alwaysincrease cwnd based on the number of packets acknowledged. This option ishowever left for future studies.

To summarize, TCP-like can discount packets when they have been con-firmed lost resulting in a quick exit from loss recovery. Also, the acknowledg-ment of essentially any new packet restarts the transmit timer and releases anew packet, which keeps the ack clock going through difficult congestion eventsand decreases the likelihood of a timeout occurring. Finally, there is no lowerbound on the transmit timeout which means that less time is spent waiting forthe timer to expire in environments where the round trip time is short, if atimeout is necessary to recover.

3 Simulations

Our evaluation is based on simulations carried out in the Network Simulatorversion 2.27 (ns-2). The TCP SACK agent (TCPSack1) is part of the simulatorand includes most TCP algorithms such as fast recovery, fast retransmit, slowstart, congestion avoidance and limited transmit. We have been involved in theimplementation of DCCP and will use our DCCP implementation [43] whichimplements all protocol features relevant for this study. In all simulations theinitial window was set to 2 packets and the buffers at both end points were set

1Through the SACK option it can be derived when a packet left the network, but this iscurrently not exploited.


04000080000

1200000

4000080000

1200000

4000080000

120000

0 5 10 15 20

Rec

eive

rat

e (b

ytes

/s)

Loss rate (%)

RTT 20 ms

RTT 100 ms

RTT 200 ms

TCPLSACK

Figure 4.1: The receive rates of TCP SACK and TCP-like congestion control.

large enough not to limit the send rate. The simulation scenarios are similar tothose presented in [20] when TFRC was introduced, which makes a comparisonof TCP-like and TFRC possible.

3.1 Environmental impact

We have identified a number of differences between ordinary TCP and TCP-likecongestion control, that can have an effect on the throughput of a connection.The decreased sensitivity to multiple packets being lost from the same windowand not having a minimum transmit timeout, are factors that are likely tobe more relevant in certain environments. We therefore compared the receiverates of TCP SACK and TCP-like congestion control for various loss rates andround trip times. The results are presented in Fig. 4.1. Losses were distributedaccording to a uniform distribution. The simulations have been repeated fortytimes for each set up and the confidence intervals are for 95%. The confidenceintervals are narrow, therefore they appear to coincide with the marks on thelines. At higher loss rates, and especially when the round trip time is short,TCP-like has a higher receive rate.

When loss events are frequent, timeouts may be necessary for the transfers torecover. The removal of the minimum retransmission timeout, which is currently1 second in TCP SACK, is likely to be to an advantage for TCP-like when the


RTT Lossrate

MinRTO Reliability Transferrate

R2

P-value Effect P-value Effect

20 ms 1% 1 0 ± 15 0.75 2 ± 15 122069 ± 8 33%

200 ms 1% 1 0 ± 2987 0.69−598 ±3012

86765± 1506 45%

20 ms 5% 0.02 −611 ± 521 0.76 80 ± 526 118671± 263 37%

200 ms 5% 0.84 −64 ± 651 0.56191 ±657

35293 ± 328 61%

20 ms 10% 0.00−18937 ±

24230.26

1393 ±2443

95322± 1221 78%

200 ms 10% 0.00 −932 ± 346 0.04372 ±348

21580 ± 174 60%

Table 4.1: The impact of a 1 second minimum retransmission timeout andapplication layer retransmissions on the receive rates of TCP-like.

round trip time of a connection is low and stable. However, it makes the protocolmore sensitive to delay spikes. The Eifel Detection and Response algorithmscould be implemented for TCP-like to mitigate this potential drawback.

The effect of enforcing a minimum transmission timeout of 1 second onthe receive rate of TCP-like can be easily investigated. It is also possible toimitate application layer retransmissions by adding another packet to be sentfor each packet detected as lost by the sender. Table 4.1 gives the results ofan experiment designed as a full factorial test [45] where these two features areturned on and off in a few environments characterized by their round trip timeand loss rate. Each setting was simulated thirty times2.

A p-value less than 0.05 indicates that a factor is significant at the 95% confi-dence level. The effect of the interaction between the factors was not significantand is therefore excluded from the table. A minimum transmission timeout of1 second has a negative impact on performance when the loss rate is high andthe effect becomes significant for lower loss rates when the round trip time islow. At 95% confidence level, reliability results in insignificant changes in all theinvestigated scenarios, except when both the round trip time and the loss rateare high. The Effect column gives information about the confidence interval forthe effect.

The R-Squared statistic captures how much of the variability that can beexplained by the fitted model. The best fit is given when the RTT is 20 ms and

2The average effect found in the table is computed over all simulations for that particularenvironmental setting, these values are therefore not directly comparable to the receive ratesshown in Fig. 4.1.


0

4

8

12

16

0 2 4 6 8 10

Siz

e (p

acke

ts)

Time (seconds)

TCPLSACK

Figure 4.2: A comparison of the cwnd sizes under the same conditions.

the loss rate 10%. Part of the discrepancy between the receive rate observed byTCP-like and TCP SACK is still unaccounted for. It is reasonable to assumethat the remaining difference can be attributed to the decoupling of the conges-tion control state from individual packets as illustrated in the previous section.This assumption is strengthen through the trace of the congestion windows whenthe loss rate is 5% and the delay is 10 ms shown in Fig. 4.2. Timeouts are lessfrequent in the case of TCP-like (the congestion window is never down to onepacket) and there are fewer long loss recovery periods identified by cwnd beingfrozen.

3.2 Send rate, fairness and smoothness

In the previous section TCP-like congestion control has been shown to give ahigher receive rate than TCP SACK when traversing separate links induced withrandom loss. We have also investigated the scenario depicted in Fig. 4.3 wherethe two protocols co-exist over a link with varying capacity for both RED anddrop-tail queuing. Half the flows are TCP SACK and the other half consistsof TCP-like flows. Each dot in Fig. 4.4 is the normalized mean send rate ofthe last 60 seconds of a 75 seconds long simulation for an individual flow. Theinitial 15 seconds are removed, since we are interested in the performance oncethe system has stabilized. This figure is representative of our findings, i.e., whenthe loss rate is low TCP-like congestion control has a slightly higher normalizedmean throughput. This gap increases with an increasing number of competitorsand a diminished link capacity.

Fig. 4.5 shows how the coefficient of variation (CoV) between flows of thesame type in one simulation changes as the bandwidth is varied for 16 TCPSACK and 16 TCP-like sessions. Each setting has been repeated ten timesand the mean send rate was computed over the second half of the 30 simulatedseconds. TCP-like congestion control manages to maintain a low coefficient of


Figure 4.3: The topology used in the simulations. The queue parameters werescaled with the bandwidth that in some scenarios was up to 256 Mbytes/s.

02468

101214

0 16 32 48 64 80 96 112 128

Loss

Rat

e (%

)

Number of TCP SACK and TCP-like Flows in total

0

0.5

1

1.5

2

2.5

0 16 32 48 64 80 96 112 128

Nor

mal

ized

se

nd

ra

te

Number of TCP SACK and TCP-like Flows in total

SACK FlowsTCPL FlowsMean SACKMean TCPL

Figure 4.4: TCP-like and TCP SACK when sharing a 16Mbytes/s link withRED queuing.


0.10.20.30.40.50.60.70.80.9

1

2 3 4 5 10 20

Coe

ffici

ent o

f Var

iatio

n

Loss Rate (%)

SACK CoVTCPL CoV

Mean SACK CoVMean TCPL CoV

Figure 4.5: Coefficient of variation of the send rate between flows of the sametype.

variation although the loss rate is high, whereas the spread of the throughputbetween the TCP SACK sessions rapidly increases. When the loss rates are low,TCP-like and TCP SACK exhibit similar fairness between the flows.

Fairness can also be measured over different time scales. For this purpose,we ran 150 seconds long simulations. These simulations were partitioned intotime intervals of length δ and the send rate in every time interval computed.The equivalence ratio in a time interval for user A and B is then the minimumof the two ratios, sendrateuser A

sendrateuser Band sendrateuser B

sendrateuser A. By taking the minimum of

the two ratios, a value between 0 and 1 is received. For perfect fairness thisequivalence ratio should be 1. The average value of the equivalence ratios for atime series gives an estimate of how the bandwidth has been distributed on thetime scale δ [20]. The shorter the time scale, the more likely it is that we willobserve a smaller equivalence ratio.

We have computed the equivalence ratio for two scenarios corresponding tothe situations when 32 and 128 flows respectively were active in Fig. 4.4. Themain difference is that the starting times of the flows are chosen from a uniformrandom distribution in the interval between 0-40s. Previously all flows werestarted within a time span of less than 10ms. We also removed the first 50seconds before performing our analysis. The reduction in fairness compared tothe results in Fig. 4.4 indicates that new TCP SACK flows have a harder timegrabbing bandwidth from already active sources. Also, the equivalence ratiodoes not consider which flow that got more bandwidth during an interval. Forinstance, if TCP-like sends at a rate that is twice that of TCP SACK in thefirst interval and TCP SACK sends at twice the rate of TCP-like in the nextinterval, the equivalence ratio will be (0.5 + 0.5)/2 = 0.5, not (0.5 + 1.5)/2 = 1.


The inter-flow fairness between TCP-like flows seems independent of changesin the loss rate resulting from increasing the number of active flows, but boththe inter-flow fairness for TCP SACK flows and between flows of different typesdecreases as visualized in Fig. 4.6.

The coefficient of variation of the send rate time series can also be used tomeasure the variability in the send rate, a property commonly referred to asthe smoothness. A low coefficient of variation means that the flow is sendingdata at a steady rate. If the send rate varies a lot it may be difficult for mediaapplications with a limited play-out buffer, to present an uninterrupted flow ofdata. In TCP, minor congestion events leads to the congestion window beingcut in two and more severe loss events result in the protocol having to start overin slow start from a window of one segment. In large, TCP-like responds in thesame way to congestion and thus the difference in smoothness is expected tobe minor when the loss rate is low. At higher loss rates, the looser coupling ofthe congestion control state to individual packets and not having a minimumtransmit timeout are likely to give TCP-like an advantage.

Furthermore, Fig. 4.6 shows the computed smoothness. TCP-like maintainsa steadier send rate than TCP and it is insensitive to high loss rates also overshort time scales. The coefficient of variation for TCP SACK is significantlyhigher over shorter time scales and for higher loss rates.

4 Conclusions

TCP-like features several of the numerous TCP improvements that have beenproposed during the last decade. While being more aggressive than TCP Reno,it is reasonably fair to TCP SACK at loss rates observed on the Internet today.

Simulations show that at shorter round trip times - up to approximately100ms - the differences between TCP-like and TCP SACK are more pronounced.If in addition the loss rate is high, not having a minimum transmission timeoutgives TCP-like better performance. TCP-like also recovers faster from severecongestion as its lack of reliability makes it less dependent on individual packets.

In the future we would like to explore the delay variations generated bythe two algorithms observed from an application point of view. Also, TCP-likeattempts to regulate the acknowledgment pace when losses are detected on thereturn path. Investigating the performance impact that this algorithm may haveis also an area to look into.


0

0.2

0.4

0.6

0.8

1

0.2 0.5 1 2 5 10

Equ

ival

ance

rat

io

Timescale for throughput measurement (seconds)

TCPL vs TCPLSACK vs SACKSACK vs TCPL

0

0.5

1

1.5

2

2.5

3

0.2 0.5 1 2 5 10

Coe

ffici

ent o

f Var

iatio

n

Timescale for throughput measurement (seconds)

SACK 128SACK 32

TCPL 128TCPL 32

Figure 4.6: Equivalence ratio: the upper line is for the case of 32 active flows andthe lower line represents 128 flows. In the lower figure you find the smoothnessof the flows.

Bibliography

[1] M. Allman, S. Floyd, and C. Partridge. Increasing TCP’s Initial Window.RFC Standards Track 3390, IETF, Oct. 2002.

[2] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshan, andRandy H. Katz. A comparison of mechanisms for improving TCP per-formance over wireless links. IEEE/ACM Transactions on Networking,5(6):756–769, 1997.

[3] Christian Bettstetter. Mobility modeling in wireless networks: categoriza-tion, smooth movement, and border effects. ACM SIGMOBILE MobileComputing and Communications Review, 5(3):55–66, Jul. 2001.

[4] E. Blanton, M. Allman, K. Fall, and L. Wang. A Conservative SelectiveAcknowledgment (SACK)-based Loss Recovery Algorithm for TCP. RFCStandards Track 3517, IETF, Apr. 2003.

[5] Ulf Bodin and Arne Simonsson. Effects on TCP from Radio-Block Schedul-ing in WCDMA High Speed Downlink Shared Channels. In QoFIS, volume2811 of Lecture Notes in Computer Science, pages 214–223. Springer, 2003.

[6] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd,V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan,S. Shenker, J. Wroclawski, and L. Zhang. Recommendations on QueueManagement and Congestion Avoidance in the Internet. InformationalRFC 2309, IETF, Apr. 1998.

[7] Jin Cao, William S. Cleveland, Dong Lin, and Don X. Sun. On the nonsta-tionarity of Internet traffic. In ACM Sigmetrics, pages 102–112, Cambridge,Massachousetts, United States, 2001. ACM Press.

[8] Vinton G. Cerf and Robert E. Kahn. A Protocol for Packet Network Inter-connection. IEEE Transactions on Communications, COM-22(5):637–648,May 1974.

[9] S. Crocker. Host software. http://www.ietf.org, RFC001, Apr. 1969.

81

http://www.ietf.org

82 Bibliography

[10] Hannes Ekstrom and Andreas Schieder. Buffer Management for the Inter-active Bearer in GERAN. In IEEE VTC, pages 2505–2509, Apr. 2003.

[11] Magnus Erixzon. DCCP-Thin for Symbian OS. Master’s thesis, LuleaUniversity of Technology, Sep. 2004. 2004:261 CIV.

[12] Magnus Erixzon, Joakim Haggmark, and Nils-Erik Mattsson. DCCPProjects. http://www.dccp.org, Jun. 2003.

[13] Aaron Falk and Mark Allman. On the Effective Evaluation of TCP. ACMSIGCOMM Computer Communication Review, 29(5):59–70, Oct. 1999.

[14] Kevin Fall and Sally Floyd. Simulation-based comparisons of Tahoe, Renoand SACK TCP. ACM SIGCOMM Computer Communication Review,26(3):5–21, Jul. 1996.

[15] S. Floyd. Optimum functions for computing the drop probability. E-mailavailable at http://www.aciri.org/floyd/REDfunc.txt, Oct. 1997.

[16] S. Floyd, T. Henderson, and A. Gurtov. The NewReno Modification toTCP’s Fast Recovery Algorithm. RFC Standards track 3782, IETF, Apr.2004.

[17] S. Floyd and E. Kohler. Internet Research Needs Better Models. ACMSIGCOMM Computer Communications Review, 33(1):29–34, Jan. 2003.

[18] Sally Floyd. A bug in the TFRC code in NS. Mail to the DCCP mailinglist, http://www.ietf.org/mail-archive/web/dccp/index.html, 2003.

[19] Sally Floyd, Mark Handley, and Eddie Kohler. Problem Statement forDCCP. Internet draft, IETF, Oct. 2002. Work in progress.

[20] Sally Floyd, Mark Handley, Jitendra Padhye, and Jorg Widmer. Equation-based congestion control for unicast applications. In ACM SIGCOMM Pro-ceedings of the conference on Applications, Technologies, Architectures, andProtocols for Computer Communication, pages 43–56, Stockholm, Sweden,Aug. 2000.

[21] Sally Floyd and Van Jacobson. Traffic Phase Effects in Packet-SwitchedGateways. Journal of Internetworking: Practice and Experience, 3(3):115–156, Sep. 1992.

[22] Sally Floyd and Van Jacobson. Random early detection gateways for con-gestion avoidance. IEEE/ACM Transactions on Networking, 1(4):397–413,Aug. 1993.

[23] Sally Floyd and Eddie Kohler. Profile for DCCP Congestion Control ID 2:TCP-like Congestion Control. Internet Draft 6, IETF, Jul. 2004. Work inprogress.

http://www.dccp.org

http://www.aciri.org/floyd/REDfunc.txt

http://www.ietf.org/mail-archive/web/dccp/index.html

83

[24] GSM Association. GSM World – 3GSM Platform.http://www.gsmworld.com/technology/3g/index.shtml, Feb. 2005.

[25] Andrei Gurtov. TCP Performance in Presence of Congestion and Corrup-tion Losses. Master’s thesis, University of Helsinki, Dec. 2000.

[26] Andrei Gurtov and Reiner Ludwig. Responding to Spurious Timeouts inTCP. In IEEE Infocom, pages 2313–2322, 2003.

[27] John Heidemann, Nirupama Bulusu, Jeremy Elson, Chalermek In-tanagonwiwat, Kun chan Lan, Ya Xu, Wei Ye, Deborah Estrin, and RameshGovindan. Effects of detail in wireless network simulation. In SCS Multi-conference on Distributed Simulation, pages 3–11, Phoenix, Arizona, USA,Jan. 2001. Society for Computer Simulation.

[28] John Heidemann, Kevin Mills, and Sri Kumar. Expanding Confidencein Network Simulation. IEEE Network Magazine, 15(5):58–63, Sep./Oct.2001.

[29] Hameenlinna. Overview of 3GPP Release 5. Technical Report 030375,ETSI Mobile Competence Center, Jun. 2003.

[30] Jun ichiro Itojun Hagino. DCCP in FreeBSD Kame? Mail sent to theIETF DCCP mailing list, Nov. 2004.

[31] IETF. Datagram Congestion Control Protocol (dccp) - working group.http://www.ietf.org/html.charters/dccp-charter.html, Feb. 2005.

[32] H. Inamura, G. Montenegro, R. Ludwig, A. Gurtov, and F. Khafizov. TCPover Second (2.5G) and Third (3G) Generation Wireless Networks. RFCBest Current Practice 3481, IETF, Feb. 2003.

[33] V. Jacobson. Congestion Avoidance and Control. In ACM SICOMM, pages314–329, Stanford, CA, Aug. 1988.

[34] Raj Jain. The Art of Computer System Performance Analysis. John Wiley& Sons, 1991.

[35] Niranjan Joshi, Srinivas R. Kadaba, Sarvar Patel, and Ganapathy S. Sun-daram. Downlink Scheduling in CDMA Data Networks. In ACM Mobicom,pages 179–190, 2000.

[36] Leonard Kleinrock. Information Flow in Large Communication Nets. RLEQuarterly Progress Report, Jan. 1972.

[37] Eddie Kohler, Mark Handley, and Sally Floyd. Datagram Congestion Con-trol Protocol (DCCP). Internet Draft 7, IETF, Jul. 2004. Work in progress.

[38] Troels Emil Kolding, Klaus Ingemann Pedersen, Jeroen Wigard, FrankFrederiksen, and Preben Elgaard Mogensen. High Speed Downlink PacketAccess: WCDMA Evolution. In IEEE Vehicular Technology Society News,pages 4–10, Feb. 2003.

http://www.gsmworld.com/technology/3g/index.shtml

http://www.ietf.org/html.charters/dccp-charter.html

84 Bibliography

[39] T.V. Lakshman, Arnold Neidhardt, and Teunis J. Ott. The Drop fromFront Strategy in TCP and in TCP over ATM. In IEEE INFOCOM, pages1242–1250, Mar. 1996.

[40] Barry M. Leiner, Vinton G. Cerf, David D. Clark, Robert E. Kahn, Leon-dard Kleinrock, Daniel C. Lynch, Jon Postel, Lawrence G. Roberts, andStephen S. Wolff. The Past and Future History of the Internet. Commu-nications of the ACM, 40(2):102–108, Feb. 1997.

[41] R. Ludwig and R. H. Katz. The Eifel Algorithm: Making TCP RobustAgainst Spurious Retransmissions. ACM Computer Communications Re-view, 30(1):30–36, Jan. 2000.

[42] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP Selective Ac-knowledgement Options. RFC Standards Track 2018, IETF, Oct. 1996.

[43] Nils-Erik Mattsson. A DCCP module for ns-2. Master’s thesis, LuleaUniversity of Technology, Feb. 2004. 2004:175 CIV.

[44] S. McCanne and S. Floyd. ns Network Simulator. Technical report, Infor-mation Sciences Institute, 2004.

[45] Douglas C. Montgomery. Design and Analysis of Experiments. John Wiley& Sones, 5th edition, 1997.

[46] Motorola. Evaluation Methods for High Speed Downlink Packet Accesss(HSDPA). Technical report, 3GPP, Jul. 2000.

[47] John Nagle. Congestion Control in IP/TCP Internetworks. RFC 896,IETF, Jan. 1984.

[48] Open Mobile Alliance. OMA Technical Section-Push Talk Over CellularWorking Group. http://www.openmobilealliance.org/, Feb. 2005.

[49] J. Padhye, V. Firiou, D. Towsley, and J. Kurose. Modeling TCP Through-put: A Simple Model and its Empirical Validation. In ACM SIGCOMMconference on Applications, technologies, architectures, and protocols forcomputer communication, pages 303–314, 1998.

[50] S. Parkvall, E. Dahlman, P. Frenger, P. Beming, and M. Persson. The Evo-lution of WCDMA Towards Higher Speed Downlink Packet Data Access.In IEEE VTC (Spring), 2001.

[51] Vern Paxson and Sally Floyd. Wide area traffic: the failure of Poissonmodeling. IEEE/ACM Transactions on Networking, 3(3):226–244, 1995.

[52] Vern Paxson and Sally Floyd. Why we don’t know how to simulate theinternet. In Winter Simulation Conference, pages 1037–1044, 1997.

[53] Janne Peisa and Eva Englund. TCP performance over HS-DSCH. In IEEEVTC Spring, volume 2, pages 987–991, May 2002.

http://www.openmobilealliance.org/

85

[54] J. Postel. Transmission Control Procol. RFC 793, IETF, Sep. 1981.

[55] Theodore Rappaport. Wireless Communications: Principles and Practice.Prentice Hall, 2nd edition, Dec. 2001.

[56] V. Rosolen, O. Bonaventure, and G. Leduc. A RED discard strategy forATM networks and its performance evaluation with TCP/IP traffic. ACMSIGCOMM Computer Communications Review, 29(3):23–43, Jul. 1999.

[57] I. Stojanovic, M. Airy, D. Gesbert, and H. Saran. Performance of TCP/IPOver Next Generation Broadband Wireless Access Networks. In IEEEWPMC, Aalborg, Denmark, Sep. 2001.

[58] Mats Sagfors, Reiner Ludwig, Michael Meyer, and Janne Peisa. BufferManagement for Rate-Varying 3G Wireless Links Supporting TCP Traffic.In IEEE VTC, pages 675–679, Apr. 2003.

[59] Mats Sagfors, Reiner Ludwig, Michael Meyer, and Janne Peisa. QueueManagement for TCP Traffic over 3G Links. In IEEE WCNC, pages 1663–1668, Mar. 2003.

[60] R Development Core Team. R: A language and environment for statisticalcomputing.

[61] W. Willinger and V. Paxson. Where Mathematics meets the Internet.Notices of the American Mathematical Society, 45(8):961–970, Aug. 1998.

[62] Yang Richard Yang, Min Sik Kim, and Simon S. Lam. Transient Behav-iors of TCP-friendly Congestion Control Protocols. Computer Networks,41(2):193–210, Feb. 2003.

[63] N. Yin and M.V. Hluchyj. Implications of Dropping Packets from the Frontof a Queue. In 7-th ITC, Oct. 1990.

congestion control in wireless cellular networks990348/fulltext01.pdf · puting power therefore...

Documents