1. TCP in Wireless Ad Hoc Networks
2009

2. 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.

3. 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

4. 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”

5. Impact of Multi-Hop Wireless Paths
TCP Throughput using 2 Mbps MAC,
transmission range = one hop
For large number of hops throughput stabilizes (pipelining effect)

6. Throughput Degradations with Increasing 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

7. Impact of Mobility on TCP
Mobility causes route changes
Throughput generally degrades with increasing speed …
Ideal
Average
throughput
over
50 runs
Actual
Speed (m/s)

8. 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

9. Performance with Explicit Notification

10. 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.

11. TCP Westwood: Efficient Transport for High-speed wired/wireless Networks
(Mobicom 2001)

12. 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)

13. Rate Estimation (BE-> RE)
Receiver
Sender
Internet
Bottleneck
packets
ACKs
measure
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)

14. “Original” Rate estimation (BE-> RE)
tk-1 tk dk
First TCPW version used a “bandwidth like” estimator (BE) given by:
sample
exponential filter
filter gain
RE/BE Estimation is similar to Keshav Packet Pair estimation

15. 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

16. 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

17. 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

18. TCPW in presence of random loss: Analysis and Simulation

19. TCPW Rate Estimation (TCP RE)
dk-1 dk tk
T is the sample interval T
Rate estimate (RE) is obtained by aggregating the data ACKed during the interval T (typically = RTT):
sample
exponential filter
filter gain

20. TCPW RE or BE interaction with RENO
One TCPW RE or BE and one Reno share a 5Mbps bottleneck
No errors (bottleneck gets saturated)
Errors (0.5%), no congestion
fair share*
fair share
BE overestimates fair rate ( = 2.5 Mbps)
TCPW BE Not friendly to NewReno!
RE underestimates fair rate (=3.6 Mbps)
TCPW RE does not improve thruput!
(*) TCPW fair share > 50% because NewReno is incapable of getting 50%

21. TCPW with adaptive filter (AF)
Neither RE or BE estimator are optimal for all situations
BE is more effective in random loss
RE is more appropriate in congestion loss (ie, buffer overflow)
KEY IDEA: dynamically select the aggressive estimate (BE) or the conservative estimate (RE) depending on current channel status (congestion or random loss?)
NEEDED: a “congestion measure” that gives us an idea of the most probable cause of packet loss (congestion or random)
The Adaptive Filter actually provides a smooth transition from aggressive to conservative measure

22. 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