cross-layer congestion control in ad hoc wireless networks · cross-layer congestion control in ad...

Ad Hoc Networks 4 (2006) 687–708

www.elsevier.com/locate/adhoc

Cross-layer congestion control in ad hoc wireless networks

Dzmitry Kliazovich, Fabrizio Granelli *

Department of Information and Communication Technologies, University of Trento, Via Sommarive 14, I-38050 Trento, Italy

Received 18 February 2005; received in revised form 18 July 2005; accepted 5 August 2005Available online 31 August 2005

Abstract

The paper presents the problem of performance degradation of transport layer protocols due to congestion of wire-less local area networks. Following the analysis of available solutions to this problem, a cross-layer congestion avoid-ance scheme (C3TCP) is presented, able to obtain higher performance by gathering capacity information such asbandwidth and delay at the link layer. The method requires the introduction of an additional module within the pro-tocol stack of the mobile node, able to adjust the outgoing data stream based on capacity measurements. Moreover, aproposal to provide optional field support to existing IEEE 802.11 protocol, in order to support the presented conges-tion control solution as well as many other similar approaches, is presented. Achieved results underline good agreementwith design considerations and high utilization of the available resources.� 2005 Elsevier B.V. All rights reserved.

Keywords: Congestion control; TCP-over-wireless; Multi-hop wireless networks

1. Introduction

The IEEE 802.11 standard [1] represents theleading solution providing communications overwireless local area networks. A section of the stan-dard specifies a network architecture, called ad

hoc, which is capable to operate without therequirement for a fixed infrastructure. For suchreason, in the remainder of the paper, IEEE

1570-8705/$ - see front matter � 2005 Elsevier B.V. All rights reservdoi:10.1016/j.adhoc.2005.08.001

* Corresponding author. Tel.: +39 0461882062.E-mail addresses: [email protected] (D. Kliazovich),

[email protected] (F. Granelli).

802.11 will be considered as the reference MAC/PHY protocol stack.

The main limitation present in the standard isthe restriction of the ad hoc network to the casewhen all the stations are located in range of eachother. However, ongoing research overcame suchlimitations, allowing data delivery over an end-to-end path which can consist of several wirelesshops. For that reason, the paper considers thegeneral case of data transport over an ad hocmulti-hop wireless network.

Moreover, for the purpose of the paper, theproblem of network congestion is considered as

ed.

mailto:[email protected]

mailto:[email protected]

688 D. Kliazovich, F. Granelli / Ad Hoc Networks 4 (2006) 687–708

the main reason for potential performance degra-dation, while aspects related to the nature of wire-less links, such as limited bandwidth, increasedlatency, channel losses, mobility, etc., which intro-duce performance degradation are neglected.

Congestion occurs when the amount of datasent to the network exceeds the available capacity.Such situation leads to increased buffer spaceusage in intermediate nodes over the data path,leading to data losses in case of shortage of re-sources. Transmitted data start to be droppedwhen available buffer resources, which are physi-cally limited, are exhausted.

Such situation decreases network reliability inthe sense of service provisioning for data communi-cations. Transport-level protocols improve reliabil-ity by implementation of different error recoveryschemes. However, they could lead to excessivedata retransmissions, reducing an importantparameter such as network utilization, while atthe same time increasing latency in data delivery.

This paper targets the core reason for networkcongestion—the amount of traffic emitted to thenetwork. For such reason, the proposed solutionfor congestion avoidance is to control (and possi-bly optimize) the amount of traffic being sent ontothe network, considering limited availability ofnetwork resources.

The rest of the paper is organized as follows:Section 2 presents an insight related to the natureof congestion, while Section 3 outlines the state-of-the-art in the field of TCP adaptation to wirelesslinks. The proposed approach is detailed in Section4, and experimental evaluation of its performanceis presented in Section 5. Finally, Section 6 drawssome conclusions and outlines of future work onthe topic.

2. Nature of congestion

TCP/IP reference model defines a set of proto-cols that enable communication over the Internet.No layer has complete and real-time informationabout available network resources over themulti-hop path where the communication is per-formed. For that reason, the sources can avoidnetwork congestion based on network feedback,

which is obtained as a reaction to a certain amountof data being sent on the network.

The dominant transport protocol in the Inter-net is the Transmission Control Protocol (TCP)[2], used by a variety of applications [3,4]. TCP isa reliable connection-oriented byte-stream proto-col which performs congestion control dynami-cally during the data communication process.

TCP congestion control is performed on an end-to-end basis. The receiver provides an acknowl-edgement (ACK) feedback back to the sender.Relying on the information provided by ACKs,the sender can detect which packets are lost duringtransmission over the communication path.

The congestion control algorithm employed byTCP is window-based [5]. Congestion window(cwnd) controls the amount of data the sender isallowed to output to the network withoutacknowledgement. The congestion window evolu-tion is the key mechanism for TCP congestion con-trol. TCP uses additive increase and multiplicativedecrease strategy for its window adjustmentaccording to network conditions. The main phasesof TCP window evolution are presented in Fig. 1.

The connection is initiated with window sizeequal to one packet (1 MSS—Maximum SegmentSize). Then, cwnd is increased exponentially forevery non-duplicate ACK reception until the SlowStart Threshold (ssthresh) is reached. Prior theconnection establishment, ssthresh is set to an ini-tial value, which depends on the implementation ofthe protocol stack, and then adjusted on the basisof the estimate of the network capacity. This tech-nique is called slow start phase.

When the ssthreshold is reached, TCP enterscongestion avoidance phase. The window is in-creased linearly by one packet for each receivedACK. The window growth in this phase is limitedto a maximum window size, negotiated betweensender and receiver during connection estab-lishment and then updated on the fly during thecommunication process (the receiver�s advertisedwindow).

There are two ways for TCP sender to detectdata loss occurred on the communication link:reception of duplicate ACKs (dupacks) and timeoutoccurrence. In the first case, a dupack is generatedby the receiver upon reception of an out-of-order

0

2

4

6

8

10

12

14

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

Number of ACKs received

Co

ng

esti

on

Win

do

wssthresh

ssthresh

Slow StartCongestionAvoidance

timeoutoccurance

Fig. 1. TCP congestion window (cwnd) evolution.

D. Kliazovich, F. Granelli / Ad Hoc Networks 4 (2006) 687–708 689

packet, detected through the analysis of sequencenumbers of incoming packets. Duplicate ACKreception triggers congestion window reductionto the half of its current size. In the second case,upon the timeout occurrence, TCP reduces the sizeof cwnd to its initial value (equal to 1) enteringslow start phase.

In summary, TCP increases congestion windowuntil the amount of traffic present in the networkexceeds the available bandwidth capacity. Uponcongestion loss, it reduces the window to the halfor to its minimum initial value.

Moreover, TCP was originally designed forwired networks where packet losses occurmostly due to congestion; for that reason, conges-tion avoidance/recovery is the only reaction ofTCP to losses [6]. In fact, while the Bit ErrorRate (BER) varies from 10�6 to 10�8 for wirednetworks, it varies from 10�3 to 10�1 for wirelessones—several orders of magnitude higher [7]. Asa consequence, in wireless networks, TCP reactionto frequent packet losses severely limits the con-gestion window and thus underestimates thecapacity of the networks, leading to non-optimalperformance.

The performance of TCP directly depends onthe window size, which optimal value should beproportional to bandwidth * delay product of theentire path of the data flow [8]. The excess of thisthreshold does not bring any additional perfor-mance enhancement, but only leads to increasedbuffer requirements in intermediate nodes alongthe data connection.

The rest of the paper, being focused on a wire-less multi-hop IEEE 802.11-based network, as-sumes that the reader is familiar with generalaspects of IEEE 802.11 standard [1] as well asmulti-hop routing for wireless LANs [9], which isnot covered by the standard. The reader shouldnote that most achieved results and considerationsremain valid also in more generic scenarios.

At this point, it is necessary to underline theproblems which arise in TCP communicationsover IEEE 802.11 networks.

The authors of [10] produced an evaluation ofTCP performance in wireless multi-hop network,underlining two major problems: instability andunfairness. The observed instability in the perfor-mance is present even in the simplest scenario withonly one data flow over a multi-hop connection.The main reason for that is touching TCP timeouts,which forces TCP to follow the slow start periodgreatly degrading the performance through conges-tion window reduction. The second phenomenonobserved in [10] is unfairness, which happens be-tween two TCP data flows that occupy the samenumber of hops on the same path: the flow startedlater in time will gain full bandwidth advantages,degrading the performance of previous flow downto zero. The unfairness phenomenon mentionedabove is mainly caused by improper tuning ofTCP and link layer retransmission timeouts, multi-ple collisions present on the link layer as well aswell-known IEEE 802.11 MAC unfairness (i.e.the last station is always favored in link accessdue to the employed exponential backoff scheme).


A new metric, called expected throughput, isintroduced in [11] and used as a bound for com-parison of the achieved performance for existingTCP implementations in wireless multi-hop sce-narios. The simulations show that the performanceof TCP, being far from the desired level, is unac-ceptable in several applications. Similar resultsare also presented in [12].

The problem of network congestion existsalmost from the early beginning of the Internet[13]. Nowadays, many researchers underline thatthe problem of congestion is even more criticalnow rather than in 1980s. A relevant theoreticalwork on the topic presented in literature is [14],where Sally Floyd and Kevin Fall highly motivatethe usage of end-to-end congestion control algo-rithms for the design of future protocols, in orderto avoid network collapse due to congestion. Sim-ilar results are obtained by the authors of [39]using a game-theoretic approach.

3. Available solutions

During the past years, a relatively strong effortof the research community was devoted to TCPadaptation to the wireless multi-hop network sce-nario, with the main focus on performance optimi-zation, aimed at enabling uninterrupted networkservice provisioning.

The majority of the available solutions whichmodify congestion control algorithm of TCP canbe logically classified into the three following cate-gories: (1) modifications of TCP based only on theinformation available at the sender node; (2) solu-tions which enhance the previous category byallowing network feedback; and (3) approacheswhich obtain bandwidth * delay information byintroducing measurement techniques at the trans-port layer.

3.1. TCP modifications

One of the first approaches to perform preciseRTT (Round Trip Time) estimation is TCP Vegas[15]. First, TCP Vegas reads and stores inside TCPheader the system clock every time a segment istransmitted. Receiver echoes it back without

performing any modification. Then, upon ACKarrival, the sender uses the stored timestamp forRTT calculation. The congestion avoidance algo-rithm is based on the analysis of the actualthroughput achieved by the flow through its com-parison with expected throughput. The expectedthroughput is calculated using measured RTTvalue and current size of the congestion window.In case the actual throughput is much less than theexpected value, TCP Vegas decreases the size ofthe congestion window assuming that it is sendingmore data than the available network bandwidth.

Another approach presented by authors of [16]introduces congestion window adjustment basedon an end-to-end bandwidth estimation technique.The key idea is in continuous measurements of therate of returning ACKs at the TCP sender side.After congestion occurrence, the source runningTCP Westwood attempts to set a slow start thresh-old and a congestion window on the basis of theeffective bandwidth estimation.

A set of protocols designed for congestionavoidance form the adaptive transport layer(ATL), presented in [17]. ATL consists of twoadaptive transport layer protocols: ATL-TCP forreliable communications and ATL-UDP which isused for multimedia data delivery. The main ideaof this approach is to allow more freedom incongestion window evolution. The dynamicadjustment algorithm assumes to obtain the infor-mation on bandwidth and RTT from the linklayer. However, it is not mentioned in the paperthe way such information could be obtained bythe link layer.

In summary, the solutions within this cate-gory attempt to conquer the roots of the prob-lem. The main problem associated with poorperformance of transport protocols over wirelessnetworks lies in the fact that they are designedfor wired networks—without taking into accountlimitations of the wireless scenario. In order tosolve this problem, the presented solutions redefinetransport protocols, replacing them with versionswhich are designed considering the different char-acteristics of the wired and wireless scenarios.

Obviously, the solutions within this categoryprovide reasonable performance improvement ifcompared with traditional wired implementations


of transport layer protocols. However, the maindisadvantage—which prevents wide deploymentof the proposed approaches—lies exactly in therequirement for modification of a standardizedand widely deployed transport protocol such asTCP. Thus, a huge effort from joined cooperationof industry and standardization committees is re-quired to bring the proposed modification to theend-user.

3.2. Explicit feedback solutions

Data communication over wireless networks isfar from being identified by a simple two-hop sce-nario. The path of data delivery in most cases con-sists of several hops with different capacitycharacteristics. These characteristics include notonly communicational parameters such as avail-able bandwidth and delay, but also parametersassociated with nodes on the data path—theirmemory and computational resources.

Solutions of this category allow network to beaware of pending data transmission between anypair of nodes. The main idea is to allow intermedi-ate nodes on the data path to dynamically informthe sender about the amount of resources availablethrough the entire path. Relying on such feedback,the sender can adjust the amount of data sent onthe network in order to avoid congestionoccurrence.

Random Early Detection (RED) [18] is ascheme which is proposed to deal with networkcongestion through explicit signaling to the sourceabout growing probability of congestion occur-rence. RED is designed to be implemented in inter-mediate routers, where congestion notification isbased on queue monitoring. RED defines two buf-fer occupancy thresholds: low threshold and highthreshold. When the average size of the queuelength exceeds the low threshold, the packets startto be dropped with linear probability, propor-tional to the current average queue length. In casethe average length exceeds the high threshold, allincoming packets are dropped.

Congestion is detected by RED through theanalysis of the actual queue length, comparing itto the predefined low and high threshold values.While operating with a queue size between these

two thresholds, RED informs the sender nodeabout growing probability of congestion occur-rence by marking the incoming packets using aspecially defined bit in the packet header. Beingnotified of the network congestion, TCP sendercan perform congestion avoidance through con-gestion window reduction.

Packet drops performed by RED are designedto the purpose of compliance in operationwith TCP sources which do not support REDframework.

The specification of the way for Explicit Con-gestion Notification (ECN) is presented in [19].The IP layer packets are considered for ECN noti-fication delivery through the ECN bit set. TCPheader is modified as well, in order to support fol-lowing indication of ECN-enabled support of TCPimplementation as well as for ECN communica-tion between TCP sender and receiver.

Another approach which targets the reductionof the mismatch between TCP window and theavailable bandwidth–delay product, called ExplicitWindow Adaptation (EWA), is presented in [20].Similar to RED congestion detection, it is basedon the analysis of available buffer size in edgerouters. EWA attempts to adjust the size of thecongestion window explicitly on the data paththrough modification of receiver�s advertised win-dow field of the packet. This scheme generalizeswindow advertising technique allowing the specifi-cation of available buffer space not only by thereceiver but also by intermediate routers.

Summarizing, solutions presented in this cate-gory implement different explicit feedback tech-niques. All of them rely on the available bufferspace at intermediate nodes, which forces themto depend more on the size of allocated memoryrather than on the available capacity of the com-munication links. Such a tradeoff leads to an in-creased response time to the congestion.

The main reason for congestion occurrence isthe production of more traffic than the availableresources for its delivery over the network. In caseof a connection covering multiple hops of the net-work, data transmission is performed on an hop-by-hop basis: data is stored in the buffer, waiting,while node obtains access to the physical medium.In case the amount of incoming data overcomes


the node�s forwarding capacity, input buffer sizewould grow with a rate which is approximatelyequal to the difference between incoming and out-going data rates. When the buffer is full, the nodestarts to drop incoming packets and congestion isdetected.

For that reason, solutions based on the analysisof buffer free space react to congestion later ifcompared with solutions which analyze the differ-ence between capacities of the incoming and out-going communication links.

3.3. Transport layer capacity measurement

The ideal case for the source node is to havecapacity information of the entire data communi-cation path for the entire duration of the connec-tion. In order to approach to this ideal case,many proposals are targeting an enhancement oftransport layer protocols through capacity prob-ing techniques.

The entire capacity of communication path isrepresented by two parameters: bandwidth anddelay.

Delay associated with an end-to-end connectioncan be easily obtained by TCP through the calcu-lation of the time difference between packet trans-mission and reception of the acknowledgementgenerated by the receiver for such packet. The ob-tained value corresponds to the cumulative delayexperienced in forward and backward directionsof the connection path. However, it is shown thatacknowledgement-based RTT estimation couldperform poor under specific circumstances [21].More accurate RTT estimation is performed whensender includes timestamps into outgoing packets,which are echoed back without any modificationby the receiver. The recommendation for high per-formance extension and finer RTT estimation forTCP protocol is presented in [21].

The second parameter is bandwidth. Differentbandwidth estimation solutions available in litera-ture can be logically divided into passive measure-ments and active probing groups, according to thealgorithm they employ [22]. Passive solutions buildtheir measurements based on the trace history ofan existing data transmission. Such solutions arelimited to the network paths that have recently

been used for communication. On the other hand,active probing provides faster and more accurateestimations, while having the potentiality forexploration of the whole network.

The packet pair mechanism is a reliable tech-nique for bandwidth measurement. The key ideaof the approach is based on the measurement of in-ter-arrival time between two back-to-head packetstransmitted through the entire connection path. Asimple calculation based on inter-arrival delay andpacket size gives the bandwidth of the link. A de-tailed description of packet pair measurementtechnique is presented in [23,24].

The main drawback of packet pair technique isthe dramatic reduction of the estimation accuracyin presence of cross-traffic. CapProbe [25] is a tech-nique which improves packet pair measurementsby filtering only those pairs of the packets whichhave minimal end-to-end delays. This method ex-cludes those packet pairs which are influenced bycross-traffic in intermediate queues.

Summarizing, capacity measurement techniquespresented within this section have obvious draw-backs which prevent their successful deployment:

• They simply do not work under certain circum-stances, such as under presence of cross-trafficwhich is both intensive and non-reactive [25].

• Probing network bandwidth requires an inser-tion of additional traffic, which reduces thealready limited network resources.

• The bandwidth information becomes availableto sender after the time required for a roundtrippropagation of the probe sequence over the net-work path.

• Additional computation resources are requiredfrom the sender for statistical processing ofthe measured data.

4. Cross-layer congestion control over multi-hop

wireless networks

This section presents a novel scheme (Cross-

layer Congestion Control for TCP: C3TCP) forcongestion control over wireless local area net-works where data delivery is performed over mul-tiple wireless hops. To the purpose of explanation

TCP

IPFI

FO

TCP

IP

FIFO

TCP

IP

FIFO

TCP

IP

FIFO

Wireless Medium

N1 N2 N3 N4

Fig. 2. String topology for a multi-hop wireless network.


of the proposed congestion control ideas, we con-sider a string network topology as the simplesttopology which approximates the multi-hopscenario [26]. A four-node example of the stringtopology is presented in Fig. 2.

In our string topology, only neighboring nodescan communicate with each other due to the limi-tations in transmission range. It is assumed thatevery node has an appropriate output FIFO buf-fer, where the link layer packets are queued whilethe wireless medium is busy due to transmissionsof other nodes. Input queuing is omitted for sim-plicity of presentation without any influence onthe results.

The second assumption consists in the availabil-ity of a routing path to every node of the multi-hop network: details related to route discoveryare out of the scope of current paper.

4.1. Bandwidth measurement

Basic medium access mechanism specified byIEEE 802.11 standard is the Carrier Sense Multi-ple Access with Collision Avoidance (CSMA/CA) with binary exponential backoff. The nodeis not allowed to transmit until the medium be-comes free (i.e. no pending transmissions of othernodes). As a result, the whole bandwidth is dividedamong nodes which share the same (wireless)medium.

An optional part of the standard specifies RTS/CTS (Request-To-Send/Clear-To-Send) exchange,which takes place prior transmission at the linklayer of a data frame and its acknowledgement.

This scheme is designed as a solution to the hiddenterminal problem. Consequently, it considerablyreduces data losses caused by collisions.

From the considerations described above, onecan conclude that finally the bandwidth is sharedamong the nodes which are located in the rangeof the sender as well as the receiver nodes.

The available bandwidth B for transmission ofa certain amount of data can be obtained knowingthe size of data D and time T taken for transmis-sion of such data over a specific link:

B ¼ DT

. ð1Þ

The detailed framework for single data packettransmission is presented in Fig. 3. Having datato send at time Tin, the source node initiates themedium access procedure: it senses that mediumis already occupied by another transmission andfalls into exponential backoff with the initial sizeof the backoff window; during the next time ofsensing the medium appears to be free, whichmeans that the source node is allowed to initiatethe transmission with RTS frame for medium res-ervation. Then, after Short Inter-Frame Space(SIFS) the destination node replies with CTSupdating the Network Allocation Vector (NAV)of the nodes which are located within the rangeof the receiver.

At time Tout, the sender initiates data frametransmission onto the physical medium. Uponthe successful reception of the data frame, thedestination node replies with positive acknow-ledgement.

RTS

CTS

Frame

ACK

SIFS SIFS SIFS

SourceNode

DestinationNode

OtherNode

DIFS

Random Backoff

inT outT

Queuing Delay + Medium Access trT

DIFS

Fig. 3. IEEE 802.11 basic medium access mechanism and data delivery procedure.


Taking into account the described data deliveryframework, the time required for the transmissionof a single data packet using CSMA/CA can beobtained as follows:

T ¼ T in � T out þ T tr; ð2Þwhere the difference Tin � Tout includes data queu-ing delay corresponding to the time the node waswaiting for all other nodes to finalize their pendingtransmissions as well as channel to channel accessdelay using random backoff and optional RTS/CTS exchange. A similar way of analysis was firstpresented by Giuseppe Bianchi in his theoreticalmodel for the performance analysis of IEEE802.11 DCF [27].

In order to calculate the time Ttr required fordata frame transmission and its correspondingacknowledgement, it is necessary to take into ac-count the framework employed by the physicallayer.

Data encapsulation performed at both physicaland link layers is presented in Fig. 4. PhysicalLayer Convergence Protocol (PLCP) preamble istransmitted prior any communication betweennodes, for the synchronization of their physicalcircuits. PLCP Header contains signaling informa-tion about the subsequent MAC layer frame, such

PLCPPreamble18 byte

PLCPHeader6 byte

FCS4 byte

Data(0 - 2312 byte)

MACHeader30 byte

Fig. 4. Physical and link layer encapsulation.

as length and bit rate. PLCP preamble and headerare always transmitted at the basic rate, regardlessof the maximum bitrate available on the medium.

The MAC header, being transmitted at the datarate specified in the PLCP header, contains infor-mation about the delivered data on the link layer.FCS field finalizes frame containing CRC informa-tion related to both MAC header and frame body.

According to physical and link layer specifica-tions, the time required for data packet delivery(including the data frame and the correspondingACK) is calculated as follows:

T tr ¼ T data þ SIFSþ T ACK þDIFS; ð3Þ

T data ¼PLCP .Preambleþ PLCP .Header

Basic.Rate

þMAC.Header þ FCSData.Rate

þ DataData.Rate

; ð4Þ

T ACK ¼PLCP .Preamble þ PLCP .Header

Basic.Rate

þ ACK.Header þ FCSData.Rate

; ð5Þ

where DIFS is the Distributed CoordinationFunction Inter-Frame Space.

The time required for a single data frame trans-mission Tdata includes the term which correspondsto physical preamble and header (always fixed sizeand transmitted at the basic rate). For example,for basic rate of 1 Mbps, the time required forthe transmission of physical preamble and headeris equal to 192 ls. This means that the value ofthe first term can be calculated once and thenreused for subsequent calculations.


The second term corresponds to the timerequired for MAC header and CRC information,which could be theoretically transmitted at anyrate supported by the standard. However, sincemost of the rates specified by the standard areobtained from the maximum one through simpleoperations, it is possible to pre-calculate them,for example, by building a short table with valuescalculated for the entire set of possible data ratesfor a given physical layer extension of the standard(a, b or g).

The algorithm for bandwidth measurement isthe following:

1. Store the timestamp Tin for every data arrivedto the link layer for further transmission. Thedata can arrive for forwarding from other nodesor it can be generated locally by upper layers ofthe protocol stack.

2. Prior actual data frame transmission, at timeTout calculate the time taken for packet deliveryincluding queuing and packet transmission timeTtr using Eq. (3).

3. Calculate the bandwidth experienced by thepacket using Eq. (1).

The bandwidth calculated by the presentedalgorithm includes following components: queuingdelay, the time required to gain medium access andthe delay associated with physical and link layerheader transmission. It means that entire overheadwhich occurs before any actual data transmissionover the physical medium is considered to be a fac-tor which reduces the available bandwidth on thelink.

The overhead added at physical and link layersis directly related to the utilization level. For exam-ple, utilization of wired local area networks is rela-tively high (97%) [28] while the utilization ofwireless IEEE 802.11 networks is on low level [29].

4.2. Delay estimation

Transport layer protocols provide end-to-enddata delivery without having any knowledge onthe network structure, like number of hops,parameters of communication link and so on,assuming to have a single data pipe between end

nodes. In order to reach the maximum perfor-mance, transport protocols ideally should fill thedata pipe with its bandwidth–delay product.

Considering the four-node example presented inFig. 2, let us assume that node N1 wishes to com-municate with node N4. The data generated by thetransport layer of node N1 is placed in the outputqueue on the link layer. Then, after node N1 gainsmedium access, the data packet can be transmittedto node N2. Node N2, upon the reception of thedata packet which should be forwarded to the nextnode of the string topology, performs its mediumaccess procedure—during which the packet canbe required to wait in the output queue of nodeN2. Similar procedures are performed by the nodeN3 as well, before the data reach the destinationnode N4.

Finally, in our multi-hop scenario, queuing de-lay is present on all the nodes except the destinationnode. Such queuing delay does not correspond tothe length of data pipe between end nodes N1and N4. On the contrary, the length of this pipeconsists only of the time required for actual datatransmission at the physical layer through all thelinks along the communication path.

Most solutions for optimization of the TCPperformance through congestion window adjust-ment (presented in Section 3) rely on RTT as adelay measurement parameter. Such a way ofdelay measurements approximates forward andbackward links within a single data pipe.

However, TCP assigns different communica-tional purposes to links in forward and backwarddirections. Thus, forward direction is used fortransfer of application payload while the back-ward direction serves for the functionality of theTCP acknowledgement scheme.

In the proposed delay estimation technique wedifferentiate between forward and backward de-lays. Forward delay contains the length of the datapipe between sender and receiver nodes whilebackward delay measures the time required forthe delivery of TCP ACK packets.

1. Forward delay. According to the consider-ations described above, the single-hop forwarddelay experienced by a data burst includes channelaccess delay, time required for data delivery on thephysical layer including related physical and link


layer overhead, but excluding link layer queuingdelay.

Forward delay is calculated using (2) setting Tin

to be equal to the time the packet leaves the queuepreparing for actual transmission on the link layer.Such estimation avoids the insertion of link layerqueuing delay into the Tin � Tout component.

Most of the transport layer measurement tech-niques include also queuing delay along the entirepath experienced by the data packet at the link andIP layers: the end-to-end data pipe is consideredartificially longer than it actually is. In otherwords, a simple insertion of an additional trafficincreases the bandwidth–delay product throughan increased measured delay. However, the band-width–delay product should be decreased in thissituation through reduction of the available band-width component while leaving forward delayunaffected.

Considerations described above bring advan-tages for link layer per-hop delay estimationif compared with end-to-end transport layermeasurements.

2. Backward delay. The reliability of TCP isachieved through implementation of a positiveacknowledgement scheme. The receiver acknowl-edges successful data delivery with TCP ACKpackets going back towards the sender.

On contrary with forward delay measurementtechnique described above, TCP ACK delay doesinclude both transmission and queuing delays,i.e. it is equal to the difference between the timethe TCP ACK packet was generated by the recei-ver node and its reception by the TCP sender.Backward path delay on each single link is calcu-lated using (2).

The proposed method for estimation of thedelay in forward and backward directions allowsthe TCP sender to adjust the amount of outstand-ing data to the bandwidth–delay product in theforward path, while considering the backwardpath as a simple delay line for TCP acknowledge-ment reception.

4.3. ‘‘Options’’ support for IEEE 802.11

The previous two sections describe techniquesfor available bandwidth and delivery delay mea-

surements at the link layer. Such measurementsare performed by wireless stations and correspondto the neighboring links which in fact constitute asingle shared medium the nodes belong to.

Wireless multi-hop networks perform datacommunication over several short-range links.An evaluation of the capacity experienced by a cer-tain data packet can be obtained by the analysis ofcapacity of the individual links: the end-to-endbandwidth Bend-to-end over an n-hop path is equalto the bandwidth of the bottleneck on the path,while the end-to-end delay Dend-to-end is obtainedby the superposition of delays Di introduced byindividual links

Bend-to-end ¼ minðB1;B2; . . . ;BnÞ; ð6Þ

Dend-to-end ¼Xn

i¼1

Di. ð7Þ

The obtained values for end-to-end bandwidthand delay should be forwarded to the source pro-ducing traffic to let it implement congestion controlbased on performed measurements. In order tosupport such functionality, we propose to extendIEEE 802.11 MAC protocol by allowing the speci-fication of optional fields inside the MAC header.

Optimization of IEEE 802.11 link layer is a hottopic. Huge amount of optimization solutions areproposed by the research community which intro-duce an enhanced signaling for optimization of thelink layer performance. In most cases, enhancedsignaling requires the modification of the stan-dardized MAC protocol or the specification ofan additional protocol. Indeed, research workcontinues to go on after the specification of aparticular protocol has taken place. Many novelapproaches and optimization solutions appearwhich cannot be easily applied to the existing spec-ification. The idea to include an universal way forinserting additional information has touched mostimportant protocol specifications nowadays. Thus,IPv4 [30], IPv6 [31], TCP [2] specifications containthe support of optional fields.

The proposed modifications are aimed at en-abling optional support within the IEEE 802.11MAC header (Fig. 5).

‘‘Options’’ is a variable length field whichextends standard MAC header. It consists of

FrameControl

Duration/ID

Address 1 Address 2 Address 3SequenceControl

Address 4FrameBody

FCSOptions

HeaderLength

Option 1 Option 2 ... Option N

OptionType

OptionLength

OptionData

MAC Header

2Octets: 2 6 6 6 62 Variable 0 - 2312 4

Fig. 5. ‘‘Options’’-enabled IEEE 802.11 data frame.


‘‘Header Length’’ field which specifies the entirelength of the MAC header, including the list ofoptions. The length of the header is required toperform separation of the data encapsulated intothe frame from the MAC header.

Each option consists of option type, length inoctets and data. Length is required to handle thecase when a node does not support the corre-sponding option. The knowledge of the option�slength makes skipping the current option easier,jumping to the next one for processing.

Current wireless devices do not support op-tional fields within the MAC layer header. In orderto provide backward support within the existingIEEE 802.11 standard specification a new type ofpacket is introduced, since an options-enableddata frame should be of a different type with re-spect to a normal data frame. For that purpose,one of the reserved types in the Frame Controlfield of the MAC header of data frames can beused. For example, the type equal to �10� can beused for data transmission, while the subtype�1000� indicates options-enabled data frame.

Backward compatibility with standard IEEE802.11 devices also requires the specification ofcommunication of options-enabled nodes withthose which implement standard MAC. In caseoptions-enabled node wishes to communicate withanother node, it should first try to establish com-munication using the new options-enabled dataframe. If the destination node does not supportthe new type of data frame, it will just simply dropthe received frame. The sender node will detect theframe loss through the lack of positive acknowl-

edgement from the receiver after timeout occur-rence, which is equal to SIFS + ACKtransmission time. The second time the sendernode should use standard data frames to commu-nicate with such node.

It could happen that the first communicationusing options-enabled frames could be unsuccess-ful because of information corruption during datadelivery in the channel. For that reason, the sendernode should periodically attempt to communicateusing new types of frames.

The presented backward compatibility tech-nique is easy to implement, however it is not opti-mal in the sense that the sender node needs toprobe the destination. These probes could beunsuccessful in case the destination does not sup-port MAC-layer options, producing additionaloverhead which reduces the bandwidth utilizationand increases the packet delivery delay. In orderto avoid such additional overhead, the informa-tion about options-enabled capability could beencapsulated into route discovery protocol allow-ing nodes to have knowledge about which typeof frame to use in advance.

Options-enabled data frames should not beused in case the node does not transmit anyoptions inside the header.

4.4. The proposed approach: C3TCP

Fig. 6 presents an example of TCP communica-tion over a 3-hop wireless network. Sender nodeN1 initiates the transmission by sending a TCPdata packet to node N4 over the string topology.

N1 N2 N3 N4

TCPSender

TCPReceiver

TCP DataMAC Header

TCP ACKMAC Header

L1 L2 L3

Fig. 6. C3TCP usage scenario: TCP connection over 3-hopwireless network.


Upon reception of the TCP data packet, the linklayer of node N1 performs bandwidth and delaymeasurements for link L1. Then, it includes themeasured information into the correspondingoptional fields inside the MAC header. Node N2,after the reception of the data frame from nodeN1, performs the same measurements for linkL2. Then, it takes the minimal value for the mea-sured bandwidth of links L1 and L2 and updatesthe bandwidth option in the MAC header. Delayexperienced by the data on the link L2 is summedwith the delay on the link L1.

When the TCP data packet reaches the destina-tion node N4, its MAC header contains bandwidthand delay experienced by the packet on the paththrough links L1–L2–L3. TCP receiver in N4 re-plies with TCP ACK back to the sender indicatingsuccessful data packet reception. This TCP ACKis also encapsulated by link and physical layerheaders, including the bandwidth–delay informa-tion obtained by N4 during TCP data packetreception. Such information is simply echoed backusing the appropriate optional fields.

Upon the reception of the TCP ACK packet,sender node N1 will have the bandwidth and thedelay for both transmitted TCP data and TCPACK packets. Based on the obtained information,the sender can adjust the outgoing traffic using cal-culated bandwidth–delay product. The bandwidthis taken only from TCP data packet propagatingin forward direction, while the delay is obtainedas a sum of propagation delays of TCP data andTCP ACK packets.

The goal of the presented approach is to avoidany changes at the transport layer of the protocolstack. For that reason, an additional module,called congestion control module (CCM), isinserted below the transport layer. This module

cooperates with the link layer providing conges-tion control information for the transport layer,using a cross-layer collaboration technique. Theimplementation of cross-layer signaling is out ofthe scope of current paper, however a detaileddescription of existing approaches is provided byauthors of [32].

General architecture of C3TCP and position ofCCM within the protocol stack are specified inFig. 7. CCM has different functionalities depend-ing whether it is implemented at the sender or atthe receiver node.

At the receiver�s side, upon the reception of apacket, CCM requests from the link layer thebandwidth and the delay which have been deliv-ered with the TCP data packet. Having access toTCP headers, CCM traces the outgoing TCPACKs. In case the produced TCP ACK acknow-ledges the received TCP data packet, CCMforwards the request to the link layer in order toinclude the stored bandwidth–delay informationinto MAC-layer header of the outgoing TCPACK.

Modern implementations of TCP supportcumulative or selective acknowledgements, whichlead to the generation of one TCP ACK packetper several TCP data packets received. In this case,CCM will include forward path measurement ob-tained from the last data packet acknowledgedby the outgoing TCP ACK.

At the sender�s side, CCM requests end-to-endmeasurements from the link layer upon TCPACK packet reception. Then, it calculates the de-sired size of the congestion window based on theon the forward path bandwidth and RTT valueson the forward path.

TCP specification includes receiver advertisedwindow function, which main idea is to allow thereceiver to specify (in the TCP ACK header) thedesired congestion window size. In current imple-mentations of TCP, this parameter includes unoc-cupied buffer space left on the receiver.

CCM uses the receiver advertised window(RWND) field of TCP ACK packet for the deliv-ery of the calculated congestion window. In detail,it leaves the lower cwnd value between the calcu-lated one and the one reported by the receiver.Producing congestion control through the correc-

TCP Layer TCP Layer

Congestion Control Module (CCM)

Link Layer

Congestion Control Module(CCM)

Link Layer

Physical Medium

Cross-layerInterface

TCP ACKPacket

End-to-endMeasurements

TCP ACK(RWND Adjusted)

Cross-layerInterface

Forward PathMeasurements

TCP ACK

Sequence Number Analysis

IncludeForward PathMeasurements

TCP ACK

TxRxTx Rx

Sender Receiver

Fig. 7. Congestion control module (CCM) architecture and its position within the protocol stack of C3TCP-enabled nodes.

N1 N2 N3 N4

N6

N7

N5

Tx Ran

ge

Flow F1 - src node N1dst node N5



Fig. 8. Multi-flow communications between different nodes ofa multi-hop network.


tion of receiver�s advertised window is not a novelapproach, on the contrary it is a common tech-nique for the congestion window adjustment—pre-sented in many works. For example, the authors of[20] use RWND field of TCP header to inform thesender about network congestion from intermedi-ate routers based on the free buffer space left onthe edge device.

RWND signaling adjusts TCP window limitingits upper bound of evolution. In order gain fullcontrol on the size of the window, CCM shouldbe enabled with acknowledgement generation forthe local TCP layer in order to control the behav-iour of TCP congestion control algorithm.

4.5. Multi-node multi-flow scenario

In previous paragraphs, congestion control wasmostly focused on the simple single-flow example.However, wireless multi-hop networks are aimedat supporting more complex scenarios, where dif-ferent nodes initiate transmission of multiple dataflows.

Fig. 8 presents a three-flow example of multi-hop communications. Flow F1 shares a part ofthe data path with flow F2. Flow F3 will also influ-ence flows F1 and F2, since the destination nodeN6 shares the same medium with nodes N2, N3


and N4. It is assumed that all nodes use RTS/CTSframework in order to solve the hidden nodeproblem.

Obviously, the bottleneck shared by all threeconnections is located at node N3. For that rea-son, the measured bandwidth between nodes N7and N6 will contain the portion of bandwidth usedby flow F3.

Flows F1 and F2 are the flows produced by thesame sender node N1. This makes the measuredbandwidth equal to the portion of bandwidthjointly occupied by both of them. For that reason,it is not possible to adjust contention windowswithout performing per-flow differentiation. How-ever, per-flow differentiation can be supported bythe C3TCP framework.

The general structure of a possible flow-differen-tiation module is presented in Fig. 9. The purposeof the Packet Classifier is to differentiate incomingpackets according to the data flow they belong to.Then, the transmission scheduler allocates forevery flow an appropriate portion of the availablebandwidth to the node. The implementation ofscheduling algorithm could be simple or containfairness and Quality of Service (QoS) support.

4.6. Routing

A multi-hop IEEE 802.11-based wireless net-work is a self-organizing network, where nodesshould perform route discovery in order to knowthe path or at least the next hop of the data com-munication path.

Bandwidth Allocation /Transmission Scheduler

Flow1

Link LayerTransmission

Packet Classifier

Flow2

FlowN

. . .

AvailableBandwidth

Fig. 9. Flow differentiation for congestion control in theC3TCP framework.

IEEE 802.11 standard does not specify anyrouting protocol, relying on a simple scenariowhere all the nodes are located within transmissionrange of each other. In order to adapt wireless net-works to multi-hop scenarios, a growing amountof proposals gave birth to many routing protocolsoptimized for the wireless environment.

The existing routing protocols are categorizedinto two major groups: on-demand and proactive.On-demand protocols perform route discovery inthe moment of the need for communication, forexample AODV [33] and DSR [34]. Proactiveapproaches like DSDV [35], on the contrary, tryto avoid the delay overhead added by initial routediscovery keeping the table with routes� descrip-tion, updated at regular intervals.

However, the main aspect of routing is the met-ric which is chosen for route selection. Traditionalrouting protocols rely on shortest path routing,which brings performance optimization in wirednetworks through improvement in data deliverydelay as well as bandwidth utilization. Wirelessnetworks have an additional set of parameterswhich should be taken into account to make aproper choice. Such parameters include energyconstrains, error rate, reliability of links, mobilityand available throughput level.

The importance of the last metric is underlinedin [36], where the authors introduce an alternativemetric for route selection which is called MediumTime Metric (MTM). MTM assigns a weight toeach route that is proportional to the time takenfor packet delivery over that particular route.

As an extension of MTM metric, we propose todifferentiate different routes according to theirbandwidth–delay product. Dynamical update ofthe weight of the routes can be produced basedon the values measured with existing data flows ofthe nodes. Such a way of updating does not producean additional overhead, in opposite to the case ofrouting protocol update—leading to an improvedefficiency in the utilization of network capacity.

5. Performance evaluation

The performance of the proposed solution isanalyzed using the ns-2 network simulator [37].

Table 1Simulation parameters

Parameter name Value

Slot 20 lsSIFS 10 lsDIFS 50 lsPLCP preamble + header 192 lsData rate 11 MbpsBasic data rate 1 MbpsPropagation model Two-ray ground


C3TCP evaluation is performed using two scenar-ios: the first scenario is used to evaluate thestep-by-step operation of C3TCP—showing goodagreement with the design objectives, while the sec-ond scenario is more complex and better approxi-mates the reality of ad hoc multi-hop networkcommunications.

5.1. String topology

The first simulation scenario consists of fournodes involved in a single TCP connection andtwo nodes which produce cross-traffic UDP pack-ets (Fig. 10). Node N1 is attached to a TCP agent,while TCP sink is located at the node N4. TCPpackets are routed through the intermediate nodesN2 and N3 up to the destination node N4. Due totransmission range limitations, cross-traffic streamshares the same medium with TCP flow only at thelink between nodes N3–N4. Each station�s trans-mitting range is limited to 22.5 m, and the distancebetween each pair of nodes in the simulation sce-nario is equal to 20 m.

Congestion control module (CCM) is attachedat the link layer of end nodes of the TCP connec-tion. At the sender size (node N1), CCM dynami-cally adjusts TCP congestion window specifying itsdesired size by the RWND field of TCP header.

Simulation parameters are set to satisfy theIEEE 802.11b specification of the standard [1] atboth physical and link layers, and briefly summa-rized in Table 1. In order to reduce collisions,RTS/CTS exchange is employed.

N1 N2 N3 N4

20 m

TCP Flow

Cross-Traffic (UDP flow) N5 N6

TCP Agent TCP Sink

UDP Agent UDP Sink

UDP Flow

TCP Flow

20m

Fig. 10. C3TCP evaluation: Scenario 1.

TCP flow is started after 3.0 s of the simulation,being initially the only traffic in the network.Cross-traffic produced by node N5 is present onlyin the interval between 15.0 and 30.0 s ofsimulation.

In order to evaluate the accuracy of bandwidthmeasurements provided by the presented tech-nique, the difference between calculated bandwidthand the one obtained at the link level is presentedin Fig. 11. The dashed curve corresponds to theavailable bandwidth on the link, which is calcu-lated without taking into account exponentialbackoff performed by the nodes as well as in ab-sence of collisions. The results show good approx-imation achieved by measurements in both cases:with and without cross-traffic.

Another important parameter for TCP perfor-mance is the RTT. Fig. 12 presents a comparisonbetween RTT measured at the link level againsttransport layer measurements. RTT measurementsat the transport layer are performed using time-stamp options specified in [21].

Transport layer is not aware about the mediumit operates on. For that reason, it is not possible

00.10.20.30.40.50.60.70.80.9

0 5 10 15 20 25 30 35 40 45

Simulation time (sec)

Ban

dwid

th (

Mbp

s)

Available

Measured

Fig. 11. Accuracy of C3TCP bandwidth measurement.


00.10.20.30.40.50.60.70.80.9

0 5 10 15 20 25 30 35 40 45

Thr

ough

put (

Mpb

s)

StandardTCP

C3TCP

Fig. 13. Throughput of C3TCP against standard TCP imple-mentation.


0.01

0.02

0.03

0.04

0.05

0 5 10 15 20 25 30 35 40 45

RT

T (m

sec)

Link Layer

Transport Layer

Fig. 12. C3TCP RTT measurements against standard TCPmeasurements.


for standard TCP to differentiate between queue-ing and transmission delay, as both of them are in-cluded into the obtained RTT value.

In case TCP continuously outputs two datapackets, the last will stay in buffer waiting forthe transmission of the first one. This results inan artificial increase of the RTT delay by a timeinterval equal to the transmission delay of the firstpacket over the wireless link. Such situation leadsto overestimate the length of available data pipe,which results in an unnecessary increase of theTCP congestion window.

In opposite to transport measurements, linklayer measurements avoid including queuing delayinto the measured round trip delay value. How-ever, delay variation is still present due to the dif-ference in medium access time as a consequence ofcollisions and random backoff. The jitter ofthe link layer curve which corresponds to singleTCP flow measurements mostly reflect variationsdue to exponential backoff. In the presence ofcross-traffic (from 15.0 to 30.0 s), the average ofRTT measured values is increased mostly due tocollisions.

Results presented in Fig. 12 underline the bene-fits obtained from the C3TCP link layer measure-ments if compared with those performed at thetransport layer, providing good confirmation ofthe theoretical advantages of link layer measure-ments described in Section 4.

The major metric for evaluating the perfor-mance of TCP flows is the obtained end-to-endthroughput. The throughput comparison between

TCP version with cross-layer congestion control(C3TCP) and standard TCP implementation [2] ispresented in Fig. 13.

Results underline stability of throughput in thecase of C3TCP during all the phases of the exper-iment. The classical implementation of congestioncontrol, on the opposite, always tries to enlarge thewindow, periodically incurring into congestion.

In more details, in case TCP flow is the onlytraffic present in network, C3TCP throughput iscomparable with one obtained by standard TCPimplementation, with less jitter. However, whencross-traffic is present (from 15.0 to 30.0 s), stan-dard TCP flow periodically drops throughput to0, while C3TCP always keeps the throughput levelclose to the available bandwidth—showing goodutilization of the link capacity.

The bottleneck on the TCP communicationpath in the evaluation scenario presented inFig. 10 is the link between nodes N2 and N3. NodeN5 produces cross-traffic, generating RTS forobtaining medium access which is heard by nodeN3 but not by node N2. As a result, node N2 doesnot receive any response while trying to communi-cate with the node N3. The communication be-tween nodes N1 and N2 is still possible, sincenone of them is aware of the cross-traffic andcross-traffic flow does not collide with transmis-sions of such nodes. The only assumption whichis made is that signals transmitted by the nodesdo not collide outside effective transmission range(22.5 m). This comes from the implementationdetails of IEEE 802.11 MAC inside ns-2simulator.


Que

ue s

ize

(pac

kets

)

02468

101214161820

0 5 10 15 20 25 30 35 40 45

Fig. 15. Buffer utilization at node N2 for C3TCP.


The TCP source attached to node N1 deliversdata packets to node N2 utilizing full bandwidthof the link between nodes N1 and N2. Then, nodeN2 can forward the received packets to node N3only after node N5 finalizes its pending transmis-sion. The difference between incoming and outgo-ing data rates observed by node N2 results inmultiple buffer overflows, which finally causeTCP throughput reduction.

Packets dropped from the buffer of intermediaterouters are partially transported to the destination.It is demonstrated that multiple drops of suchpackets could lead to networks collapse [14]. Inorder to evaluate buffer usage as well as for betterunderstanding the advantages of C3TCP, bufferutilization at the bottleneck node N2 is measured.The evaluated buffer is limited in size—allowing anallocation of up to 20 packets, which is about 5times greater than the entire link capacity (using1 K TCP data packets). The obtained results arepresented in Fig. 14 for standard TCP and inFig. 15 for C3TCP.

Buffer usage of standard TCP flow is relativelylow (less than 5 packets) when the incoming andoutgoing data rates present on node N2 are com-parable. However, in presence of cross-traffic,standard TCP source produces much more pack-ets, overloading the bottleneck link. Such situationleads to buffer overflow and consequently multiplepacket drops in the interval between 15.0 and30.0 s.

On the contrary, knowledge of the capacity ofthe communication path greatly reduces bufferusage for C3TCP if compared with standard TCP

0

2

4

6

8

10

12

14

16

18

20

0 5 10 15 20 25 30 35 40 45


Que

ue s

ize

(pac

kets

)

Fig. 14. Buffer utilization at node N2 for standard TCP.

implementation. Thus, buffer in node N2 doesnot exceed the value of 10 packets in presence ofcross-traffic and it is fixed in the interval between0 and 3 packets when C3TCP manages the onlyflow in the network. As a consequence, C3TCPscheme does not produce more packets than thenetwork can transport, saving communication re-sources and avoiding multiple packet drops alongthe communication path.

Standard TCP was chosen for the comparisonas the most wide-spread TCP implementation, inorder to underline the obtained performanceimprovement. However, an additional comparisonwith other approaches which aim at optimizingTCP congestion control framework is providedin the following.

TCP Vegas [15] and TCP Westwood [16] arechosen among those congestion control solutionswhich most closely approximate C3TCP from thetheoretical point of view. The model of TCP Vegasis taken from standard ns-2 distribution, whileTCP Westwood model is obtained from [38].

Throughput comparison results are presented inFigs. 16 and 17 for TCP Vegas and TCP West-wood respectively.

The results show that all the evaluated ap-proaches achieve relatively close (with differenceless than 2%) throughput in the scenario whenTCP flow is not affected by cross-traffic (from 3.0to 15.0 and from 30.0 to 45.0 s of simulation).

However, when cross-traffic is present (between15.0 and 30.0 s of simulation), both TCP Vegasand TCP Westwood periodically drop theirthroughput down to zero due to overestimationof the link capacity. For clarity of presentation,

00.10.20.30.40.50.60.70.80.9

0 5 10 15 20 25 30 35 40 45Simulation time (sec)

Thr

ough

put (

Mbp

s)

Westwood

C3TCP

Fig. 17. Throughput of C3TCP against TCP-Westwood imple-mentation.


Thr

ough

put (

Mbp

s)

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

15 20 25 30

Westwood

C3TCP

Fig. 19. Throughput of C3TCP against TCP-Westwood imple-mentation (zoomed).


00.10.20.30.4

0.50.60.70.80.9

0 5 10 15 20 25 30 35 40 45

Thr

ough

put (

Mbp

s)

TCP-Vegas

C3TCP

Fig. 16. Throughput of C3TCP against TCP-Vegas imple-mentation.


zoomed portions of the graphs are presented inFigs. 18 and 19. In the considered scenario, TCPVegas performs better than TCP Westwood. Themain reason for that is that TCP Vegas performscomparison between the estimated capacity andthe actually achieved throughput. Based of such


Thr

ough

put (

Mbp

s)

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

15 20 25 30

TCP-Vegas

C3TCP

Fig. 18. Throughput of C3TCP against TCP-Vegas implemen-tation (zoomed).

comparison TCP Vegas does not increase conges-tion windows if this does not lead to a throughputincrease. As a result, the more conservative TCPVegas performs better than TCP Westwood.

The throughput of C3TCP is stable for the en-tire simulation interval, showing good approxima-tion of the available link capacity. The performedcomparison underlines the advantages of the net-work capacity measurement at the link level ratherthan at the transport level.

For the purpose of quantitative comparison, re-sults show an improvement achieved by C3TCP ofaround 27%, 18% and 7% against standard TCP,TCP Westwood, and TCP Vegas, respectively.

5.2. Grid topology

The results presented in Scenario 1 show goodagreement with the design principles of C3TCP.However, the simplicity of the scenario does notguarantee similar behavior in the general case ofoperation in a complex ad hoc multi-hop network.

In order to approach a more realistic case, Sce-nario 2 specifies a flat-grid topology, consisting of20 nodes, as shown in Fig. 20. The size of the cellin the grid of 20 m—allowing communication onlybetween neighboring nodes (connected by adashed line).

TCP agent attached to node 10 and TCP Sinkattached to node 14 create a ‘‘long’’ four-hopsTCP flow, while a ‘‘short’’ two-hops flow is initi-ated between nodes 5 and 17. As a result, the firsttwo hops utilized by the ‘‘long’’ flow are sharedwith the ‘‘short’’ TCP flow.

0 1 2 3 4

5 6 7 8 9

10 14

15 16 17 18 19

TCP Agent 1 TCP Sink 1

TCP Sink 2

UDP Agent

UDP Sink

12 13

TCP Agent 2

11

20 m

20m

Fig. 20. C3TCP evaluation: Scenario 2.


UDP agent and sink, attached to the nodes 8and 4 respectively, generate a constant-bitratecross-traffic flow—which impacts on the ‘‘long’’TCP flow but not the ‘‘short’’ one.

Simulations are run for 100 s. UninterruptedTCP traffic flows are started at the beginning ofsimulation, while the cross-traffic UDP flow is ac-tive only in the interval between 30 and 70 s of sim-ulation time. Other simulation parameters as wellas configuration of network simulator are fullyconsistent with those described in Scenario 1.

Obtained simulation results are presented inFig. 21 for standard TCP, TCP Westwood, TCPVegas and proposed C3TCP implementations.Within the entire simulation time, standard TCPimplementation (see Fig. 21a) continuously triesto increase congestion window on relatively lowcapacity links. As a result, due to multiple conges-tion-related packet losses and TCP timeout expira-tions, the throughput of both flows shows highfluctuations. The ‘‘short’’ TCP flow gets slightlyhigher average of 0.4 Mbps, if compared with0.33 Mbps obtained by the ‘‘long’’ flow.

A similar behavior to standard TCP but withlower level of fluctuations is observed for TCPWestwood (see Fig. 21b). Both flows are continu-

ously trying to get full available bandwidth oneover another. Periodic throughput reduction pres-ent on the graph derives from bandwidth overesti-mation, caused mainly by the employed type ofTCP Westwood ACK filter. However, the large-scale sharing of bandwidth by TCP Westwoodflows is relatively fair with an average throughputof 0.4 Mbps per data flow.

Much more stable behavior is observed withTCP Vegas flows (see Fig. 21c). The presented re-sults show relatively large unfairness in sharing theavailable bandwidth: the ‘‘short’’ flow alwaysshow better throughput if compared with the‘‘long’’ one. Additionally, in presence of con-stant-bitrate UDP traffic, the throughput of the‘‘long’’ flow is dramatically decreased (down tozero).

Fig. 21d shows the results obtained with theproposed C3TCP scheme. While not being dis-turbed by cross-traffic, both flows share the avail-able bandwidth equally—keeping their averagethroughput at 0.45 Mbps. In the interval between30.0 and 70.0 s of simulation time, the cross-trafficUDP flow is starting to take a part of the band-width from the ‘‘long’’ flow. As a result, thethroughput of the ‘‘short’’ flow is increased with

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 20 40 60 80 100


0 20 40 60 80 100


0 20 40 60 80 100


0 20 40 60 80 100


Thr

ough

put (

Mbp

s)T

hrou

ghpu

t (M

bps)

Thr

ough

put (

Mbp

s)T

hrou

ghpu

t (M

bps)

"long" flow"short" flow




0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

(a) (b)

(c) (d)

Fig. 21. Simulation throughput results for data flows of (a) Standard TCP (b) TCP-Westwood (c) TCP Vegas, and (d) C3TCPimplementations.


the portion of the bandwidth temporarily releasedby the ‘‘long’’ flow.

6. Conclusion

The paper presents the problem of performancedegradation of transport layer protocols due tocongestion in wireless multi-hop local area net-works. Following the analysis of available solu-tions to this problem, a cross-layer congestionavoidance scheme (C3TCP) is presented, able toobtain higher performance by gathering capacityinformation such as bandwidth and delay at thelink layer. The method requires the introductionof an additional module within the protocol stackof the mobile node, able to adjust the outgoingdata stream based on capacity measurements. Anadditional contribution of the paper is a proposalto provide optional field support to existing IEEE802.11 protocol, in order to support the presented

congestion control solution as well as many othersimilar approaches.

Achieved results underline good agreement withdesign considerations and high utilization of theavailable resources. Ongoing work is oriented to acomprehensive evaluation of the presented conges-tion control technique and a possible proposal toIEEE 802.11 working group to include the supportof optional fields into next releases of the standard.

References

[1] Wireless LAN medium access control (MAC) and physicallayer (PHY) specifications, IEEE 802.11 standard, 1997.

[2] J. Postel, Transmission control protocol, Request forComment RFC 793, September 1981.

[3] G. Miller, K. Thompson, R. Wilder, Wide-area Internettraffic patterns and characteristics, IEEE Network(November/December) (1997) 10–23.

[4] N. Brownlee, K. Claffy, Understanding Internet trafficstreams: Dragonflies and tortoises, IEEE CommunicationMagazine 40 (October) (2002) 110–117.


[5] V. Jacobson, Congestion avoidance and control, ComputerCommunication Review 18 (4) (1988) 314–329.

[6] W. Stevens, TCP Slow Start, Congestion Avoidance, FastRetransmit, and Fast Recovery Algorithms, Request forComment RFC 2001, January 1997.

[7] K. Pentikousis, TCP in wired-cum-wireless, IEEE Com-munications Surveys (2000).

[8] R. Wang, G. Pau, K. Yamada, M.Y. Sanadidi, M. Gerla,TCP startup performance in large bandwidth delay net-works, in: Twenty-third Annual Joint Conference of theIEEE Computer and Communications Societies (INFO-COM 2004), vol. 2, March 2004, pp. 796–805.

[9] J. Broch, D. Maltz, D. Johnson, Y. Hu, J. Jetcheva, Aperformance comparison of multi-hop wireless ad hocnetwork routing protocols, in: Fourth Annual Interna-tional Conference on Mobile Computing and Networking(MobiCom�98), ACM, Dallas, TX, October 1998.

[10] S. Xu, T. Saadawi, Does the IEEE 802.11 MAC protocolwork well in multihop wireless ad hoc networks? IEEECommunications Magazine 39 (June) (2001) 130–137.

[11] G. Holland, N. Vaidya, Analysis of TCP performance overmobile ad hoc networks, Wireless Networks 8 (March)(2002) 275–288.

[12] Z. Fu, X. Meng, S. Lu, How bad TCP can perform in mobilead hoc networks, in: Seventh International Symposiumon Computers and Communications (ISCC), July 2002.

[13] J. Nagle, Congestion control in IP/TCP internetworks,Request for Comment RFC 896, Internet EngineeringTask Force, January 1984.

[14] S. Floyd, K. Fall, Promoting the use of end-to-endcongestion control in the Internet, IEEE/ACM Transac-tions on Networking 7 (August) (1999) 458–472.

[15] L. Brakmo, L. Peterson, TCP Vegas: end to end congestionavoidance on a global Internet, Computer CommunicationReview 25 (October) (1995) 69–86.

[16] C. Casetti, M. Gerla, S. Mascolo, M. Sansadidi, R. Wang,TCP Westwood: end-to-end congestion control for wired/wireless networks, Wireless Networks Journal 8 (2002)467–479.

[17] O. Akan, I. Akyildiz, ATL: an adaptive transport layersuite for next-generation wireless Internet, IEEE Journalon Selected Areas in Communications 22 (June) (2004)802–817.

[18] S. Floyd, V. Jacobson, Random Early Detection gatewaysfor congestion control for high speed data networks, IEEE/ACM Transactions on Networking 1 (4) (1993) 397–413.

[19] K. Ramakrishnan, S. Floyd, D. Black, The Addition ofExplicit Congestion Notification (ECN) to IP, Request forComments (RFC), September 2001.

[20] L. Kalampoukas, A. Varma, K. Ramakrishnan, Explicitwindow adaptation: a method to improve TCP perfor-mance, Infocom, April 1998.

[21] V. Jacobson, R. Braden, D. Borman, TCP Extensions forHigh Performance, Request for Comment RFC 1323, May1992.

[22] H. Ningning, P. Steenkiste, Evaluation and characteriza-tion of available bandwidth probing techniques, IEEE

Journal on Selected Areas in Communications (JSAC) 21(6) (2003) 879–894.

[23] K. Lai, M. Baker, Nettimer: a tool for measuring bottle-neck link bandwidth, USENIX Symposium Internet Tech-nologies and Systems, March 2001.

[24] C. Dovrolis, P. Ramanathan, D. Moore, What do packetdispersion techniques measure? IEEE INFOCOM (April)(2001).

[25] R. Kapoor, L. Chen, M. Sanadidi, M. Gerla, CapProbe: asimple and accurate technique to measure path capacity,Technical Report TR040001, UCLA SCD, 2004.

[26] M. Gerla, R. Bagrodia, Z. Lixia, K. Tang, W. Lan, TCPover wireless multi-hop protocols: simulation and experi-ments, in: IEEE International Conference on Communi-cations (ICC), June 1999.

[27] G. Bianchi, Performance analysis of the IEEE 802.11distributed coordination function, IEEE Journal onSelected Areas in Communications (JSAC) 18 (March)(2000) 535–547.

[28] D. Boggs, J. Mogul, C. Kent, Measured capacity of anethernet: myths and reality, Computer CommunicationReviews 18 (August) (1988) 222–234.

[29] D. Kliazovich, F. Granelli, Performance improvements indata transfer over 802.11 WLANs, in: 10th IEEE Work-shop on Computer-Aided Modeling, Analysis, and Designof Communication Links and Networks, CAMAD�04,Dallas, November 2004.

[30] J. Postel, Internet Protocol: DARPA Internet ProgramProtocol Specification, Request for Comment RFC 791,September 1981.

[31] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6)Specification, Request for Comment RFC 2460, December1998.

[32] Q. Wang, M.A. Abu-Rgheff, Cross-layer signalling fornext-generation wireless systems, in: WCNC 2003, vol. 2,March 2003, pp. 1084–1089.

[33] C. Perkins, E. Royer, Ad hoc on-demand distance vectorrouting, in: Proceedings of the 2nd IEEE Workshop onMobile Computing Systems and Applications, NewOrleans, LA, February 1999, pp. 90–100.

[34] D. Johnson, D. Maltz, J. Broch, DSR: the dynamic sourcerouting protocol for multi-hop wireless ad hoc networks,in: C. Perkins (Ed.), Ad Hoc Networking, Addison-Wesley,2001, pp. 139–172 (Chapter 5).

[35] C. Perkins, P. Bhagwat, Highly dynamic destination-sequenced distance-vector routing (DSDV) for mobilecomputers, in: Conference on Communications Architec-tures, Protocols and Applications (SIGCOMM), 1994.

[36] B. Awerbuch, D. Holmer, H. Rubens, The medium timemetric: high throughput route selection in multirate ad hocwireless networks, in: Kluwer Mobile Networks andApplications (MONET), Special Issue on ‘‘Internet Wire-less Access: 802.11 and Beyond’’, 2005.

[37] NS-2 Simulator Tool Home Page. Available from: <http://www.isi.edu/nsnam/ns/>, 2000.

[38] TCP Westwood Home Page. Available from: <http://www.cs.ucla.edu/NRL/hpi/tcpw/>.

http://www.isi.edu/nsnam/ns/

http://www.isi.edu/nsnam/ns/

http://www.cs.ucla.edu/NRL/hpi/tcpw/

http://www.cs.ucla.edu/NRL/hpi/tcpw/


[39] R. Garg, A. Kamra, V. Khurana, A game-theoreticapproach towards congestion control in communicationnetworks, Computer Communication Review (July) (2002)47–61.

Dzmitry Kliazovich received his Mas-ters degree in Telecommunication sci-ence from Belarusian State Universityof Informatics and Radioelectronics in2002. He is currently working towardsthe Ph.D. degree in University ofTrento, Italy. His main research inter-est lies in wireless networking field witha focus on performance optimizationand cross-layer design.

Fabrizio Granelli was born in Genoa in
1972. He received the «Laurea»(M.Sc.) degree in Electronic Engineer-ing from the University of Genoa,Italy, in 1997, with a thesis on videocoding, awarded with the TELECOMItaly prize, and the Ph.D. in Telecom-munications from the same university,in 2001. Since 2000 he is carrying onhis teaching activity as Assistant Pro-fessor in Telecommunications at the
Department of Information and Communication Technol-ogy—University of Trento (Italy). In August 2004, he wasvisiting professor at the State University of Campinas (Brasil).He is author or co-author of more than 40 papers published ininternational journals, books and conferences, and he ismember of the Technical Committee of the International Con-ference on Communications (ICC2003, ICC2004 and ICC2005)and Global Telecommunications Conference (GLOBE-COM2003 and GLOBECOM2004). He is guest-editor of ACMJournal on Mobile Networks and Applications, special issue on‘‘WLAN Optimization at the MAC and Network Levels’’ andCo-Chair of 10th IEEE Workshop on Computer-AidedModeling, Analysis, and Design of Communication Linksand Networks (CAMAD�04). He is General Vice-Chair ofthe First International Conference on Wireless Internet(WICON�05).

His main research activities are in the field of networking and
signal processing, with particular reference to network perfor-mance modeling, medium access control, wireless networks,next-generation IP, and video transmission over packetnetworks.

cross-layer congestion control in ad hoc wireless networks · cross-layer congestion control in ad...

Documents