360 likes | 550 Views
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.
E N D
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 • Problem Statement • Quick TCP Review • Case for RCP • Protocol Details • Performance • Discussion • Q&A
OUTLINE of Presentation • Problem Statement • Quick TCP Review • Case for RCP • Protocol Details • Performance • Discussion • Q&A
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?
OUTLINE of Presentation • Problem Statement • Quick TCP Review • Case for RCP • Protocol Details • Performance • Discussion • Q&A
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
Typical wireless setup • FH: Fixed Host • BS: Base Station • MH: Mobile Host • Assumption: Most data flow is from FH to MH
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!!
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!
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
OUTLINE of Presentation • Problem Statement • Quick TCP Review • Case for RCP • Protocol Details • Performance • Discussion • Q&A
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
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
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
Therefore… More appropriate to let receiver handle • How Much data? • Which data?
OUTLINE of Presentation • Problem Statement • Quick TCP Review • Case for RCP • Protocol Details • Performance • Discussion • Q&A
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
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
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.
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)
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
RCP: Is that all? • Extension: R2CP, the Radial RCP • Enables functionality gains in multi-homed systems • Abstracts a single interface to upper layers
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
R2CP: What can it do? • New functionality gains • Seamless handoffs between interfaces • Server migration • Bandwidth aggregation
OUTLINE of Presentation • Problem Statement • Quick TCP Review • Case for RCP • Protocol Details • Performance • Discussion • Q&A
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
RCP: Performance (1) TCP Friendliness: TCP Throughput same irrespective of RCP:TCP
RCP: Performance (2) TCP Friendliness: Throughput constant with reverse traffic
RCP: Performance (3) Error recovery: With ELN, MH can determine exact cause of loss, hence better throughput
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
OUTLINE of Presentation • Problem Statement • Quick TCP Review • Case for RCP • Protocol Details • Performance • Discussion • Q&A
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?
OUTLINE of Presentation • Problem Statement • Quick TCP Review • Case for RCP • Protocol Details • Performance • Discussion • Q&A