TCP in Wireless Ad Hoc Networks 2008

TCP on Wireless Ad Hoc Networks TCP overview Ad hoc TCP and network layer: mobility, route failures and timeout The problem of fairness and the NRED TCP Westwood: efficient transport for high-speed wired/wireless networks

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.

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 TCP Throughput using 2 Mbps MAC, transmission range = one hop For large number of hops throughput stabilizes (pipelining effect)

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

Impact of Mobility on TCP Mobility causes route changes Throughput generally degrades with increasing speed … Average throughput over 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

Enhancing TCP Fairness in Ad Hoc Wireless Networks Using Neighborhood RED Kaixin Xu, Mario Gerla University of California, Los Angeles Lantao Qi, Yantai Shu Tianjin University, Tianjin, China (Mobicom 2003)

TCP Unfairness in Ad Hoc Networks 3 TCP flows contending with each other Flow 2 is nearly starved Original RED fails to improve the fairness

 Direct way: Announce queue size upon changes  Too much overhead, queue location problem?  Our method: Indirectly estimate an index of instant queue size by monitoring wireless channel Neighborhood Congestion Detection Average queue size is calculated using RED ’ s alg. Congestion: queue size exceeds the minimal threshold  Channel utilization ratio  Queue size index K is a constant Channel busy CTS

Neighborhood Random Early Detection (NRED) Extending RED to the distributed neighborhood queue (Virtual) Key Problems –Counting the size of the distributed neighborhood queue –Calculating proper packet drop probability at each node Components of Neighborhood RED –Neighborhood Congestion Detection (NCD) –Neighborhood Congestion Notification (NCN) –Distributed Neighborhood Packet Drop (DNPD)

Performance Evaluation Fairness is achieved Loss of aggregated throughput –Tradeoff between fairness and throughput Overall Throughput

Experiment result on TJU testbed f

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) t k-1 t k dk dk sample exponential filter filter 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*RTT min (instead of ssthresh=cwin/2 as in Reno) if (cwin > ssthresh) set cwin=ssthresh –When a TIMEOUT expires: set ssthresh=BE*RTT min (instead of ssthresh=cwnd/2 as in Reno) and cwin=1 Note: RTT min = 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

TCPW in presence of random loss: Analysis and Simulation

TCPW Rate Estimation (TCP RE) Rate estimate (RE) is obtained by aggregating the data ACKed during the interval T (typically = RTT): sample exponential filter filter gain dkdk T d k-1 tktk T is the sample interval

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

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

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