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

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

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

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

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

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

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.

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

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

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

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

Protocol

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.

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.

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.

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.

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

TCP friendliness

TCP friendliness

Loss Recovery

Congestion Control

Power Management

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

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

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