1. H. Hsieh, K. Kim, Y. Zhu and R. Sivakumar ACM Mobicom 2003
A Receiver-Centric Transport Protocol for Mobile Hosts with Heterogeneous Wireless Interfaces
H. Hsieh, K. Kim, Y. Zhu and R. Sivakumar
ACM Mobicom 2003

2. Addressed Issues Loss discrimination/recovery Power management
Seamless handoffs
Server migration
Bandwidth aggregation
Wired-wireless Network

3. Proposed Solution
A receiver-centric TCP clone – RCP (Reception Control Protocol)
A multi-state extension of RCP – Radial RCP (R2CP) for multi-homed hosts

4. New Contribution
Cogent argument in favor of receiver-centric approaches
A holistic approach
A generic transpositional framework for transport protocols

5. Core Thesis Behind Proposal
The wireless last link is crucial
Receiver has accurate knowledge of channel conditions
Receiver has knowledge of all its interfaces
Receiver can handle functionality without making changes at the sender

6. TCP: Design Assumptions
TCP: designed for wired networks
Transmission errors very rare
Most losses due to congestion
TCP: invokes Congestion Control on packet loss
Reduce size of congestion window
Reduce value of ssthresh (slow start threshold)
Wireless links violate assumptions!

7. Related Prior Work (TCP-over-wireless)
End-to-end approaches
Involving both sender and receiver e.g. WTCP
Purely Sender-centric e.g. TCP-Westwood
Purely Receiver-centric: WebTP
Link-layer approaches
Reliable link layer
Split-Connection/Base-Station Oriented Approaches
e.g. Indirect-TCP, Snoop etc.
Misc.
e.g. Loss Discrimination using AQM, Explicit Notification etc.

8. Related Prior Work
B/W aggregation:
pTCP
R- MTP

9. RCP/R2CP: Where they stand
WebTP
pTCP
B/W aggregation by encapsulating multiple connections with a single wrapper
Pure receiver-centric approach
RCP/R2CP
RCP shares design philosophy with WebTP
R2CP //r to pTCP but needs no change to RCP sender

10. RCP: Protocol Overview
Connection Establishment
3-way handshake as a TCP
SYN
SYN+ACK
ACK
Sender
Receiver

11. 3 out-of-order DATA segments->
RCP Protocol Overview
Data Transfer:
REQ-DATA instead of DATA-ACK
REQ in 2 modes
Cumulative
Pull
In CUM or PULL mode
REQ
DATA
3 out-of-order DATA segments->
Fast Retransmit
Sender
Receiver

12. Window moves forward on DATA receipt
RCP Protocol Overview
Congestion Window maintained at Receiver
Receiver can react to packet loss based on its knowledge of channel conditions
Window moves forward on DATA receipt

13. RCP Operation RCP Sender RCP Receiver SND.NEXT RCV.NEXT REQ.NEXT
SEG.SEQ
RCV.NEXT
REQ.NEXT
Reliability
NextReq
Recv/Req Buffer
SEG.DEQ
Flow
Control
SEG.SEQ
RWND
SND.NEXT
Loss/Progress
SEG.REQ +
SEG.DEQ
Send Buffer
SEG.REQ
Congestion
Control
CWND
RCP Sender
RCP Receiver

14. RCP Performance Analysis
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 STP
Simulated Topology

15. RCP Performance Analysis
Much better power-consumption figures if power management enabled in RCP with about the same throughput
Shows robustness to REQ losses

16. Multi-Homed Mobile Hosts: Opportunities and Challenges
Multiple Heterogenous Interfaces:
Survivability of communication
B/W Aggregation
Issues:
Seamless Migration
Intelligent Data Striping

17. Radial RCP – A Multi-State Extension
Provides an encapsulating entity R2CP that manages multiple RCP pipes
R2CP
RCP 1
RCP k
RCP 2

18. R2CP Overview Functionality Division:
R2CP - reliability and flow control
Individual RCPs - congestion control (can use interface-specific mechanisms)
Separate global and per-pipe sequence spaces
RCPs essentially maintain relevant state and prepare and pass headers to R2CP
Single aggregate connection might comprise connections with multiple senders (server replicas)

19. R2CP R2CP R2CP open est close send RCP RCP Connection Management
Mark as active, might send FREEZE if rwnd full
send
RCP
RCP
Connection Management
Data Transfer

20. R2CP Architecture Application Application IP IP RCP (sender)
R2CP (engine)
binding
pending
RCP (receiver)
Send Buffer
rank
active
Recv Buffer IP IP

21. R2CP Operation
Use of binding structure to map between global and per-pipe sequence nos.
Binding may be changed if packet loss happens – helps avoid stalling of all pipes due to congestion/blackout in one!

22. R2CP Operation Use of Rank Structure for Effective Striping
When sending REQ for Segment i on Pipe j, store T(i)+2*RTT(j) in structure
When Segment i is received (say at time T): find rank k of T+RTT(j) in structure and schedule k’th pending segment on Pipe j
T(i)+RTT(j)
T(i+1)+RTT(k)
DATA(i)
DATA(i+1)
T(i+1)+2*RTT(k)
T(i)+2*RTT(j)
REQ(i)
REQ(i+1)
T(i)
T(i+1)

23. Performance Analysis ns-2 based emulation + simulations
Testbed: 2 APs, 1 laptop with 2 interfaces, 2 desktops (servers)

24. Testbed Results
SEQ #
TIME
Bandwidth Aggregation

25. Simulation Results: Vary B/W Diff.
Aggregate Throughput
Pipe 1 bandwidth

26. Simulation Results: Vary RTT Diff.
Aggregate Throughput
Pipe 1 RTT

27. Simulation Results: Vary RTT Diff.
Out-of-Order Index (%)
Pipe 1 RTT

28. Misc. Discussions Overhead not prohibitive
For reverse direction data-flow e.g. mobile server, recommend a TCP-RCP hybrid
Extending RCP for rate-controlled traffic is an option
Receiver can switch between reliable/unreliable mode of delivery

29. Critical Review
Noteworthy feature of performance analysis of RCP:
Plain RCP shows only marginal improvement over TCP
However RCP with add-ons performs significantly better e.g. RCP-ELN and RCP-STP
Value of receiver-centric approaches?
Immediate and unambiguous response to observed conditions
No comparison with other B/W aggregation protocols like pTCP

30. Critical Review
All decisions relegated to mobile host but is the mobile host always equipped to make the right decision?
How is channel state accurately monitored?
Requires an intelligent application (and possibly an effective Service Location Protocol) to make good use of RCP/R2CP
Security Implications:
What if receiver misbehaves?
Sender flooded with REQs
Undesirable as sender is a Server!