Transcript 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
1
OUTLINE of Presentation







Problem Statement
Quick TCP Review
Case for RCP
Protocol Details
Performance
Discussion
Q&A
2
OUTLINE of Presentation







Problem Statement
Quick TCP Review
Case for RCP
Protocol Details
Performance
Discussion
Q&A
3
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?
4
OUTLINE of Presentation







Problem Statement
Quick TCP Review
Case for RCP
Protocol Details
Performance
Discussion
Q&A
5
TCP Recap
sender
 End-to-end argument
cwnd
 Cater to the end-point
specific requirements
1
2
 Flow Control
 Congestion Control
3
4
 Reliable in-order delivery
5
6
7
8
 Various flavors of TCP
receiver
data packet
ACK
6
Typical wireless setup
 FH: Fixed Host
 BS: Base Station
 MH: Mobile Host
 Assumption: Most data flow is from FH to MH
7
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!!
8
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!
9
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
10
OUTLINE of Presentation







Problem Statement
Quick TCP Review
Case for RCP
Protocol Details
Performance
Discussion
Q&A
11
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
12
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
13
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
14
Therefore…
More appropriate to let receiver handle
 How Much data?
 Which data?
15
OUTLINE of Presentation







Problem Statement
Quick TCP Review
Case for RCP
Protocol Details
Performance
Discussion
Q&A
16
TCP: Connection and Data transfer
SYN
ISN=X
1
SYN
2
ISN=Y ACK=X+1
3
DATA X+3
4
ACK=X+4
5
time
ACK=Y+1
17
RCP: Transposition of TCP
SYN
ISN=X
1
Sender
ACK=Y+1
3
REQ
4
DATA
5
time
SYN
2
ISN=Y ACK=X+1
 Either party can
initiate connection
 Receiver initiates
with transfer
 Cumulative mode
 Pull mode
Receiver
18
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.
19
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)
20
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
21
RCP: Is that all?
 Extension: R2CP, the Radial RCP
 Enables functionality gains in multi-homed systems
 Abstracts a single interface to upper layers
22
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
23
R2CP: What can it do?
 New functionality gains
 Seamless handoffs between interfaces
 Server migration
 Bandwidth aggregation
24
OUTLINE of Presentation







Problem Statement
Quick TCP Review
Case for RCP
Protocol Details
Performance
Discussion
Q&A
25
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
26
RCP: Performance (1)
TCP Friendliness: TCP Throughput same irrespective of RCP:TCP
27
RCP: Performance (2)
TCP Friendliness: Throughput constant with reverse traffic
28
RCP: Performance (3)
Error recovery: With ELN, MH can determine exact cause of loss,
hence better throughput
29
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
30
R2CP: Performance
31
OUTLINE of Presentation







Problem Statement
Quick TCP Review
Case for RCP
Protocol Details
Performance
Discussion
Q&A
32
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?
33
OUTLINE of Presentation







Problem Statement
Quick TCP Review
Case for RCP
Protocol Details
Performance
Discussion
Q&A
34