1. Group 5 ECE 4605 Neha Jain Shashwat Yadav
A Receiver Centric Transport Protocol for Mobile hosts with Heterogeneous Wireless Interfaces
Group 5
ECE 4605
Neha Jain
Shashwat Yadav

2. Outline Why Receiver Centric? RCP R2CP Testbed results Critique
Summary

3. Why Receiver Centric? TCP – Sender centric >> WHAT??
Sender decides congestion control, reliability
Receiver only provides feedback in form of ACKs.
RCP – Receiver Centric
Location intelligence at MH
Receiver decides
“ How Much”
“ What” data to request for.
Provides Mechanism for
Performance Gains Functionality Gains
- Loss recovery Seamless Handoffs
- Congestion Control Server Migration
- Power Management Bandwidth Aggregation

4. How RCP works Receiver clone of TCP. Sender Receiver
SYN
SYN+ACK
Three Way handshake
ACK+1
REQ
DATA
REQ
REQ
DATA
FIN M
Two half closes
ACK M+1
FIN N
ACK N+1

5. Loss Recovery TCP RCP Assumes all losses are due to congestion.
Performance degradation incase of channel errors, delay variations, blackouts, handoffs.
Prior approaches
Provide TCP information to distinguish causes of
losses. (RTT samples etc.)
Feedback incurs overhead.
RCP
Mobile host has first hand knowledge of cause of loss.
Responsive to dynamics of wireless link.

6. Congestion Control TCP RCP
Different wireless topologies use different mechanisms.
WLAN, WWAN, Satellite Networks
Servers need to implement all mechanisms.
RCP
Receiver performs congestion control
Different MH can implement different algorithms depending on networks

7. Power Management Channel errors tend to be bursty (correlated) TCP RCP
Energy conserving to cut down window size.
TCP
Persistently accesses the channel in hostile conditions.
Cannot make the best power saving decisions.
Feedback information suffers same problem.
RCP
More accurate knowledge of channel conditions.
Control transmission/retransmission decisions.

8. RCP : Complete Control Congestion control –
Data is preceded by REQ
Cumulative mode – default
PULL mode – ‘RE’requests (SACK)
Sack options. ( 3 blocks sent as part of REQ header)
Flow Control – internal >> WHY ??
Sender clears cache by  SEG.REQ – SEG.DEQ
Sender
Receiver
REQ
DATA
Congestion window reduced
Re-REQ
Reliability of Re-Req’s insured by use of SACK options
DATA
SACK

9. Performance Gains
Comparison with improved TCP-SACK as well as TCP-NewReno.
TCP friendly
Performs much better than TCP in a wired-wireless scenario with optimizations
RCP-ELN better than TCP-ELN
RCP-STP better than TCP-STP

10. R2CP : Radial RCP Maintains multiple states of RCP
Allows for each interface to choose the CCM
WHY different CCM?
Ideal solution for migration, as states can co-exist
Functionalities Decoupled
R2CP decides ‘What’ data to request
RCP pipes decide how much data it can request
Packet Rescheduling
Multiplexing of pipes with mismatched characteristics
Bandwidth, Loss rate, Delay
R2CP assigns sequence of requests
Controls features like I/O from IP
Converts local sequence number to global sequence number

11. Packet Scheduling Maintains key data structures Commands Binding
Maintains mapping between local sequence numbers and global sequence numbers
Pending
Range of sequence numbers yet to be requested
Rank
Timestamp reflective of when to expect the data
Active
Adds a pipe to this structure in event of full buffer
Commands
open / established
close / closed
send / recv
loss / update
resume

12. R2CP : Protocol functioning
R2CP decides to initiate a new connection
FREEZE RCP connection
Space in buffer
open( ) to RCP pipe
established( ) by RCP pipe
resume( ) to RCP pipe
Entry deleted in rank
Recv_buffer full
Enqueue data in Recv_buffer A
send( ) request by RCP pipe j with seq. number s at time T
Finds corresponding pipe and relates sequence number in binding structure
Locates rank k of the segment, compares with T + RTTj
Passes sequence number to RCP pipe using recv( )
Finds segment in pending updates entry
RCP will update its own states A
close( ) to RCP pipe
Inserts entry in rank as
 T+2*RTTj
closed( ) by RCP pipe

13. R2CP : protocol Functioning contd.
RCP pipe discovers loss.
Loss( ) call to R2CP
Unbinds the sequence number in bind
Inserts sequence number in pending
Deletes from rank

14. Supporting Heterogeneous Interfaces
Seamless Handoff’s
Can use multiple RCP pipes.
Server Migration
Connect through different interface

15. Supporting Heterogeneous Interfaces
Bandwidth Aggregation
Testbed Scenario
Testbed Result

16. Performance of R2CP Scheduling
 Bandwidth Mismatch
RTT Mismatch 
 Buffer 75% full
>> WHY??

17. Critique Mobile host overheads Security Consequences Sender’s side
R2CP maintains multiple states
Different structures
Paper compares RCP receiver to TCP sender
Security Consequences
Aggressive receiver?
Flooding sender with REQs.
Sender’s side
How does sender recognize an REQ?
So requires implementation of RCP at every server?

18. Summary Receiver Centric Better suited for the ‘last hop’
RCP is a TCP clone
For heterogeneous interface provides
Seamless handoffs
Network specific CCM
Server migration
Bandwidth aggregation