1. 1 RCP (Reception Control Protocol) A Receiver-Centric Transport Protocol for Mobile Hosts with heterogeneous Wireless Interfaces MOBICOM 2003 H. Hsieh, K. Kim, Y. Zhu, and R. Sivakumar, Georgia Institute of Technology Presented for ECE299.02 by Thilee Subramaniam

2. 2 OUTLINE of Presentation  Problem Statement  Quick TCP Review  Case for RCP  Protocol Details  Performance  Discussion  Q&A

3. 3 OUTLINE of Presentation  Problem Statement  Quick TCP Review  Case for RCP  Protocol Details  Performance  Discussion  Q&A

4. 4 What is the Problem?  Wired: low BER  Wireless: high BER (channel error, Fading, Handoffs)  TCP was originally proposed for wired networks assumes losses are due to congestion corrective measures address congestion only!  TCP over wireless: does not perform well  TCP over wireless: can it be improved?

5. 5 OUTLINE of Presentation  Problem Statement  Quick TCP Review  Case for RCP  Protocol Details  Performance  Discussion  Q&A

6. 6 TCP Recap  End-to-end argument Cater to the end-point specific requirements  Flow Control  Congestion Control Various flavors of TCP  Reliable in-order delivery data packet ACK receiversender cwnd 1 2 3 4 5 6 7 8

7. 7 Typical wireless setup  FH: Fixed Host  BS: Base Station  MH: Mobile Host  Assumption: Most data flow is from FH to MH

8. 8 TCP and wireless networks  Sender does Congestion control  Sender reacts to feedback from receiver  Assumption: any loss is due to congestion  BS MH connection highly error prone  MH to FH feedback takes time and resources  Sender ends up sending less data!  Reduces network performance. Not Good!!

9. 9 Attempts for Wireless friendly TCP  Snoop Link-layer of BS buffers un-ACKed data and DupACKs Retransmit Data, Suppress DupACK from MH to FH Prevent FH from decreasing CWND drastically Issues: IPSec incompatibility, mess with RTT estimate on FH, requires change in BS which is difficult  WTCP Do local recovery like Snoop BS adds timestamp to ACKs from MH to FH, informing FH to correctly estimate RTT Issues: require change in BS, assume all losses are due to errors while congestion is possible!

10. 10 Attempts for Wireless friendly TCP..  ELN (Explicit Loss Notification) BS sets an ELN bit in DupACK header FH does not decrease CWND for DupACK with ELN set Issue: Still need BS change, consumes resources for feedback  Freeze-TCP Moves intelligence to MH Primary focus: handoff; FH still does Congestion Control  Syndrome BS simply adds the number of packets sent to MH MH can differentiate W loss and WL loss Handoff is still a problem

11. 11 OUTLINE of Presentation  Problem Statement  Quick TCP Review  Case for RCP  Protocol Details  Performance  Discussion  Q&A

12. 12 Motivation for Receiver-Centric Protocol  Why does Wireless TCP under-perform? Sender over-reacts by reducing CWND when not necessary  Why cannot Receiver provide more information? Magnitude Cost Latency  The closer the problem solver is to the problem, the easier it is to solve  Client specific congestion control mechanisms Sender cannot provide custom mechanisms Generic mechanism cannot make everyone happy

13. 13 More Reasons  Multi-homed Devices (Notebook with Wifi, WIMAX, and 3G cards)  Technology specific congestion control schemes may be required. Receiver-centric more useful  Users can move from one technology coverage-area to another Receiver-centric transport protocol can better handle handoffs

14. 14 Even More Reasons..  Power issue with mobile devices Limited Battery Wireless Transmission/Reception consume high % energy  Wireless errors happen in bursts Need to cut down transmission Costly to inform the sender to cut down CWND Receiver dropping packets: affects throughput

15. 15 Therefore… More appropriate to let receiver handle How Much data? Which data?

16. 16 OUTLINE of Presentation  Problem Statement  Quick TCP Review  Case for RCP  Protocol Details  Performance  Discussion  Q&A

17. 17 TCP: Connection and Data transfer SYN ISN=X SYN ISN=X 1 SYN ISN=Y ACK=X+1 SYN ISN=Y ACK=X+1 2 ACK=Y+1 3 time DATA X+3 4 ACK=X+4 5

18. 18 RCP: Transposition of TCP SYN ISN=X SYN ISN=X 1 SYN ISN=Y ACK=X+1 SYN ISN=Y ACK=X+1 2 ACK=Y+1 3 time REQ 4 DATA 5  Either party can initiate connection  Receiver initiates with transfer Cumulative mode Pull mode Sender Receiver

19. 19 RCP: Flow Control  In TCP, receiver advertises its buffer size Sender makes sure that sent data is limited by this  No need to advertise this in RCP Buffer internally handled by receiver.

20. 20 RCP: Congestion Control  TCP: CWND limits amount of unacknowledged data  RCP: CWND limits number of outstanding REQ packets from receiver  Slow start, congestion avoidance, fast retransmit, fast recovery etc. same as TCP  Receiver adjusts the CWND based on channel conditions Requested DATA arrives: increase CWND (AI) Wireless error detected: sleep or set CWND=0 or.. Wired link error detected: decrease CWND (MD)

21. 21 RCP: Reliability  TCP: Receiver performs re-sequencing Sender ensures reliability  RCP: Receiver has full control on data Any loss recovery mechanism can be used that optimizes the wireless environment

22. 22 RCP: Is that all?  Extension: R 2 CP, the Radial RCP  Enables functionality gains in multi-homed systems  Abstracts a single interface to upper layers

23. 23 More about R 2 CP  Receiver centric  Manages multiple RCP instances  Maintain state specific details of each RCP  Exports connection & reliability to upper layers Single connection Multiple interfaces  Utilizes underlying RCP congestion control  Packet scheduling between different RCPs

24. 24 R 2 CP: What can it do?  New functionality gains Seamless handoffs between interfaces Server migration Bandwidth aggregation

25. 25 OUTLINE of Presentation  Problem Statement  Quick TCP Review  Case for RCP  Protocol Details  Performance  Discussion  Q&A

26. 26 Sounds good. Will it work?  What to look for? TCP friendly? Loss recovery? Scalable Congestion control? Power Management?  Ns-2 simulator  20 data flows, reverse flows, varying RCP:TCP

27. 27 RCP: Performance (1) TCP Friendliness: TCP Throughput same irrespective of RCP:TCP

28. 28 RCP: Performance (2) TCP Friendliness: Throughput constant with reverse traffic

29. 29 RCP: Performance (3) Error recovery: With ELN, MH can determine exact cause of loss, hence better throughput

30. 30 RCP: Performance (4) Power Management Transmit=1.65W,Recv=1.4W, Sleep=0.045W Vary channel condition using a statistical model (good & bad states) Check-(Sleep/Wakeup)-(transmit/receive) cycle

31. 31 R 2 CP: Performance

32. 32 OUTLINE of Presentation  Problem Statement  Quick TCP Review  Case for RCP  Protocol Details  Performance  Discussion  Q&A

33. 33 So, what do we think about RCP & R 2 CP?  Sound arguments for receiver-centric transport  Hybrid RCP-TCP protocol (same binary) for upstream traffic  Error recovery still needs BS change  Unanswered questions How can sender guarantee fairness to multiple users? How to address REQ attacks? How bad it will be to the NW if the receiver sends REQ and, before data is delivered, goes to sleep on seeing bad channel?

34. 34 OUTLINE of Presentation  Problem Statement  Quick TCP Review  Case for RCP  Protocol Details  Performance  Discussion  Q&A