Transport Protocols for Wireless Ad Hoc Networks

1. Transport Protocols for Wireless Ad Hoc Networks

2. TCP Congestion Control loss event = timeout or 3 duplicate acks

3. Problems in TCP over Wireless Ad Hoc Networks • Miss interpretation of packet loss • TCP interprets any packet loss as a sign of congestion. • TCP sender reduces congestion window. • On wireless links, packet loss can also occur due to random channel errors, handoffs or route changes. • Not due to congestion. • Reducing window may be too conservative. • Leads to poor throughput. • How to distinguish loss due to congestion from loss due to other wireless/mobility reasons? • Frequent path break leads to throughput degradation • Route reestablishment delay > RTO  congestion notification reduce CW  performance degradation

4. Factors that affect TCP performance • Wireless transmission errors • Multi-hop routes on shared wireless medium • For instance, adjacent hops typically cannot transmit simultaneously • Route failures due to mobility • Unfairness

5. Wireless Transmission Errors • If # of errors is small • may be corrected by an error correcting code  delivered • Excessive bit errors • result in a packet being discarded, possibly before it reaches the transport layer  lost • Random errors may cause Fast Retransmission • retransmission of lost packet • reduction in congestion window reduces the throughput (unnecessary) • Sometimes congestion response may be appropriate • When a channel is in a bad state for a long duration, it might be better to let TCP backoff • Burst errors may cause Timeouts • If wireless link remains unavailable for extended duration, a window worth of data may be lost • driving through a tunnel • passing a truck • Timeout results in slow start • Slow start reduces congestion window to 1 MSS, reducing throughput • Reduction in window in response to errors unnecessary

6. TCP on Multi-hop Wireless • TCP throughput drops with increase in #hops. • Reasons • Each hop adds additional self-contention. • Also, more delay, more variability in delay, and more chance of packet loss. • They increase RTO. • Packet transmission can occur on at most one hop among 3 consecutive hops • Contention between TCP Data and ACKs traveling in opposite directions

7. Impact of Mobility: TCP Throughput • Think of a TCP session where one end point is a mobile. • Route recomputations cause interruptions often longer than RTO. • Source doubles RTO. • Large original RTO or longer interruptions especially vulnerable. • Explicit notifications have been found to be useful. • Explicit route failure and route reconnect notifications to TCP source

8. TAP3 TAP2 TAP4 TAP1 Impact of MAC Unfairness • Notations: Obj = objective throughput for fair sharing Basic = no RTS/CTS • Two longer flows starve • Similar effect regardless whether RTS/CTS are used ACK Traffic

9. How to Improve TCP Throughput • Mask wireless loss from the TCP sender. • TCP sender will not reduce congestion window • Explicitly notify the TCP sender about cause of packet loss. • TCP sender will not reduce congestion window for wireless losses. • Solutions may be at the sender, at the receiver, or at an intermediate node (basestation).

10. TCP-F: TCP Feedback [9-3] • Aims to minimize the throughput degradation resulting from the frequent path breaks • Allows the source to be informed of a route disconnection as a result of node mobility. • Avoid going through SS process • Failure point (FP) detecting link break • Originate Route Failure Notification(RFN) packet toward the source • Every intermediate node • updates its routing table and forwards toward the source, • Or, if has an alternate route to the destination, discards RFN and use the alternate route. • When the source receives RFN, it enters SNOOZ state • The source stops transmitting all data packets • It freeze all timers, the current cwnd size, and value of other state variables, such as RTT estimate, RTO.. • It then initiates route failure timer: depend on the worst-case route repair time • When the source receives route reestablishment notification (RRN) packet, or route failure timer is expired, • Data transmission will be resumes and all timers and variables will be restored • Do FP or intermediate nodes always find the path to the source ?

11. TCP-ELFN: TCP with Explicit Link Failure Notification [9-8] • Similar to TCP-F, except for • Handling ELFN • Orignates “Destination Unreachable” ICMP error msg, or • Piggy back ELFN on RERR message that is sent to the sender • Detecting route reestablishment • When the TCP sender receives the ELFN, • Disables RTO, and enters a standby state • Periodically originates probe packets to see if a new route is reestablished • If receives an ACK for the probe, leaves standby state, and restore RTO • Less dependent routing protocol

12. TCP-BuS: TCP with Buffering Capability and Sequence Information [9-10] • Use explicit feed back, but more dependent on routing protocol • ABR was proposed for underlying routing protocol • When route break is detected, • PN (pivot node): send Explicit Route Disconnection Notification(ERDN) to TCP-Bus sender • buffers packets in transit from sender to PN until partial path is reestablished, • Downstream intermediate node: send Route Notification(RN) to TCP-BuS receiver • Intermediate node that receives an RN packet discards all packets belonging to the flow • Routing protocol • LQ  destination: carries SEQ of TCP segment buffered at PN • REPLYPN: carries SEQ of the last segment successfully received by receiver • When route is repaired, • PN: send Explicit Route Successful Notification(ERSN) to TCP-BuS • Sender: understands • The last successfully received packet at destination • The packets buffered at PN, • the packets lost in transition • Receiver understands that lost packets will be delayed further • To avoid unnecessary requests for fast retransmission, use selective ACK • Packets in transit before route disconnection ; Destination node continue to send ACK

13. ATCP: Ad Hoc TCP [9-12] • Compatible with TCP • Implemented only at TCP sender • New interpretation • ECN (explicit congestion notification) or ICMP source quench: congestion • ICMP DUR: link break • 3 duplicated ACK: • Avoid fast reTX and fast recovery (CW backoff) • TCP state  persist state to avoid CW backoff • reTx by ATCP

14. Split TCP [9-13] • To solve • the degradation of throughput with increasing path length • unfairness in wireless MAC (channel capture effect) • Lessen impact of mobility • Split a long TCP connection into a set of short concatenated TCP connections (called segments or zones) • To operate at its own transmission rate • Proxy node • Buffering • Local ACK • Split congestion control and end-to-end reliability • Congestion window: local ACK • End-to-end window: end-to-end ACK • Drawback: IP pay load encryption cannot be used