TCP in Wireless Networks

1. TCP in Wireless Networks CS 598HL, 2006

2. Contents • TCP in Wireless Mobile Ad Hoc Networks • Some impacts on TCP • Understanding Link-Layer Behavior • Improving TCP Performance • With Out-of-Order Detection and Response • Conclusion

3. TCP in Wireless Mobile Ad Hoc Networks • TCP interaction with wireless mobile ad hoc networks • In wireless • High wireless medium losses • Frequent connectivity disruptions • Path asymmetry • Some impacts • Partitions • MAC Layer impacts • Network Layer impacts • Path asymmetry

4. TCP in Wireless Mobile Ad Hoc Networks • Effect of partitions • Partitions • Splitting its adjacent nodes into two isolated parts

5. TCP in Wireless Mobile Ad Hoc Networks • Effect of partitions • Effect of a long partition • It can lead the TCP sender to a long idle

6. TCP in Wireless Mobile Ad Hoc Networks • Effect of partitions • Effect of a short partition or fading • Invoke its exponential backoff mechanism • Decrease its transmission rate → The standard TCP needs to be adapted to work in partitions → Error-detection mechanism needs to detect the nature of the error

7. TCP in Wireless Mobile Ad Hoc Networks • MAC Layer impacts on TCP • MAC Layer • One hop recovery (7 times) • Providing an efficient shared broadcast channel • Some conditions • Hidden node • Exposed node • Capture effect

8. TCP in Wireless Mobile Ad Hoc Networks • MAC layer impacts on TCP • Hidden and exposed problems • Trigger a TCP retransmission • Impair the TCP fast retransmit • Capture effect • Unfairness → MAC Layer problems can hurt the TCP performance

9. TCP in Wireless Mobile Ad Hoc Networks • Network Layer impacts on TCP • Frequent route changes • the high probability of stale routes • Mobility • Medium constraints → A route protocol should take into consideration its impact on the upper layer

10. TCP in Wireless Mobile Ad Hoc Networks • PATH asymmetry • The forward path and the backward path can have different characteristics • Classification of the asymmetry • Bandwidth asymmetry • Loss rate asymmetry • Media access asymmetry • Route asymmetry Asymmetry condition can induce lack of ACKs in the sender, lead to inaccuracy in RTT estimation

11. Improving TCP Performance over Mobile Ad-Hoc Networks with Out-of-Order Detection and Response Feng Wang and Yongguang Zhang, ACM MobiHoc, 2002

12. Introduction • TCP performance is worse in mobile ad-hoc networks • High link error rate • Route failures • Packet drops • Route changes • Out-of-order delivery • Packet Order • It should be in sequence (in an ideal TCP) • In two cases, it can be violated • Out-of-Sequence • Out-of-Order

13. < A possible case of route change > Out-of-Order Delivery • Out-of-Sequence • Retransmission due to packet losses • Out-of-Order • A packet sent earlier arrives later than a subsequent packet • It often implies route change

14. Detecting Out-of-Order Event • Out-of-Order can happen in both direction • Out-of-Order ACK (sender) • Out-of-Order data packet (receiver) • How to detect Out-of-Order ACK (D1) • Property • No retransmission of an ACK • Non-decreasing of ACK sequence number • Two cases • For duplicate ACK • Compare ACK duplication sequence number (ADSN) • For the rest • Compare the sequence number

15. Detecting Out-of-Order Event • How to detect Out-of-Order data packet (D2) • Property • Retransmission • TCP packet sequence number • Two bytes • Incremented with every data packet • Need to add to the TCP header • TCP timestamp • Records the time in the TCP packet header • Compare the timestamp in each packet

16. Responding to Out-of-Order Event • The response actions • Take place at the sender • Two actions • Temporarily Disabling Congestion Control • Instant Recovery during Congestion Avoidance • Temporarily Disabling Congestion Control (R1) • The sender disable congestion control temporarily • The length of a time is a tradeoff

17. Responding to Out-of-Order Event • Instant Recovery during Congestion Avoidance (R2) • After the congestion indication event, if the sender begins receiving ACK, the sender resumes its previous route change state • In case of R2, there is no going through slow start or linear window recovery

18. Simulation Environment • ns2 (including the CMU wireless networks extension) • 20 nodes • 1000 m * 750 m rectangular area • Mobility pattern : the random way-point • Moving speed : 0 – 10 m/s • Routing protocol : DSR • The workload : a single TCP connection • Network condition • Non-congestion mode • Congestion mode (CBR flows are added)

19. Performance Analysis • Some parameters • All : detect Out-of-Order with both D1 and D2, and take both R1 and R2 • SD : activate D1 only, but take both R1 and R2 • RD : activate D2 only, but take both R1 and R2 • TD : detect with both D1 and D2, but take only R1 • IR : detect with both D1 and D2, but take only R2 • T1 : congestion control disabling period • T2 : instant recovery period

20. The different T1 and T2 does not make much difference No significant difference < DSR with Congested condition > Performance Analysis Improvement ration is between 45% to 57% < DSR with Uncongested condition >

21. T2 does not make a difference < DSR with Uncongested condition > The instant recovery mechanism is more productive < DSR with Congested condition > Performance Analysis Improvement ratio is between 32% to 50%

22. Conclusion • The sender can distinguish route changes from network congestion • By not invoking unnecessary congestion control, it can improve the performance • This mechanism can be applied to both ad hoc an fixed networks

23. References • [1] R. Oliveira and T. Braun, "TCP in wireless mobile ad hoc networks," Technical Report IAM-02-003, 2002 • [2] A. Jardosh, K. Ramachandran, K. Almeroth, and E. Belding-Royer, “Understanding Congestion in IEEE 802.11b Wireless Networks,” IMC, 2005 • [3] Feng Wang and Yongguang Zhang, “Improving TCP Performance over Mobile Ad-Hoc Networks with Out-of-Order Detection and Response,” ACM MobiHoc, 2002

24. Conclusion • We have seen the impacts on TCP in Wireless Mobile Ad-Hoc Networks • We have studied how link reliability is correlated with • Retransmission • Frame size • Data rate • We have shown an improvement of TCP performance over Mobile Ad-Hoc Networks • Out-of-Order Detection and Response

25. A Receiver-Centric Transport Protocol for Mobile Hosts with Heterogeneous Wireless Interfaces Hung-Yun Hsieh, Kyu-Han Kim, Yujie Zhu, and Raghupathy Sivakumar

26. Backend Server Internet Access Network A • Loss Recovery Proxy Server • Congestion Control Access Network B • Power Management • Seamless Handoffs • Server Migration • Bandwidth Aggregation Mobile Host Wireless Communication

27. Backend Server Internet Access Network A Proxy Server Access Network B Mobile Host Role of the Mobile Host • Closest to wireless link • Better views

28. Outline • Tackling the wireless last-hop • Motivations • Loss recovery • Congestion control • Power management • RCP: reception control protocol • Supporting multi-homed mobile hosts • Motivations • Seamless handoffs • Server migration • Bandwidth aggregation • R2CP: radial RCP • Summary

29. Loss Recovery • Loss recovery • Detect and react according to the nature of losses • Loss differentiations • Sender-centric approaches • The sender needs feedback from the receiver • Overheads, latency, and can be incomplete or unreachable • Receiver-centric approaches • The receiver fully aware of the loss occurrences • First-hand information about the nature of losses • Interaction with wireless Link Layer

30. Congestion Control • Congestion control • Optimality of interface-specific congestion control: STP for satellite , WTCP for WWAN, TCP-West • Sender-centric approaches • Optimal congestion control scheme cannot be used without the support from the sender • The sender be configured with all possible schemes and be updated for any new access technology • Receiver-centric approaches • The receiver implements only the congestion control schemes of certain interfaces • The sender does not need to be involved

31. Power Management • Power management • TCP ~ power consumption (bursty channel errors) • Channel state based window adaptation • Sender-centric approaches • RTT variation due to receiver power management • Feedback consumes power, and can potentially limit the time granularity of the power conserving decision • Receiver-centric approaches • Sender merely responds based on the receiver’s direction • Receiver can take power-conserving decisions

32. SEG.SEQ SEG.ACK SND.NXT SND.UNA RCV.NXT REQ.NXT Reliability Reliability SEG.ACK + SEG.WND ReqMuch SendMuch NextSend NextReq SEG.SEQ SEG.DEQ SEG.WND RCV.NXT RCV.WND Loss / Progress Loss / Progress RWND Flow Control Send Flow Control Resequencing SND.NXT RWND SEG.SEQ SEG.REQ + SEQ.DEQ recv buffer recv buffer send buffer send buffer ReqMuch SendMuch SEG.REQ SEG.SEQ Congestion Control Congestion Control CWND CWND TCP sender RCP sender RCP receiver TCP receiver RCP: Reception Control Protocol • A TCP clone in its behavior • TCP semantics: reliable, in-sequence data delivery • TCP-equivalent operations • Transposition of protocol functionalities • Receiver-centric congestion control, reliability, and flow control

33. RCP Operations • REQ – DATA handshake • Retain the self clocking mechanism in TCP that uses the DATA – ACK handshake • Allow the receiver to control which data the sender should send on a per-packet granularity • REQ • Generated based on the available buffer space at the receiver (flow control) and the congestion window size • The window size controls the amount of pending REQs, while the return of DATA clocks the progression of the window (congestion control) • Loss is inferred through out-of-order DATA arrivals or timeouts – the receiver has complete knowledge of the state of the received buffer (reliability) • Improved robustness using two modes: cumulative mode and pull mode

34. RCP Performance • TCP friendliness • REQ is robust to losses • Introduce on/off traffic in the reverse path (drop rate ~ 40%) • Intelligent loss recovery • RCP-ELN achieves better performance than TCP-ELN (56% improvement for 1% packet loss rate) • Scalable congestion control • Implement a receiver-centric version of STP called RCP-STP, which shares the same sender as RCP (RCP-NewReno) • RCP-STP achieves the desired performance as STP in a satellite environment (RTT ~ 500ms) • Efficient power management • Use the WiFi device and two-state Markov error model • RCP achieves power savings without suffering from the performance degradation in TCP

35. Outline • Tackling the wireless last-hop • Motivation • Loss recovery • Congestion control • Power management • RCP: reception control protocol • Supporting multi-homed mobile hosts • Motivation • Seamless handoffs • Server migration • Bandwidth aggregation • R2CP: radial RCP • Summary • Tackling the wireless last-hop • Motivation • Loss recovery • Congestion control • Power management • RCP: reception control protocol • Supporting multi-homed mobile hosts • Motivation • Seamless handoffs • Server migration • Bandwidth aggregation • R2CP: radial RCP • Summary

36. Multi-homed Mobile Hosts • Different access technologies • Network capacity (data rate), coverage area, mobility support, and power • Challenges • Autonomous domains • Heterogeneity: bandwidth, delay, loss rate, and fluctuation • seamless handoffs • server migration • bandwidth aggregation

37. Seamless Handoffs • Seamless handoffs • Avoid latency exhibited in using Mobile IP etc. • Multiple states can facilitate seamless handoffs • Sender-centric approaches • The sender be informed of the handoff decision and status at the receiver • Switch congestion control scheme ? • Receiver-centric approaches • The receiver is fully aware of the handoff decision • Enable interface-specific congestion control schemes required during handoffs

38. Server Migration • Server migration • Service continuity when the mobile host moves across different autonomous domains • State synchronization required • Sender-centric approaches • Overheads in synchronizing the (complex) sender states • May have to flush the receiver buffer • Receiver-centric approaches • Minimal sender state: minimal sync overhead • Receiver request only the unreceived data

39. Bandwidth Aggregation • Bandwidth aggregation (striping) • Enable multipoint-to-point (multiple sources) bandwidth aggregation • Sender-centric approaches • Multipoint-to-point bandwidth aggregation cannot be effectively supported • Interpreting and conveying the policy supplied by the user can be unwieldy • Receiver-centric approaches • Receiver control and coordinate transmissions from different senders: multipoint-to-point • Receiver access the policy, and follow the policy (dynamics of the wireless link)

40. R2CP: Radial RCP • RCP for multi-homed mobile hosts • A receiver-only extension which can communicate with one or multiple RCP senders • Multi-state transport protocol built atop RCP • Multipoint-to-point communication (as well as unicast)

41. Receiver-centric operations • Receiver-centric operations • Receiver-centric operations • Receiver-centric operations • Maintaining multiple states • Maintaining multiple states • Maintaining multiple states • Decoupling of functionalities • Decoupling of functionalities • Effective packet scheduling R2CP Design • Receiver-centric operation • A receiver-only extension without changing the sender • Plug-n-play interface-specific congestion control schemes at the receiver without sender awareness • Maintaining multiple states • Individual states resemble the default RCP states • Dynamic state creation and deletion depending on the number of interfaces used or servers connected • Decoupling of functionalities • Per-path (pipe) functionalities (e.g. congestion control) decoupled from per-connection functionalities (e.g. reliability) • R2CP controls what data each pipe should receive, while RCP controls how much data each pipe can receive • Effective packet scheduling • R2CP supports in-sequence data delivery • Effective packet scheduling avoids head-of-line blocking • R2CP schedules which data should be received through individual RCP pipes, while RCP controls when and how much data each pipe can request

42. R2CP Performance • ns-2 emulation • Live Internet traffic • Uncontrolled environment • Testbed • 2 WiFi access points with different ESSIDs • 1 IBM laptop with two WiFi cards • 2 Dell desktops • Linux OS • libpcap + tcpdump + ns-2 trace

43. Seamless Handoffs • Scenario • The two interfaces are associated with different IP addresses in respective networks • The mobile host opens the RCP-2 pipe before closing the RCP-1 pipe • The mobile host continues receiving data without any stall during handoffs

44. Server Migration • Scenario • The mobile host connects to Server-II when it moves to network B • RCP-3 is opened between address B and Server-II • RCP-2 is between address B and Server-II for reference • The receiving application at the mobile host can be made unaware of the server migration

45. Bandwidth Aggregation • Scenario • Best-effort bandwidth aggregation • Packet scheduling • Bandwidth mismatch • Delay mismatch • Buffer occupancy • R2CP can effective achieve bandwidth aggregation through its RTT-based packet scheduling

46. Related Work • NETBLT [Clark 87] • The receiver maintains the retransmission timer • WTCP [Sinha 99], TFRC [Handley 00], TCP-Real [Tsaoussidis 02] • Increased participation from the receiver, including calculating the send rate, maintaining the loss history, or tracking loss events • WebTP [Gupta 00] • A receiver-centric transport protocol optimized for the Web application • It does not consider REQ losses, and is not TCP friendly • Bandwidth management and sharing [Spring 00, Mehra 03] • RCP can allow more effective bandwidth management and sharing for mobile hosts over the wireless link than TCP

47. RTT2 RTT1 RTT1 T time t3 t4 t5 RTT2 DATA        REQ       R2CP Packet Scheduling • Avoid out-of-order arrival of data rank data structure • Every pending REQ sent out by pipe j at time t has an entry with a timestamp of t + 2*RTTj • The rank of a new REQ issued by pipe k at time T is determined by comparing T + RTTk with entries in the rank data structure  The binding data structure maintains the mapping between the R2CP sequence number and the RCP sequence number (along with the pipe identifier) The pending data structure maintains ranges of data to be requested (includes retransmissions)