1. RCP (Receiver Centric Transport Protocol)
Group 6
John Paul Kalapurakal
Ronak Kamdar

2. Introduction
Transport protocol for mobile hosts with heterogeneous wireless interfaces.
Address the characteristics of the last hop wireless link.
Uses intelligence of mobile hosts adjacent to the wireless link to increase performance.
Performance improvements
Functionality improvements
Protocol intended for mobile hosts who can connect to the internet using different technologies like WLAN or WWAN etc. They have become multi-homed with 2 or more interfaces which may belong to different autonomous domains
These protocols are designed to address characteristics of last hop wireless link like random errors, RTT variations, blackouts, handoffs etc
Because mobile host is more closer to the wireless link, it has more information locally than the server/corresponding host. It is designed as a TCP clone.
Performance improvements: congestion control, loss recovery and power management
Functionality improvements: Seamless handoffs, server migration, bandwidth aggregation

3. Background and Motivation
Various TCP protocols are introduced but all of them sender centric.
Mobile host have become multi-homed with various heterogeneous wireless interfaces.
Hence it is desirable that the receiver control how much and which data to receive from the sender.
Various transport protocols have been introduced but all of them sender centric i.e. sender performs important functions like congestion control, reliability etc. Receiver participates only by providing useful feedback
Since mobile hosts have various options to choose from, the receiver should be given more responsibility and autonomy

4. Scenario 1. This is the scenario used to discuss performance issues
2. Data is sent from the server in the backbone network to the mobile host

5. Why receiver centric? Loss recovery Congestion Control
Power Management
Seamless Handoffs
Server Migration
Bandwidth Aggregation
The key question is why receiver centric?
The paper evaluates it based on performance gains and functionality gains
We assume that in a receiver centric protocol the receiver controls how much data it should receive and which data it should receive

6. Loss Recovery TCP limitations RCP advantages
Assumes all loses are due to congestion
Finite overhead
Wide variety of feedback
RCP advantages
Avoid feedback overhead and latency
Server is independent of the changes
TCP assumes all loses are due to congestion and there are unnecessary window cut downs
Also, providing feedback from receiver incurs finite overhead
Also, there are many link variables which have to be accommodated in the headers in the feedback packet
RCP avoids overhead and latency by being responsive to the dynamics of the wireless link using locally available information
The server is independent of the changes in the wireless link and hence intelligence is only added to the mobile host

7. Congestion Control TCP limitations RCP advantages
Backbone server needs to support all possible congestion control mechanisms
Leads to lack of employability
Not scalable
RCP advantages
Simplified and transparent congestion control
A mobile host should ideally use the congestion control mechanism for the specific wireless network it has access to.
Multiple hosts connect to one server. In TCP, server has to maintain all control mechanisms, which is not scalable.
In RCP, the sender is independent of the control mechanism that the receiver uses and hence it is more simplified.

8. Power Management TCP limitations RCP advantages
Power saving decision cannot be made locally
Feedback will face noise and overhead for retransmissions
RCP advantages
Power saving decision can be made locally
Greater degree of flexibility
Traditionally we evaluate TCP based on performance and not on energy efficiency
TCP SACK is performs the best but provides lowest energy efficiency
It is energy efficient to cut down window size when there are wireless losses because packets immediately retransmitted after loss will most likely be lost again
Hence, retransmission policy should be adjusted according to channel dynamics
IMPLEMENTING IT IN TCP HAS THE FOLLOWING LIMITATIONS
Cannot decide locally because sender does congestion control
Feedback will face the same noise in the reverse path and also added overhead of retransmissions
RCP on the other hand, can make decisions locally because receiver decides what to receive and how much
Also, it allows for greater degree of flexibility as the sender is not involved

9. Seamless Handoffs TCP limitations RCP advantages Feedback overhead
Receiver can accurately control which and how much data to send through each pipe (stream)
When there is an overlap of coverage areas and when a mobile hosts handoffs from one interface to another, IP address changes which is handled by Mobile IP, which creates prolonged delay for registration with the home agent which introduces packet losses
One solution is to inform the sender of the handoff decision. We know that RCP is better in terms of feedback than TCP
Another solution is to create multiple streams, and use them simultaneously without experiencing congestion stall as long as the link layer allows it. RCP can control which and how much data it can receive through each pipe and hence it is preferable

10. Server Migration TCP limitations RCP advantages
States maintained at the server for congestion control and loss recovery need to be transferred to another server
A window’s worth of data buffered at the receiver needs to be flushed after migration
RCP advantages
States maintained at receiver, hence overheads minimized
No need to flush out data since receiver has access to buffer and decides which data to receive
A mobile host initially uses WWAN to connect to Yahoo online server … After vertical handoff it cannot connect to original proxy server due to firewalls … however, it can connect to a different server through WLAN
Hence, the need for server migration which requires synchronization
TCP: States have to transferred from one server to another
TCP: Data needs to be flushed because mobile host can acknowledge data that the sender has not yet sent (resequencing)
RCP: States maintained at receiver and hence overheads are minimized
RCP: No need to discard data since receiver has control over flow of data

11. Bandwidth Aggregation
TCP Limitations
Requires explicit coordination between geographically spaced servers
RCP advantages
Multipoint-to-point bandwidth aggregation since the receiver is the center of control
Does not require explicit coordination between senders
When coverage areas overlap, mobile hosts can use multiple interfaces simultaneously
Mobile hosts want to leverage multiple active interfaces in an opportunistic fashion by selecting which one to keep or not to keep based on link dynamics (multipoint to point)
TCP: Requires explicit coordination between geographically spaced servers
RCP: No coordination since receiver is the center of control

12. Protocol

13. REQ-DATA Handshake
TCP uses the cumulative acknowledgements for achieving robustness to losses.
RCP uses same method but allows for two modes
Cumulative mode
Pull Mode
The receiver by default uses the cumulative mode to requests for new data, and uses the pull mode only for retransmission of requests. When the sender receives a request with the pull flag set, it sends only the data segment indicated in the packet header. Otherwise, the sender cumulatively transmits data from SND.NXT that has not been sent yet.

14. Connection Management
Very similar to TCP
SYN – SYN+ACK – ACK handshake
Difference comes in once the connection has been established.
The RCP receiver transmits the first REQ with the initial sequence number.

15. Congestion Control
Adopts the window based congestion control as used in TCP.
The slow start, congestion avoidance, fast retransmit, and fast recovery phases are triggered and exited in the same fashion as in TCP
In RCP, the receiver performs congestion control and maintains the congestion control parameters
In TCP, the size of the congestion window limits the amount of unacknowledged DATA in the network, and the sender uses the return of ACKs to trigger the progression of the congestion window
In RCP, the size of the congestion window limits the amount of outstanding REQs in the network, and the receiver uses the return of DATA to trigger the progression of the congestion window.

16. Flow Control
In RCP, a request is sent out only if the corresponding data, once received, does not cause buffer overflow at the receiver.
The receiver maintains the receive buffer, and has total control over how much data the sender can send, flow control is internal to the receiver.
TCP relies on the window advertisement from the receiver to perform flow control
RCP also needs a window field (SEG.DEQ) in the packet header to inform the sender of the highest in-sequence data received so far (which can be calculated at the sender using SEG.REQ - SEG.DEQ), thus allowing the sender to purge such data from its send buffer.

17. Reliability
RCP the re-sequencing and reliability functionalities are collocated at the receiver.
In TCP, reliability is performed at the sender while re-sequencing is performed at the receiver.
In RCP the receiver has direct access to the receive buffer, and hence it can timely and accurately perform loss detection and loss recovery
RCV.NXT is conveyed as the cumulative ACK to the sender for it to perform loss detection. However, RCV.NXT conveys limited information about the state of the receive buffer, and hence early implementations of TCP that rely on the cumulative ACK for performing loss detection, suffer from recovering at most one loss per round-trip time, in addition to incurring frequent timeouts

18. TCP friendliness

19. TCP friendliness

20. Loss Recovery

21. Congestion Control

22. Power Management

23. Related Work
Other protocols are focusing on increasing receiver participation but still sender centric.
WebTP
Used for optimization of Web data transfer
Receiver centric
Primarily designed for wired network.
RCP Extensions based on traffic scenarios

24. Critique
Unique perceptive and fits well with the needs of a mobile host with heterogeneous wireless interfaces.
Comprehensive transport layer solution

25. Summary and Conclusions
Tested using both packet level simulations and real internet experiments.
Provided better:
Reliability
Congestion Control
Power Management