TCP in Wireless Ad Hoc Networks

2009

Summary: TCP Congestion Control

• When CongWin is below Threshold, sender in slow-start phase, window grows exponentially.

• When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly. AIMD

• When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold. AIMD

• When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.

TCP Problem over Wireless Networks

• In TCP– Packet Loss <=> Congestion

• But in Mobile Networks– Packet Loss <=> Congestion (Net) ???

• high bit error rate (Phy) - No• access contention (MAC) - ?• disconnection (Net) - No• handoff (Net) - No

• The TCP end-to-end performance is degraded seriously in wireless networks

Problems with TCP in ad hoc networks

• Multihop - throughput reduction• mobility - path breaks and forces TCP to

timeout Random interference/jamming causes

packet loss => timeout Source cannot discriminate between

congestion loss and random loss => drive TCP window to zero!

Interaction between TCP backoff and MAC backoff may cause unfairness and “capture”

Impact of Multi-Hop Wireless Paths

0

200

400

600

800

1000

1200

1400

1600

1 2 3 4 5 6 7 8 9 10

Number of hops

TCP Throughtput(Kbps)

TCP Throughput using 2 Mbps 802.11 MAC, transmission range = one hop

For large number of hops throughput stabilizes (pipelining effect)

Throughput Degradations withIncreasing Number of Hops

• Packet transmission can occur on at most one hop among three consecutive hops

• Increasing the number of hops from 1 to 2, 3 results in increased delay, and decreased throughput

• Increasing number of hops beyond 3 allows simultaneous transmissions on more than one link, however, degradation continues due to contention between TCP Data and Acks traveling in opposite directions

• When number of hops is large enough, the throughput stabilizes due to effective pipelining

Impact of Mobility on TCP

• Mobility causes route changes• Throughput generally degrades with

increasing speed …

Averagethroughputover 50 runs

Speed (m/s)

Ideal

Actual

How to Improve Throughput

• Network feedback• Inform TCP of route failure by explicit

message• Let TCP know when route is repaired

– Probing (eg, persistent pkt retransmissions)

– Explicit link repair notification• Alleviates repeated TCP timeouts and backoff

Performance with Explicit Notification

0

0.2

0.4

0.6

0.8

1

2 10 20 30

mean speed (m/s)

thro

ug

hp

ut

as a

fra

ctio

n o

fid

eal

Base TCP

With explicitnotification

TCP-over-wireless

End-to-end approaches– Purely Sender-centric: TCP-Westwood, TCP-SPC– Involving both sender and receiver: WTCP– Purely Receiver-centric: e.g. RCP, WebTP

Split-Connection/Base-Station Oriented

e.g. Indirect-TCP, Snoop etc.

Link-layer approaches– Reliable link layer

Misc.

e.g. Loss Discrimination using AQM, Explicit Notification etc.

TCP Westwood: Efficient Transport for High-speed

wired/wireless Networks

(Mobicom 2001)

TCP Westwood (Mobicom 2001)Key Idea:• Enhance congestion control via the Rate

Estimate (RE) – Estimate is computed at the sender by

sampling and exponential filtering– Samples are determined from ACK inter-

arrival times and info in ACKs regarding amounts of bytes delivered

• RE is used by sender to properly set cwnd and ssthresh after packet loss (indicated by 3 DUPACKs, or Timeout)

Rate Estimation (BE-> RE)

• Ideally, would like to determine the connection fair share of the bottleneck bandwidth

• Since fair share is difficult (to define or determine), we instead estimate the achieved rate: Rate Estimate (RE)

Receiver

Sender

Internet

Bottleneck

packets

ACKs

measure

• First TCPW version used a “bandwidth like” estimator (BE) given by:

“ Original” Rate estimation (BE-> RE)

)/( 1 kkkk ttdb

tk-1 tk

dk

2

1 11

kkkkkk

bbBEBE

sample

exponential filter

k

kk t

t

2

2filter gain

RE/BE Estimation is similar to Keshav Packet Pair estimation

TCP Westwood: the control algorithm

• TCPW Algorithm Outline:– When three duplicate ACKs are detected:

• set ssthresh=BE*RTTmin (instead of ssthresh=cwin/2 as in Reno)

• if (cwin > ssthresh) set cwin=ssthresh

– When a TIMEOUT expires:• set ssthresh=BE*RTTmin

(instead of ssthresh=cwnd/2 as in Reno) and cwin=1

Note: RTTmin = min round trip delay experienced by the connection

TCP Westwood Benefits

• Reno overreacts to random loss (cwin cut by half)• TCPW less sensitive to random loss

– (1) a small fraction of “randomly” lost packets minimally impacts the rate estimate RE

– (2) Thus, cwin = RE x RTT remains unchanged • As a result, TCPW throughput is higher than Reno • What do we gain by using RE “feedback” in addition

to packet loss?

(a) better performance with random loss (ie, loss caused by random errors as opposed to overflow)

(b) ability to distinguish random loss from buffer loss

(c) using RE to estimate bottleneck bdw during slow start

TCPW in a wireless lossy environment• Efficiency: Improvement significant on high (Bdw x

Length) paths

• Fairness: better fairness than RENO under varying RTT

• Friendliness: TCPW is friendly to TCP Reno

D a t a G e n e r a l

D a t a G e n e r a l

Base StationW ireless

Host

In te rnet In ternet

TC P

long p ropaga tion tim e

link e rro rs

TCPW in presence of random loss: Analysis and Simulation

Summary

• Introduced the concept of Rate Estimation and related work

• Reviewed end-to-end estimation based congestion control methods

• Presented TCP Westwood, and the evolution of “fair rate” estimate to improve the performance; showed simulation results to evaluate the method

• Compared TCPW with other methods