Open Issues on TCP for Mobile Computing

1. Open Issues on TCP for Mobile Computing Ibrahim Matta Computer Science, Boston University Vassilis Tsaoussidis Computer Science, Northeastern UniversityTechnical Report, 2001 Presented by Brad Burres

2. First things First • SORRY! • This paper was interesting, but it was long • Apparently picking another paper based solely on the author wasn’t a good idea!

3. Agenda • Introduction • Review of TCP • TCP problems in a wireless world • Fixing TCP: Error Detection • TCP error recovery and performance enhancements • TCP Strategy • Conclusions

4. Introduction • Mobile networking is growing quickly • Protocols were tuned the “wired” world • TCP is the most prevalent example • Packet loss meant congestion (or total link failure) • The only performance metric was throughput • Assuming fairness, stability, etc. • TCP is insufficient for the wired/wireless world of today and tomorrow

5. What does TCP need? • TCP needs to not only detect an error, but to detect the nature of an error • That is, detect the error characteristics of the link • TCP needs have more flexible and robust recovery mechanisms • Awareness of the wireless power constraint – reduce a clients energy consumption

6. Review of TCP • This is review for all of us, but I’m going to hit a few key points • TCP was designed with a few key goals: • Reliable Transmission • Reasonable Fairness between flows • The ability to quickly adapt to fluctuations in available bandwidth • Mechanisms for congestion avoidance and error recovery

7. TCP Key Concepts • TCP controls data transmissions through a sliding window • Error control consists of error detection and then error recovery • TCP detects errors by monitoring acknowledged data segments (if a timeout occurs, a packet was lost) • Error recovery consists of two things • The retransmission of lost data • The reduction of the congestion window size • AIMD: Additive Increase Multiplicative Decrease

8. TCP Flavors of Congestion Control • TCP Tahoe – basic TCP mechanisms (Slow Start) but added the idea of Fast Retransmit • TCP Reno – TCP Tahoe + Fast Recovery • Retransmit the lost segment, and continue (after reducing CWND by ½) • TCP Vegas – Totally different. Keep a RTT estimate, and use that to see if the channel is being utilized (and hence to resize the transmission window).

9. A Picture is worth 1000 words

10. TCP problems in a wireless world • TCP is NOT capable of detecting the nature of an error. It only knows a drop occurred. (at least two general types of errors) • Short Lived Errors • Entering Slow Start or decreasing the transmission window causes missed opportunities to send error-free data and increases connection time. • Persistent Errors • Forced re-transmission over bad links leads to high energy consumption with minimal goodput gain • TCP backs off too much when it should not and too little when it should, thereby hurting battery life

11. Other TCP comments • TCP error control is designed for congestion induced errors only • ECN contributions are limited in wired/wireless networks • Not receiving an ECN doesn’t mean the packet wasn’t dropped • Congestion algorithms running on top of TCP (RED) could constrain the evolution of TCP • If TCP evolves, it might make RED unfair

12. Fixing TCP: Error Detection • The nature of an error calls for a distinctive recovery strategy • Congestion – same as wired, gradual retransmission • Hand-Off – suspend transmission for short amount of time, then send aggressively • Fading – reduce transmission until the channel is better • Tsaoussidis and Badr propose TCP-Probing

13. TCP-Probing • When a packet is lost, enter a Probe Cycle • In a Probe Cycle • All data transmission is suspended • A probe (small packet) is sent • If Probe or Ack is lost, re-initiate Probe Cycle • Otherwise, estimate RTT (and congestion) • If Congested, enter Tahoe/Reno congestion response • If not Congested, enter Immediate Recovery and being sending with the full window enabled

14. WTCP (proxy) • Add intelligence to the wireless base station (BS) and let it detect the nature of the error • Essential two TCP connections: between the Sender and BS, and between the BS and receiver • BS buffers the data segment • Re-transmit non-ACK’d segments • Subtract out WTCP residence time when ACKing segments back to the sender • Data lost over the wireless link could adversely effect the Time Out value

15. Error Recovery • If nature of the error is known, be smart about the recovery • CWND • ACK strategy • Timeout Mechanism • Entering Slow Start • Others…. • If it’s not a congestion based error, don’t apply a congestion derived strategy.

16. Congestion Window • Freeze-TCP – avoid a penalty during handoff • Immediate Recovery – if the failure is not due to congestion, don’t adjust the CWND or enter Slow Start. • Re-transmit aggressively when the channel recovers. • Decouple the CWND from RTT. A lost or delayed ACK doesn’t say anything about the forward path, only the backward path.

17. ACK Strategy • The ACK strategy sets the transmission rate • Fast Retransmission = improved hand-off • After HO, send Duplicate ACKs. • Using partial ACKs to re-transmit can lead to transmitting a non-lost packet. • This is bad from the energy conservation perspective • Implementing SACKs (selective ACKs) gives the sender more information

18. Proxy Based Approach • Proxy lies between the wired and wireless networks • Tries to hide wireless losses from TCP • ITCP – Implement TCP up to the Application layer in the BS • WTCP – like ITCP, but up to the Transport layer. • Snoop - Like WTCP, but up to the Link layer. Less buffering (no guarantee) of finding data locally.

19. Proxy performing Local Recovery

20. Increased Improvement by not increasing the Time-Out Value

21. TCP Strategy • TCP needs to move towards the adaptive error control • One way to achieve this is to implement the discussed TCP-Probing • By determining the nature of the error and reacting in an appropriate manner, the total throughput will be increased

22. Faster Task Completion with Probing

23. Even Faster Completion with Longer Delays (100ms extra)

24. TCP for Handhelds • TCP for wireless networks needs to make tradeoffs between the effort expended and the goodput achieved • A good performance metric is goodput/overhead ratio because it shows the efficiency of a battery powered transfer • In general, reducing the total time spent transferring data will reduce power consumed • More research is needed in this area…

25. Probing Reduces Overhead

26. Probing Reduces Overhead more with longer propagation delays

27. Conclusions • Traditionally, protocols (namely TCP) did not account for wireless architecture • Key issues for wireless networks: • error characteristics of the link • performance metrics to evaluate efficiency • TCP needs • Adaptive Error Control to respond to each error appropriately • Energy- and time-saving capabilities to support the mobile, battery powered nature of wireless devices

28. Acknowledgements • “borrowed” fast retransmit picture from http://www.ensc.sfu.ca/~ljilja/cnl/presentations/wan/wireless_TCP/sld003.htm