978-1-4673-1239-4/12/$31.00 c�2012 IEEE

Experimental Evaluation of TCP Performance inMulti-rate 802.11 WLANs

Naeem Khademi, Michael Welzl and Stein GjessingNetworks and Distributed Systems Group, Department of Informatics, University of Oslo, Norway

Email: {naeemk,michawe,steing}@ifi.uio.no

Abstract—The goal of Rate Adaptation (RA) mechanisms in

802.11 WLANs is to provide optimum system throughput under

varying channel conditions (e.g. in presence of noise) by carrying

out run-time prediction and selection of the most appropriate bit-

rate. The cross-layer interaction of TCP, as the major transport

protocol in the Internet, with different RA mechanisms and

DCF is yet to be thoroughly investigated. Previously reported

efforts A) have never included real-life measurements of uplink

TCP traffic; B) lack a practical view because they do not

consider the RA mechanisms commonly deployed in today’s off-

the-shelf 802.11 devices; C) miss the study of RA mechanisms

in low-noise environments. This paper covers all the above

shortages, by conducting real-life measurements in two different

test-beds (NDlab and Emulab) alongside with simulations, to

study the performance of TCP coupled with different commonly

deployed RA mechanisms. Our measurements reveal that 1) most

conventional RA mechanisms are unable to distinguish frame

errors due to collisions from channel noise/interference, and will

respond to them negatively to some extent; 2) different than

downlink TCP, uplink TCP can be adversely affected by collision-

triggered rate downshifts that some RA schemes exhibit even

under perfect channel conditions or in low-noise environments;

3) the relatively recent Minstrel RA mechanism can counter this

negative uplink behavior well, yielding almost equal performance

as in the downlink case.

I. INTRODUCTION

Several modulation and coding schemes which translate intodifferent physical layer bit-rates (1∼11 Mbps in 802.11b and6∼54 Mbps in 802.11a/g) are provided by the IEEE 802.11standard [1]. This flexibility in bit-rate selection facilitatesrobust frame transmission in the presence of a given SINR(Signal to Interference and Noise Ratio). Rate Adaptation(RA) mechanisms predict changes in the channel conditionand react to them accordingly by changing the bit-rate in orderto maximize the system throughput. RA mechanisms shouldrapidly respond to short-term channel quality degradations andquickly recover when the situation has improved.

When noise is negligible, ideally the highest PHY rateshould be used, and one might be tempted to believe that RAcould simply be switched off. However, the random nature ofthe wireless channel can make it very hard to automatize sucha decision – and most users clearly would not want to manuallyre-configure their devices depending on the environment. RAmechanisms should therefore automatically choose the highestPHY rate when the noise level is very low, and it was shownin [2], [3] that, indeed, with TCP traffic, they usually do,seemingly rendering the negligible-noise scenario irrelevantfor further investigation. However, [2], [3] only considered

download traffic – as our previous simulations [4] indicated,and as the measurement results in this paper will show, thesituation differs greatly when we also consider uploads.

Our investigation requires examining the cross-layer inter-actions between RA mechanisms at the PHY/link, DCF at theMAC and TCP at the transport layer. Many RA mechanismshave been proposed in the literature; most of them are notimplemented in Wi-Fi devices. The goal of our study is toinvestigate the performance of currently deployed RA mech-anisms. Due to their vendor-specific nature and potentiallyproprietary license in other 802.11 chipsets, we ended up usingonly the well-known madwifi RA suite [5] for Atheros-basedtransmitter chipsets, which is an open-source driver operatingon the Atheros’ Hardware Abstraction Layer (HAL).

madwifi provides three1 rate adaptation mechanisms:AMRR [6], SampleRate [7] and Minstrel [8] – the large man-ufacturers Atheros and Broadcom use these RA mechanisms,using ported versions of the madwifi code. AMRR is the firstwell-known mechanism, and has been widely used in Atheroschipsets. SampleRate has replaced AMRR as the “standardmechanism” to compare against in the literature, and has alsobeen used for some years on Atheros devices. Minstrel is nowthe default in the ath5k and ath9k Atheros drivers as wellas the default in the b43 driver of Broadcom and a varietyof other drivers that use mac80211 [9] framework. It is alsothe default in madwifi itself. While superiority of Minstrel onother RA mechanisms in presence of noise and interferenceis shown by [10] using UDP measurements, there has beenno work evaluating its TCP performance in presence of highcontention and low noise levels to the best of our knowledgeand this paper is the first to tackle this issue.

A. Our contributions

We make two major contributions in this paper:1) Most RA mechanisms mistake frame loss caused by

contention as an indication of channel noise and reactto it (to some degree) by decreasing the bit-rate. Evenin low-noise environments, this can lead to sub-optimalperformance when the medium contention level is high.In contrast to UDP, this mistake is believed to have littleinfluence on TCP due to the low collision probability ofTCP downlink traffic [2], [3]. We show using real-life

1We rule out the study of a fourth included mechanism, ONOE, because itwas shown to have flaws [5].

tests that TCP uplink traffic can be heavily affected bythe choice of RA mechanisms. There is a growing de-mand for TCP uplink capacity (P2P applications, largeremail attachments, network drives, YouTube video andFacebook image uploads). The point of RA mechanismsis to improve the performance in the presence of noiseonly – from our results, it is clear that the presence ofTCP uplink traffic also makes low-noise environmentsvery relevant scenarios for investigation.

2) Previous work does not arrive at a general conclusionabout TCP performance since the RA mechanisms usedin today’s 802.11 devices are not studied and uplinkscenarios are not considered. In this work, we providethe first definite answer to the question of how TCPperforms in practical modern WLANs in low-noiseenvironments. We do this by studying and comparing thedownlink and uplink performance of TCP coupled withdifferent RA mechanisms that are used in Wi-Fi devices(AMRR, SampleRate and Minstrel), using both real-lifemeasurements and simulations. We consider differentrealistic usage scenarios – e.g. various contention levels,delays and TCP congestion control variants.

The rest of this paper is organized as follows: related workis discussed in Section II. The evaluated RA mechanismsare explained in detail in Section III. TCP performance overmulti-rate 802.11 WLANs is elaborated on in Section IV.The experimental setup and methodology are presented, andperformance evaluation results are demonstrated in Section V.We present our conclusions in Section VI.

II. RELATED WORK

TCP performance over 802.11 networks has been exten-sively studied, mainly addressing the unfairness issues be-tween upload and download flows [11], [12], [13], [14], [15].However, there have been only few works focusing on thecross-layer interaction of TCP with DCF with consideration ofdifferent RA mechanisms [2], [3]. Most studies that evaluatedifferent rate adaptation mechanisms are limited to UDPmeasurements [6], [7], [16], [17], [10].

Differentiating the source of frame losses is necessary tomaintain good performance under high contention levels, butit is a challenge for RA mechanisms. The proposed solutionin [17] (CARA) exploits the use of RTS/CTS frames. Toreduce the overhead incurred by RTS/CTS handshakes, theproposed RRAA method in [18] defines an adaptive RTS filterto occasionally turn them on upon frame losses potentiallycaused by collisions. The practicality of these mechanisms islimited because of the mandatory usage of RTS/CTS. On theother hand, work done in [19] takes a different approach bypassively measuring the channel busy time (CBT) to estimatethe real-time contention level. However its analysis of packetloss versus CBT did not exhibit a strong correlation, and thisrelationship varies depending on environmental factors.

Measurement results in [3] and the analytical model in [2]show that the active contention level is eased by TCP’s dy-namic behavior for downlink traffic, rendering a low collision

probability and hence avoiding frequent occurrence of ratedownshifts. This makes the choice of RA mechanism trivial fordownlink TCP. On the contrary, our previous work [4] demon-strated, using simulations, that uplink TCP performance candrastically deteriorate in the presence of a somewhat simplisticRA algorithm called AARF. AARF [6] is an extension of thewell-known Auto-Rate Fallback (ARF) [20] algorithm with aBinary Exponential Back-off (BEB) mechanism. It decreasesthe bit-rate over a fixed number of consecutive losses (e.g.θd = 2). RA mechanisms deployed in 802.11 devices performdifferently under scenarios with uplink traffic and react tocollisions in different ways.

III. RATE ADAPTATION MECHANISMS

Most RA mechanisms can be classified into two maincategories based on the way they gather information aboutthe channel condition: PHY layer-based or link layer-basedalgorithms. PHY algorithms use metrics such as SINR orReceived Signal Strength Indication (RSSI) to determine thechannel status, while link layer algorithms use frame loss andretransmission events (and/or their statistics). In this paper wefocus on link layer algorithms only because PHY algorithmsare shown to be imprecise in environments with reflectiveobstacles [7] and they normally require incompatible changesto the 802.11 standard (e.g. [21], [22]).

Three state-of-the-art link-layer algorithms are evaluated inthis paper, and will be explained in this section: AMRR,SampleRate and Minstrel. Note that some parameters usedin the madwifi implementation are different from the originalproposals; this will be pointed out where applicable.

A. AMRR

Adaptive Multi-Rate Retry (AMRR) was designed for use inhigh-latency hardware, more specifically on AR5212 chipsets[6]. It is an extension of the MRR algorithm initially used inmadwifi with the additional feature of BEB mechanism. Itsmain idea has been borrowed from AARF. AMRR exploitsthe functionalities provided by the AR5212 HAL, allowingit to create several unbounded FIFO queues containing trans-mission descriptors to schedule the packet transmissions. Eachdescriptor consists of a transmission status field, a pointer tothe outgoing packet, the size of data to be transferred and fourpairs of rate and retransmission count fields ([r0, c0], [r1, c1],[r2, c2], [r3, c3]) called as retry chain. After a descriptor isinitialized, it is inserted in one of the FIFO queues andlater accessed by hardware at the head of the queue whenthe medium is available for data transmission. For the firsttransmission attempt, r0 is used as the bit-rate. If transmissionfails, the hardware will try to resend the data with r0 for c0−1times. If the transmission keeps on failing, on consequent re-transmissions, r1 to r3 will be used c1 to c3 times, respectively.

The main proposal in [6] uses c0..c3 = 1 to rapidly reactto short-term variations of the wireless channel (madwifi’sAMRR implementation uses c0 = 4, c1 = 2, c2 = 2 andc3 = 2). The rate r3 is always the minimum available rate(e.g. 1 Mbps in 802.11b/g). The rates r1 and r2 are chosen to

be the immediately lower available rates below r0. The AMRRalgorithm uses a heuristic approach to determine r0 from itsprevious value and the transmission statistics of the elapsedperiod: On each rate selection process, if more than 10 packetswere transmitted and less than 10% of the packet transmissionsfailed during the previous period, AMRR increases r0 to theimmediately higher available rate, and it decreases r0 to theimmediately lower available rate if more than 33% of thepacket transmissions have failed during that period. Otherwiseit will keep the current value of r0 for the upcoming period.

B. SampleRate

The SampleRate algorithm tries to maximize the throughputby sending packets at the bit-rate that has the smallest average

packet transmission time including the time required to recoverfrom losses as measured by recent samples [7]. It estimatesframe transmission time at each bit-rate by averaging thetransmission times of previous packet transmissions at thatrate. It also periodically (on every 10th transmission) sendspackets at a random bit-rate chosen from the set of bit-rates that might perform better than the current one to gatherinformation about other bit-rates. These bit-rates are thosewith a perfect transmission time (the time of a successfultransmission without any retry) that is less than the currentbit-rate’s transmission time. It stops probing at a bit-rate thatexperiences four successive failures. SampleRate calculates theaverage transmission time using packets sent during the last10 sec to adapt to the channel condition (it uses an EWMA(Exponentially Weighted Moving Average) with a smoothingrate of 95% instead of a 10 sec window in madwifi). Thetransmission time of an n-byte packet given the bit-rate b andthe number of retries r is calculated by

tx time(b, r, n) = DIFS + backoff(r) + (r + 1)

∗(SIFS +ACK + header + (n ∗ 8/b))

where backoff(r) is the average back-off window for thespecific number of retries r.

C. Minstrel

Minstrel [8] initially implemented by D. Smithies, is cur-rently the default RA mechanism in madwifi since release0.9.4 and it is also ported to other drivers (e.g. using mac80211[9]). As its name suggests, the Minstrel algorithm takes awandering minstrel approach to find the optimum rate. It inher-its the characteristics of SampleRate while it also takes intoaccount the successfulness of packet transmission. Minstreluses an EWMA to process the success history of each rateto react to both short-term and long-term variations in thechannel condition. The measure of successfulness of packettransmission at rate b is defined as

ψ(b) = psuccess(b) ∗bits transmitted

elapsed time(1)

which adjusts the bit-rate to get the maximum number of databits through the wireless medium. psuccess(b) is

psuccess(b) =number of successful transmissions(b)

number of transmission attempts(b)

Every 100 ms (tunable in the driver code), psuccess of thecurrent period for each rate and also their EWMA are cal-culated and the rate statistics table is updated accordingly.After each calculation process, the decision is made aboutthe rate which provides the best throughput, second best

throughput and the highest success probability based on ψ andpsuccess derived from the table and those rates will be used forthe next 100 ms period to populate the retry chain. Minstrelalso collects information about different rates by sending aparticular percentage of randomly chosen frames (10% bydefault) at different rates as “look-around” (sample) frames.

As mentioned in Section III-A, four [ri, ci] pairs (retrychain) can be defined for each transmission descriptor. If aframe is a normal frame (90% of the frames), the retry chainwill be the best throughput, next best throughput, best successprobability and the lowest bit-rate accordingly. If it is a sampleframe (look-around) and the randomly selected rate is lowerthan the current best throughput, then the retry chain is bestthroughput, random look-around rate, best success probabilityand lowest base rate. However, if the randomly selected rateis higher than the current best throughput, the retry chainwill be random lookaround rate, best throughput, best successprobability and the lowest base rate. This selection of ratesprevents Minstrel from sampling rates lower than the bestthroughput rate when the channel condition is good, as itwill only sample a rate lower than the best throughput if thetransmission at the current best throughput fails. The EWMAhas a smoothing effect on the results so that the new ratestatistics data have a reasonable influence of the selected rate.EWMA uses a smoothing factor of 75% by default in madwifi.

IV. TCP PERFORMANCE OVER MULTI-RATE 802.11WLANS

As explained in Section I, most link layer RA mechanismswrongly take collisions as an indication of noise (to someextent), and react by decreasing the bit-rate. The self-clockingmechanism of TCP has been shown to have a mitigating effecton downlink traffic in infrastructure-based 802.11 WLANs[2], [3]. This phenomenon has two main reasons: first, in adownlink scenario the collision events are either of the ACK-Data or ACK-ACK type, making them less wasteful for thechannel compared to Data-Data collisions. Second, an ACKpacket transmission will always be a consequence of an AP’sdata packet transmission (with 1 : n+1 medium access ratio)resulting in very few nodes having a packet to transmit in theirupstream queue at any instant of time and therefore restrainingthe active contention level at the medium. Work done in [2]states that the number of stations actively participating incontention (Nactive) is 2-3 in equilibrium, for less than 100nodes in total. We believe that the assumptions in [2], [3]are too simplistic because of two main reasons: firstly, theylack the study of uplink traffic scenarios. Secondly, in real-lifetraffic scenarios with a mixed of uplink and downlink flows, itis possible that the data packets of both uplink and downlinkflows collide (Data-Data type).

In a typical uplink scenario, collision events are mostlyof the Data-Data type (following the medium access ratioof n : n + 1) that normally waste the channel for a longerperiod of time. In addition the upstream queues of eachwireless node are backlogged with data packets associated totheir respective flows’ TCP Congestion Window (cwnd). Thecollision probability of a station is generally determined as

psta = 1− (1− τsta)n−1 (2)

where τsta is the conditional attempt rate when a station hassomething in its queue to transmit and n is the number ofnodes. This probability increases in uplink scenarios withmore backlogged queues as n = Nactive initially. Basedon M/M/1 birth-death chain introduced in [2], τsta for adownlink scenario is calculated as

τsta =τap(1− pap)

n(1− psta)(3)

Alternatively in a uplink scenario, Eq. 3 can be modified as

τsta =nτap(1− pap)

(n− 1)(1− psta)

which both equations together show an O(1/n) correlationbetween τsta in uplink and downlink scenarios. Such higheruplink τsta leads to the higher collision probability basedon Eq. 2. To obtain a clear understanding of this issue wehave conducted a series of ns-2 simulations. The detailedsimulation setup can be found in Table I and the simulationnetwork topology is illustrated in Figure 1. Figure 2 depicts thecollision events during a 1 sec slice from a 100 sec simulationwhen 8 wireless nodes are uploading/downloading TCP 2

data to/from a server connected with an AP via a wiredlink with 100 ms delay (we have chosen the 98-99 sec slicewhere TCP flows are in their congestion avoidance phase). Itreveals that collision events are happening more frequently inan uplink scenario compared to downlink in general, and morespecifically for uploading data packets.

Figure 3 shows the aggregate queue occupancy of wirelessnodes and the AP in the whole simulation period. While theoverall queue size of wireless nodes is a minimal value (0-5ACK packets) in the downlink scenario, it increases sharplyto 40-120 data packets in the uplink scenario. The spikes ofoverall queue size over time are associated to cwnd of the TCPflows. A higher buffer occupancy eventually leads to a highercollision probability of data packets (Figure 2). In a typicallink layer RA mechanism, such collisions may trigger the ratedownshifts and data packets are most likely to be transmittedwith lower bit-rates.

Figure 3(c) shows that in the uplink scenario, the bufferoccupancy of the wireless nodes under AARF grows to 80-200 packets because the lower bit-rates used in AARF (due tosimultaneous rate downshifts) increase the transmission timeof data packets, which also prolongs the time to access themedium for each wireless node. Such delay to access the

2Unless otherwise noted SACK is used as the default TCP congestioncontrol mechanism in both simulations and experiments in this paper.

APServer

5m

100Mbps

...

Fig. 1. Simulation and experimental network topology

UP-TCP Data

UP-TCP ACK

DL-TCP Data

DL-TCP ACK

98 98.2 98.4 98.6 98.8 99Time (Sec)

Fig. 2. ns-2: collisions of TCP/ACK packets in two scenarios: download-only(DL-) and upload-only (UP-).

channel causes the upstream queues to be backlogged. Thelonger queues in this case will again trigger rate downshifts.This recursive process will eventually cause the wirelessmedium to be utilized at the lowest bit-rates most of the time,drastically degrading the overall system throughput.

TABLE INS-2 SIMULATION PARAMETERS

MAC protocol IEEE 802.11gPacket size 1500 bytesApplication FTP

TCP congestion control SACK (Linux kernel code 2.6.16.3) [23]Propagation model Ricean fading

Interface queue FIFO/DropTail (50 packets size)CWMin 16CWMax 1024

SIFS 10µsDIFS 28µs

Slot time 9µsRTS/CTS option Disabled

Node-to-AP distance 5mSimulator version ns-2.29

Optional RA mechanism AARF extension [24]

In addition to ns-2 simulations, we have conducted a seriesof real-life experiments. The detailed experimental setup ofthese tests is explained in Section V and therefore we excludeits description here for the purpose of conciseness. Similarlyeight wireless nodes are uploading/downloading TCP datato/from a server via an AP. Our measurements show thatwhen the bit-rate is set to the fixed 54 Mbps the averagepacket delivery probability of data frames containing TCP datapackets in the download scenario is around 70% while it dropsto 43% for the upload scenario, confirming our argument about

0

40

80

120

160

200

0 10 20 30 40 50 60 70 80 90 100Aggr

egat

e Bu

ffer O

ccup

ancy

(Pac

kets

)

Time (Sec)

802.11 NodesAP

(a) Download

0

40

80

120

160

200

0 10 20 30 40 50 60 70 80 90 100Aggr

egat

e Bu

ffer O

ccup

ancy

(Pac

kets

)

Time (Sec)

802.11 NodesAP

(b) Upload

0

40

80

120

160

200

0 10 20 30 40 50 60 70 80 90 100Aggr

egat

e Bu

ffer O

ccup

ancy

(Pac

kets

)

Time (Sec)

802.11 NodesAP

(c) AARF-Upload

Fig. 3. ns-2: aggregate interface queue occupancy.

collisions happening more frequently in uploads.Figure 4(a) presents the bit-rate distribution of TCP data

packets when AMRR is used. It reveals that their rate distribu-tion tends toward the higher rates in the download compared tothe upload scenario. While in the download scenario, 34% and32% of data packets are transmitted with the two highest bit-rates (54 and 48 Mbps), only 14% and 1% of the data packetsare transmitted with these rates in the upload scenario. Figure4(b) shows the rate distribution of TCP data packets withSampleRate. Similar to AMRR, the tendency is toward thehigher rates in the download compared to the upload scenario.In the download scenario, 19% and 31% of the data packetsare transmitted with the two highest PHY rates of 54 and 48Mbps, while in the upload scenario, only 8% and 16% of thedata packets are transmitted with these rates and the rest aretransmitted with the lower PHY rates.

While AMRR upload rates are distributed towards theextreme limits of the available rates (65% at 1 Mbps and 14%at 54 Mbps), SampleRate mostly chooses to use intermediaterates instead of falling back to the lowest rate, providing betteraverage uplink performance than AMRR. This is becauseAMRR chooses its r0 rate by only looking at the overall

loss ratio on without considering the delivery probability andthroughput potentially gained by that rate. This eventuallycauses r0 to be set to the basic rate most of the times formoderate to high contention levels. On the other hand, Sam-pleRate also suffers from a large throughput degradation in theuplink scenario and uses a large spectrum of different ratesinstead of the highest ones, while Minstrel is able to providealmost the same uplink rate distribution as in the downlinkcase (shown in Figure 4(c)). This is due to the main differencesbetween SampleRate and Minstrel: the metrics they choose todeduce the best throughput rate, and their sampling methods.Using the tx time metric in SampleRate can result in a poorrate selection caused by probing at the rates with very closetransmission times: assume a scenario where a node is sending1500 bytes packets at 48 Mbps over a perfect channel. After10 transmissions it sends a probing packet at 54 Mbps. Whileperfect transmission times of 48 and 54 Mbps rates are 672and 644µs respectively, a probing frame failure at 54 Mbpswith total 4 retry counts potentially caused by collisions willupdate its transmission time to 738µs 3, postponing the bit-rate increase for numerous lossless probing periods. After suchan increase, frequent occurrence of collisions can cause lowerrates to eventually be sampled again.

To verify the above observations, we have conducted ex-tensive real-life measurements of AMRR, SampleRate andMinstrel, which we will present in the next section.

V. EXPERIMENTAL RESULTS

This section describes our experimental methodology andevaluates the performance of TCP with different RA algo-rithms. We have conducted our experiments in two differenttest-beds to achieve more reliable results. These are Emulab

[25], an open network test-bed at the University of Utah andNDlab [26], our own 802.11 test-bed at the University ofOslo (Figure 5). We have used Emulab as our main test-bedwhile NDlab was used to locally verify our results; Whilepresenting all the results obtained in Emulab, we have onlyincluded some of the results obtained in NDlab for the sakeof brevity. The specifications of these test-beds are presentedin Table II. Both test-beds are clusters of concentrated nodesstacked in lab environments, where their close proximityprovides a suitable situation for the experiments that requirehomogeneous channel conditions.

Each wireless node works in 802.11b/g mode for indooractivities and uses the standard madwifi driver. We conductedour experiments in the 2.4 GHz ISM band with no networkoperating on the overlapping channels, thus minimizing thepotential interference from the neighboring networks. Eachexperiment was repeated for 50 runs, each of which lasting for100 sec. The presented results are the averages over all runsand shown with 95% confidence intervals. The iperf trafficgeneration tool was used to measure TCP traffic during eachtest. TCP’s send and receive buffers were set large enough

3These values are calculated based on EWMA used in the madwifi ratestatistics table.

0%

20%

40%

60%

80%

100%

Upload Download

Upl

oad/

Dow

nloa

d PH

Y R

ate

Dist

ribut

ion

1 Mbps2 Mbps5.5 Mbps6 Mbps9 Mbps11 Mbps12 Mbps18 Mbps24 Mbps36 Mbps48 Mbps54 Mbps

(a) AMRR

0%

20%

40%

60%

80%

100%

Upload Download

Upl

oad/

Dow

nloa

d PH

Y R

ate

Dist

ribut

ion

1 Mbps2 Mbps5.5 Mbps6 Mbps9 Mbps11 Mbps12 Mbps18 Mbps24 Mbps36 Mbps48 Mbps54 Mbps

(b) SampleRate

0%

20%

40%

60%

80%

100%

Upload Download

Upl

oad/

Dow

nloa

d PH

Y R

ate

Dist

ribut

ion

1 Mbps2 Mbps5.5 Mbps6 Mbps9 Mbps11 Mbps12 Mbps18 Mbps24 Mbps36 Mbps48 Mbps54 Mbps

(c) Minstrel

Fig. 4. Rate distribution of TCP data packets

(256 KB) to provide the opportunity for cwnd to grow withno restriction. The Maximum Segment Size (MSS) was set to1448 bytes (MTU=1500 bytes). To gather the rate statistics wehave used horst [27] to monitor the wireless traffic in additionto the information dumped by the madwifi kernel modules andtools. The experiments were conducted in a typical wired-cum-wireless scenario where wireless nodes upload/download datato/from a server which is connected to the AP via a 100 Mbpswired link (Figure 1). All nodes were synchronized with eachother using ntp.

A. Mixed-mode Traffic

We have begun our experiments by evaluating differentrate adaptation mechanisms under a mixed-traffic scenariowhere a different number of uploading/downloading stationsis participating in contention. Figure 6 shows the impact of

TABLE IITEST-BED SETUP

Test-bed Emulab NDlabPC Pentium III 600 MHz Dell OptiPlex GX620

Memory 256 MB 1 GB802.11 device D-Link DWL-AG530 D-Link DWL-G520

Chipset AR5212 AR5001Xtx queue length 200 pktsDriver (madwifi) 0.9.3.3, 0.9.4 0.9.4

OS FC4, FC6 FC14Linux kernel 2.6.18.6, 2.6.20.6 2.6.35.11

Node numbers 6-26 10

Fig. 5. NDlab test-bed

0

5e+06

1e+07

1.5e+07

2e+07

2.5e+07

3e+07

3.5e+07

8DL 6DL/2UP 4DL/4UP 2DL/6UP 8UP

Aggr

egat

e Th

roug

hput

(b/s

)

Number of Uploading/Downloading Stations

54MAMRR

SampleRateMinstrel

Fig. 6. Mixed upload/download traffic using TCP SACK

the upload/download ratio on the system’s aggregate through-put. While both AMRR and SampleRate degrade the systemaggregate throughput extensively with increase of up/downratio, Minstrel is able to keep the throughput level almostas high as when 54 Mbps fixed-rate is used for all values ofup/down ratio. We carried out this experiment for the two mostcommonly used TCP variants, SACK and CUBIC; since thebehavior was similar, we only show SACK.

The result in Figure 6 matches our expectation: the adverseimpact of RA on the overall performance tends to grow withthe number of uploading stations. Since it seems to us thatcombining uploads and downloads does not add any relevantinformation to our results, for the rest of the paper, we focusonly on pure download and upload scenarios for the sake ofclarity. These scenarios constitute the best and worst case.

B. Uplink vs. Downlink

The overall uplink and downlink throughput of TCP SACKis shown in Figure 7 for different RA mechanisms when 8wireless nodes are contending to access the medium. AMRR,SampleRate and Minstrel achieve 66%-84%, 91% and 98%-100% of the 54 Mbps fixed rate throughput in the down-link scenario, respectively, while AMRR and SampleRate’sthroughput drop to 2%-6% and 38%-44% of the 54 Mbps fixedrate in the uplink scenario. However Minstrel is still able tokeep this ratio at 93%.

We have also evaluated the performance of other TCPvariants to see if the above phenomenon is observable fordifferent TCP flavours. These are CUBIC [28], HSTCP [29]and Westwood [30]. The reason for this choice is that CUBICis the default congestion control mechanism in the Linux

0

5000000

10000000

15000000

20000000

25000000

30000000

Upload Download

Agg

rega

te T

hrou

ghpu

t (b/

s)

Scenario

#Emulab

AMRRSampleRateMinstrel54M−fixed

(a) Emulab

0

5000000

10000000

15000000

20000000

25000000

30000000

Upload Download

Agg

rega

te T

hrou

ghpu

t (b/

s)

Scenario

#NDlab

AMRRSampleRateMinstrel54M−fixed

(b) NDlab

Fig. 7. TCP SACK throughput

kernel at the time of writing and HSTCP is standardized.Westwood was designed to handle large bandwidth-delayproduct paths with potential packet loss and dynamic loads,and is therefore claimed to be suitable for wireless networks.

Figure 8 compares the uplink and downlink performance ofAMRR using different TCP variants. It reveals that, even in thepresence of moderate contention, the overall system through-put declines extensively in the upload scenario comparedto the download scenario. The uploading flows only enjoy4%∼25% of the throughput gained in the download scenario,achieving roughly between 0.8 to 3.3 Mbps on average, withno significant difference between the TCP variants.

Figure 9 shows the performance of SampleRate in thesame scenario. We can observe that, with SampleRate, theupload performance of all TCP variants improves significantlycompared to AMRR, with an upload/download performanceratio of 26%∼51%. While the aggregate throughput of theupload flows achieved by AMRR does not exceed 3.3 Mbps,SampleRate achieves within the ranges of 7.1 to 13.7 Mbps forall TCP variants. Despite being an improvement over AMRR,SampleRate still suffers from a large performance penaltyconsidering its up/down throughput ratio. Figure 10 shows thatMinstrel is able to almost eliminate the problems in the uplinkscenario, yielding 92%∼118% of the downlink performance.

C. Contention Effect

Figure 11 shows the impact of the contention level onthe performance of different RA mechanisms for variousnumbers of contending nodes (4∼24). AMRR performs verypoorly in the uplink scenario for all degrees of contentionachieving 0.6∼5 Mbps, and its downlink performance alsodeclines rapidly from 31 Mbps to around 10 Mbps as thecontention level increases (Figure 11(a)). SampleRate is able

0

5000000

10000000

15000000

20000000

25000000

30000000

CUBIC HSTCP Sack Westwood

Agg

rega

te T

hrou

ghpu

t (b/

s)

TCP Congestion Control

AMRR

UploadDownload

(a) Emulab

0

5000000

10000000

15000000

20000000

25000000

30000000

CUBIC HSTCP Sack Westwood

Agg

rega

te T

hrou

ghpu

t (b/

s)

TCP Congestion Control

AMRR

UploadDownload

(b) NDlab

Fig. 8. AMRR

to keep the uplink performance close to downlink for lowcontention levels gaining around 22 Mbps on average for 4contending nodes. SampleRate’s throughput declines exten-sively as the contention level intensifies, reaching only 4 Mbpswhen the number of nodes increases to 24 (Figure 11(b)).However Minstrel is able to keep the uplink performancearound 24∼28 Mbps, which is almost equal to the downlinkcase for all degrees of contention (Figure 11(c)).

D. RTT Impact on uplink TCP performance

A wireless node’s Internet access is provided by anAP/gateway acting as a relay between wireless and wirednetworks. Internet traffic initiated by such a node normallyexperiences a variety of RTTs on the wired side, dependingon the choice of destination and path. To have a realisticevaluation of uplink TCP performance, it is essential to takethe wired link delay into consideration. We measured theRTT of the top 500 web servers in the Internet providedby Alexa [31] from a node in NDlab. The measured averageRTT was 182 ms giving a one-way wired delay of 91 ms onaverage (the RTT on our wireless network was negligible).Our measurement also matches the data shown in [32].

We repeated the ns-2 simulations of Section IV for variouswired delays. Figure 12 shows the collision events during a1 sec time-slice for delays ranging from 10 to 200 ms. It revealsthat the collision probability decreases as the delay increases,and collision events totally vanish when the delay is equalto or greater than 200 ms. The reason behind this is that forhigher wired delays, TCP data packets spend most of theirtime on the wired side, thus allowing the upstream queues ofthe nodes to drain (since cwnd growth depends on the RTT).

Figure 13 is the experimental evaluation of different RAmechanisms for various wired delays when each experiment

0

5000000

10000000

15000000

20000000

25000000

30000000

CUBIC HSTCP Sack Westwood

Agg

rega

te T

hrou

ghpu

t (b/

s)

TCP Congestion Control

SampleRate

UploadDownload

(a) Emulab

0

5000000

10000000

15000000

20000000

25000000

30000000

CUBIC HSTCP Sack Westwood

Agg

rega

te T

hrou

ghpu

t (b/

s)

TCP Congestion Control

SampleRate

UploadDownload

(b) NDlab

Fig. 9. SampleRate

run was conducted for a duration of 1000 RTTs to obtain athroughput based on the same average cwnd sawtooth behav-iors (the same scenario as in Section V-B). The higher collisionprobability with lower RTTs triggers the bit-rate downshiftsand leads to the poor performance of AMRR and SampleRate,while Minstrel’s throughput is close to the throughput achievedby the 54 Mbps fixed rate. Collisions vanish for delays morethan 200-250 ms, providing the same uplink throughput as54 Mbps for all rate adaptation mechanisms. However forRTTs less than 200 ms the choice of RA mechanism playsan important role in determining the uplink TCP performanceof 802.11 WLANs. We carried out this experiment for the twomost commonly used TCP variants, SACK and CUBIC; sincethe behavior was similar, we only show SACK.

VI. CONCLUSIONS

We have presented our investigation of cross-layer interac-tions of TCP with 802.11 DCF and different RA mechanisms(AMRR, SampleRate and Minstrel) through simulations andreal-life measurements in two different test-beds. Our experi-ments show that uplink TCP performance can be affected bythe choice of RA mechanism in infrastructure-based WLANs,even in low-noise environments, due to their inability todifferentiate the source of frame loss. While AMRR andSampleRate degrade the TCP performance in such scenariosexcept for very high RTTs, Minstrel is able to keep theuplink performance at roughly the same level as downlinkin various different scenarios, e.g. with a varying number ofcontending nodes, different RTT values and under differentTCP congestion control variants.

The good uplink performance of Minstrel over other RAmechanisms has mainly two reasons: 1) instead of measuringthe packet transmission time at a rate which can have a

0

5000000

10000000

15000000

20000000

25000000

30000000

CUBIC HSTCP Sack Westwood

Agg

rega

te T

hrou

ghpu

t (b/

s)

TCP Congestion Control

Minstrel

UploadDownload

(a) Emulab

0

5000000

10000000

15000000

20000000

25000000

30000000

CUBIC HSTCP Sack Westwood

Agg

rega

te T

hrou

ghpu

t (b/

s)

TCP Congestion Control

Minstrel

UploadDownload

(b) NDlab

Fig. 10. Minstrel

misleading effect when the transmission times of two ratesare very close, Minstrel estimates the potential throughputper rate using Eq. 1, which also incorporates the deliveryprobability; 2) while bit-rate selection in SampleRate is toosensitive towards single probing failures by probing on every10th packet transmission, Minstrel distributes the samplingframes randomly around different rates and chooses the best

throughput rate every 100 ms, therefore having more samplingframes taking part in each rate selection process. Randomdistribution of sampling frames in time and rate makes the bit-rate selection unbiased toward a single frame loss at the currentrate or the rate being probed, as the collision probability ishomogeneous among different rates.

Our observations lead us to recommend Minstrel as thedefault RA mechanism for deployment in 802.11 devices inlow-noise environments. A future investigation, focusing onnoise in all its facets, could complement our work to draw acomplete picture of which RA mechanism to use.

REFERENCES

[1] “IEEE standard for information technology-telecommunications andinformation exchange between systems-local and metropolitan areanetworks-specific requirements - part 11: Wireless LAN medium accesscontrol (MAC) and physical layer (PHY) specifications,” IEEE Std

802.11-2007 (Revision of IEEE Std 802.11-1999), 12 2007.[2] J. Choi, K. Park, and C. kwon Kim, “Cross-layer analysis of rate

adaptation, DCF and TCP in multi-rate WLANs,” in INFOCOM 2007.[3] S. Choi, K. Park, and C.-k. Kim, “On the performance characteristics

of WLANs: revisited,” SIGMETRICS Perform. Eval. Rev., vol. 33, pp.97–108, June 2005.

[4] N. Khademi, M. Welzl, and R. Lo Cigno, “On the uplink performanceof TCP in multi-rate 802.11 WLANs,” in NETWORKING 2011.

[5] (2011) Multiband Atheros Driver for Wireless Fidelity. [Online].Available: http://madwifi-project.org/

[6] M. Lacage, M. H. Manshaei, and T. Turletti, “IEEE 802.11 rateadaptation: a practical approach,” in MSWiM ’04.

[7] J. C. Bicket, “Bit-rate selection in wireless networks,” Masters thesis,MIT, Tech. Rep., 2005.

0

5e+06

1e+07

1.5e+07

2e+07

2.5e+07

3e+07

3.5e+07

4 8 12 16 20 24

Aggr

egat

e Th

roug

hput

(b/s

)

Number of nodes

CUBIC-UPHSTCP-UP

Sack-UPWestwood-UP

CUBIC-DLHSTCP-DL

Sack-DLWestwood-DL

(a) AMRR

0

5e+06

1e+07

1.5e+07

2e+07

2.5e+07

3e+07

3.5e+07

4 8 12 16 20 24

Aggr

egat

e Th

roug

hput

(b/s

)

Number of nodes

CUBIC-UPHSTCP-UP

Sack-UPWestwood-UP

CUBIC-DLHSTCP-DL

Sack-DLWestwood-DL

(b) SampleRate

0

5e+06

1e+07

1.5e+07

2e+07

2.5e+07

3e+07

3.5e+07

4 8 12 16 20 24

Aggr

egat

e Th

roug

hput

(b/s

)

Number of nodes

CUBIC-UPHSTCP-UP

Sack-UPWestwood-UP

CUBIC-DLHSTCP-DL

Sack-DLWestwood-DL

(c) Minstrel

Fig. 11. Aggregate throughput vs. contention level

10

50

75

100

125

150

175

200

98 98.2 98.4 98.6 98.8 99

Wire

d D

elay

(ms)

Time (Sec)

Fig. 12. ns-2: collisions vs. wired link delay

0

5e+06

1e+07

1.5e+07

2e+07

2.5e+07

3e+07

0 50 100 150 200 250 300 350 400 450 500

Thro

ughp

ut (b

/s)

Wired Link Delay (ms)

54M-fixedAMRR

SampleRateMinstrel

Fig. 13. Impact of RTT on uplink TCP SACK

[8] “Minstrel Description,” http://madwifi-project.org/browser/madwifi/trunk/ath rate/minstrel/minstrel.txt.

[9] mac80211 API. http://linuxwireless.org/en/developers/Documentation/mac80211.

[10] W. Yin, K. Bialkowski, J. Indulska, and P. Hu, “Evaluations of madwifimac layer rate control mechanisms,” in IWQoS’10.

[11] N. Khademi and M. Othman, “Size-based and direction-based TCPfairness issues in IEEE 802.11 WLANs,” EURASIP J. Wirel. Commun.

Netw., vol. 2010, pp. 49:1–49:13, April 2010.[12] H. Wu, Y. Peng, K. Long, S. Cheng, and J. Ma, “Performance of

reliable transport protocol over IEEE 802.11 wireless LAN: analysisand enhancement,” in INFOCOM 2002.

[13] S. Pilosof, R. Ramjee, D. Raz, Y. Shavitt, and P. Sinha, “UnderstandingTCP fairness over wireless LAN,” in INFOCOM 2003.

[14] N. Blefari-Melazzi, A. Detti, I. Habib, A. Ordine, and S. Salsano, “TCPfairness issues in IEEE 802.11 networks: Problem analysis and solutionsbased on rate control,” Wireless Communications, IEEE Transactions on,vol. 6, no. 4, pp. 1346 –1355, april 2007.

[15] A. C. H. Ng, D. Malone, and D. J. Leith, “Experimental evaluation ofTCP performance and fairness in an 802.11e test-bed,” in E-WIND ’05.

[16] P. Gangwal, “Implementation and experimental study of rate adaptationalgorithms in IEEE 802.11 wireless networks,” Masters thesis, IowaState University, Tech. Rep., 2009.

[17] J. Kim, S. Kim, S. Choi, and D. Qiao, “CARA: collision-aware rateadaptation for IEEE 802.11 WLANs,” in INFOCOM 2006.

[18] S. H. Y. Wong, H. Yang, S. Lu, and V. Bharghavan, “Robust rateadaptation for 802.11 wireless networks,” in MobiCom ’06.

[19] P. Acharya, A. Sharma, E. Belding, K. Almeroth, and K. Papa-giannaki, “Congestion-aware rate adaptation in wireless networks: Ameasurement-driven approach,” in SECON ’08.

[20] A. Kamerman and L. Monteban, “WaveLAN-II: a high-performancewireless LAN for the unlicensed band,” Bell Labs Technical Journal,vol. 2, no. 3, pp. 118–133, 1997.

[21] G. Holland, N. Vaidya, and P. Bahl, “A rate-adaptive MAC protocol formulti-hop wireless networks,” in MobiCom ’01.

[22] B. Sadeghi, V. Kanodia, A. Sabharwal, and E. Knightly, “OAR: anopportunistic auto-rate media access protocol for ad hoc networks,”Wirel. Netw., vol. 11, pp. 39–53, January 2005.

[23] A Linux TCP implementation for NS2. http://netlab.caltech.edu/projects/ns2tcplinux/ns2linux/.

[24] ns-2.29 Wireless Update Patch. http://perso.citi.insa-lyon.fr/mfiore/.[25] Network Emulation Testbed. http://www.emulab.net/.[26] NDlab 802.11 Testbed. http://nd-wifi-testbed.wiki.ifi.uio.no/.[27] Lightweight 802.11 WLAN Analyzer. http://br1.einfach.org/tech/horst/.[28] S. Ha, I. Rhee, and L. Xu, “CUBIC: a new TCP-friendly high-speed

TCP variant,” SIGOPS Oper. Syst. Rev., vol. 42, pp. 64–74, July 2008.[29] S. Floyd, “Highspeed TCP for large congestion windows,” RFC 3649

(Experimental), December 2003.[30] S. Mascolo, C. Casetti, M. Gerla, M. Y. Sanadidi, and R. Wang, “TCP

Westwood: Bandwidth estimation for enhanced transport over wirelesslinks,” in MobiCom ’01.

[31] Alexa top 500 web servers. http://www.alexa.com/.[32] Internet Traffic Report. http://www.internettrafficreport.com/.