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

Outline Why Receiver Centric? RCP R2CP Testbed results Critique Summary

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

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

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.

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

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.

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

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

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

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

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

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

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

Supporting Heterogeneous Interfaces Bandwidth Aggregation Testbed Scenario Testbed Result

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

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?

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