WIXLIB

802.11 ARQ Scheme Analysis in presence ofData and Stream TrafficClaudio E. Palazzi – cpalazzi@cs.ucla.eduComputer Science Department, University of California Los AngelesBoelter Hall, Los Angeles CA, 90095 USADipartimento di Scienze dell’Informazione, Università di BolognaVia Mura Anteo Zamboni 7, 40127 Bologna, ItalyAbstract“On-line everywhere and at every time”: this declaration represents one of the mostchallenging issue in nowadays networking. In practical terms, a ubiquitous service can beprovided only by a wireless technology as, for instance, the common Wi-Fi 802.11b.However, since the high number of applications available to the users and their differentcharacteristics, a discussion about the optimality of some design choices of 802.11 ARQscheme is required.We claim that the current setting of the maximum number of retransmissions in the 802.11protocol not necessarily corresponds to the optimal trade-off. As a demonstration, we presentresults obtained via simulation and, finally, we provide future directions in order to find themost efficient value for the maximum number of retransmissions at the MAC layer.Keywords: 802.11, ARQ, TCP Westwood, Wireless.1. IntroductionHowever, the interaction betweenmobile devices and the Internet, and theneed for reliable data transfer, havegenerated several unresolved problems.The main challenges that we face in amobile environment are [5]: Limited and variable bandwidth; High and variable latency that couldbe independent of the networkcongestion level; High BER (Bit Error Rate) andconsequently losses of many packets; Frequentandalsoextendeddisconnections, depending on theuser’s mobility; Limited computational and energyresources of the mobile device; Mobility of the connection (handoff).At present, in which an increasingnumber of people uses mobile technologyto obtain information from the Internet orto utilize email, it is easy to foresee afuture in which the synergy betweenwireless and the Internet becomes anintegral part of daily life. Virtual libraries,remote-working, video-telephony over IP,games, remote-medicine, video and musicon demand, are only a few of theinnumerable services that will be availablein every place and at every time. Peoplewill be allowed to be continuouslyconnected during the whole day,regardless of their location (home,workplace, car, airport, hotel ) andutilizing a plethora of old and new devices(PCs, laptops, PDAs, cell phones, otherhandheld devices or next generationappliances ) .Since TCP was designed in a timewhen networks were based exclusively on1

wired technology, its flow control andcongestion control functions fail whenintroduced into a wireless context [13]. Inorder to understand the reasons of thisfailure we should remember thattraditional TCP uses packet losses as ametric to evaluate the congestion level ofthe network. Consequently, when a packetis considered to be lost, TCP reduces thedata sending rate. In presence of numerouslosses related to non-congestion factors, asin a wireless environment, this behavior isnot appropriate and causes a consistentunderutilization of the link bandwidth [4].As a result, we experience a considerabledecline in the measured performancecompared to the quality of serviceexpected by the users.react accordingly. We also review somearticles related to the need of theretransmission mechanism in the MAC802.11 protocol.The 802.11 MAC layer protocolattempts to face the packet loss problemby implementing its own retransmissionscheme [3]. This scheme hides wirelesserror losses from the TCP’s congestioncontrol mechanism, thus avoidingdeleterious multiple reductions of the datasending window. On the other hand, localretransmissions affect packet deliverydelay by increasing its variability andtherebyaffectingtime-constrainedapplications such as audio or video stream.Tsaoussidis and Badr propose the useof special probe packets after each loss[16]. When one of these reaches thereceiver, the measured delays of theseprobing packets, is used to understand ifthe network is congested and, only in thiscase, to diminish the data sending rate. Ifthe wireless link is experiencing adisconnection or a fading, the probe cycleis extended, thus avoiding further datalosses and consequently erroneousrestrictions of the sending rate. Theirpurpose is also obtaining a better energyresource consumption.Biaz and Vaidya suggest the use ofdifferences in the interarrival times of twodata packets as an interpretative metric forthe causes of a loss [15]. They state thatwhen the difference between the arrivaltimes of the packets preceding andsucceeding a lost one is about twice thelast averaged interarrival time, then theloss is due to corruption. Otherwise, whenthis difference is almost the same as theaveraged interarrival times, the loss can beconsidered as occurring on the wired pathdue to congestion.In section 2, we review some articlesthat lend support to the aim of oursimulations. We comprehensively explainour ns-2 environment in section 3, and weshow the simulation results in section 4.Lastly, conclusions, comments, and futureworks are stated in section 5.In their work, Mascolo et al. suggest anew transport protocol, named TCPWestwood, which uses an end to endestimation of the channel capacity [1].While traditional TCPs blindly reduce thedata sending rate every time a data packetis lost, the key innovative idea in theirwork is to use the rate of the returningacknowledgments of received data tomeasure the effective link availability atthe sender. This bandwidth estimation iscomputed by sampling and exponentialfiltering methods and then used, after aloss or during slow start, to appropriatelyset the slow start threshold.2. Related worksIn recent years, many researchers havefocused their studies on the problems thatTCP encounters in a wireless environment[14]. Solutions proposed to face thoseproblems can be grouped into three maincategories: link layer solutions, splitconnection transport protocols (also called“walled garden”) and brand-new end-toend transport protocols. In this section, wefocus on the last category, in particular onnew transport protocols that attempt toestimate the condition of the channel andA new end-to-end transport protocol isalso proposed by Sinha et al. [8]. Theyface the high number of errors and thevariable latency of a wireless environmenteliminating the timeout mechanism, using2

the MAC layer, depending on the upperlayer protocol.periodic SACK packets [9] to understandwhen a retransmission is appropriate, andestimating the channel capacity to set thedata sending rate. In their protocol, thesender includes in its packets the leavingtime, thus the receiver can use thisinformation and the interarrival times tomeasure the bandwidth and communicatethe sending rate to the sender by its SACKpackets. If the sender doesn’t receive anySACK for a long time, it suspends the datatransmission and starts sending probepackets until an acknowledgment from thereceivermakesitresumethecommunication.Taking inspiration from all theseworks, it becomes interesting to test how adifferentmaximumnumberofretransmissions impacts TCP and UDPflow performance and, moreover, tocompare results when TCP New Reno isreplaced by TCP Westwood ABSE(Adaptive Share Bandwidth Estimation)[2].3. Simulation environmentIn the interest of analyzing the impact ofthe 802.11 ARQ scheme, we cannotoverlook the work of Nam et al. [6].Experimenting TCP and UDP over 802.11with different signal levels, they showedthat without retransmission implementedat the link layer, loss rates becomeunacceptable for any application.NS-2 is a widely used networksimulator [11]: many scientific articlesregarding various aspects of networking,especially on TCP and wireless scenarios,are based on this tool. We have used theseventh version coupled with the mostrecent version of the NOAH extension,which allows directly sending MACframes to a specific mobile node withoutrouting [12]. This helped us in creating anenvironment where the results obtained arefree of superfluous interference.TheclaimthatMAClayerretransmissions improve TCP performanceis confirmed by Xylomenos and Polyzos,who experimented TCP and UDP on aWLAN and analyzed their behavior withdifferent interfaces and bidirectional TCPtraffic [7]. On the other hand, a highnumber of repeated retransmissions,especially with short paths, can cause TCPto timeout anyway and retransmit the samedata as the MAC layer. Moreover, MACretransmissions can be wasteful andpotentially harmful for time-sensitiveapplications, such as real time video oraudio over UDP. Their suggestion is todifferentiate the retransmission policies atThe configuration of the simulation iseasily explained by fig. 3.1. A mobiledevice receives various flows of data fromfixed nodes, and only the last hop of theconnection is wireless, with an 802.11bMAC layer. Given the capacity of thevarious links and the buffer sizes at eachnode, it can be clearly understood that thebottleneck in this scenario will be the linkbetween the Access Point and the mobiledevice.Total Min one way delay: 73 msMin RTT: 146 msTCP (FTP)20 Mbps, 1 ms1000 pktsbuffers 100 Mbps70 ms delayAP50 pkts bufferUDP (CBR)5 Mbps, 1 msFig. 3.1 – The simulated environment3802.1111 Mbps10 meters apart(avg. 2 ms delay)

of the queue. The red line is the congestionwindow size of the TCP flow and thegreen line is its slow start threshold.In this scenario a single TCP streamstarts at second 0 and ends at second 100,while a variable number of UDP flows,one or five carrying CBR traffic starts atsecond 50 and lasts till the end. For eachof these configurations, simulations havebeen replicated to employ a particular TCPprotocol (New Reno or Westwood ABSE)and a different setting for the maximumnumber of MAC layer retransmissions,with values from 1 to 4. A summary of themain characteristics of the various flowsfollows: Single TCP flow (bulk transfer):o Type: Westwood ABSE or NewRenoo Duration: 100 secondso Packet size: 1000 bytes1 or 5 UDP CBR flows:o Starts at t 50 seco Audio stream: 100 byte packetsat50pkt/sec(20msinterdeparture time interval)802.11b MAC layer retransmissions:o maximum 1, 2, 3, or 4Fig. 4.1 – TCP New Reno and 1 UDPUtilizing TCP Westwood as thetransport protocol for the single FTP dataflow doesn’t significantly change themeasured performance. In the case ofaudio flow, for example, the channelutilization of TCP Westwood is 13.72%with only one CBR stream and 12.38%with 5 CBR streams. TCP New Renoreaches 13.19% of channel capacityutilization with 1 CBR stream and 12.76%with 5 CBR streams. The CBR throughputdoes not present variations whencomparing the various cases.4. Results of the simulationsIn the aim of figuring out how manyretransmissions at the MAC layer wereally need in a typical wirelessenvironment, we have run a set ofsimulations where the mobile node wasplaced at 10 meters from the AP that wastransmitting with a power of 1mW (0dbm). We have then changed severalparameters such as the maximum numberof retransmissions at the MAC layer, thenumber of UDP flows and the transportprotocol, producing results for everycombination of these. UDP flows are notrepresented in the following graphs evenif, of course, they impact on the TCPbehaviors in most cases.Fig. 4.2 – TCP New Reno and 5 UDPIn our simulations we have noticed that,for one single retransmission at the MAClayer, all the losses are due to wirelessproblems; congestion has no possibility ofoccurring. Using 3 as the maximumnumber of retransmissions at the MAClayer, wireless errors are always recoveredby the 802.11b ARQ scheme and losses atthe transport layer are only due toIn fig. 4.1 we can see how poorly TCPNew Reno performs with only oneretransmission implemented in the802.11b protocol even in the case withvery low concurrent traffic. The blue lineis the calculated bandwidth-delay product,expressed in packets, plus the 50 packets4