1 / 34

RCP (Reception Control Protocol)

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. OUTLINE of Presentation.

ilyssa
Download Presentation

RCP (Reception Control Protocol)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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. OUTLINE of Presentation • Problem Statement • Quick TCP Review • Case for RCP • Protocol Details • Performance • Discussion • Q&A

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

  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. OUTLINE of Presentation • Problem Statement • Quick TCP Review • Case for RCP • Protocol Details • Performance • Discussion • Q&A

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

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

  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. 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. 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. OUTLINE of Presentation • Problem Statement • Quick TCP Review • Case for RCP • Protocol Details • Performance • Discussion • Q&A

  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. 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. 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. Therefore… More appropriate to let receiver handle • How Much data? • Which data?

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

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

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

  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. 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. 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. RCP: Is that all? • Extension: R2CP, the Radial RCP • Enables functionality gains in multi-homed systems • Abstracts a single interface to upper layers

  23. More about R2CP • 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. R2CP: What can it do? • New functionality gains • Seamless handoffs between interfaces • Server migration • Bandwidth aggregation

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

  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. RCP: Performance (1) TCP Friendliness: TCP Throughput same irrespective of RCP:TCP

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

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

  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. R2CP: Performance

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

  33. So, what do we think about RCP & R2CP? • 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. OUTLINE of Presentation • Problem Statement • Quick TCP Review • Case for RCP • Protocol Details • Performance • Discussion • Q&A

More Related