RCP (Reception Control Protocol)

advertisement

RCP

(Reception Control Protocol)

heterogeneous Wireless Interfaces

MOBICOM 2003

H. Hsieh, K. Kim, Y. Zhu, and R. Sivakumar, Georgia Institute of Technology

Presented for ECE299.02 by Thilee Subramaniam

1

OUTLINE of Presentation

 Problem Statement

 Quick TCP Review

 Case for RCP

 Protocol Details

 Performance

 Discussion

 Q&A

2

OUTLINE of Presentation

 Problem Statement

 Quick TCP Review

 Case for RCP

 Protocol Details

 Performance

 Discussion

 Q&A

3

What is the Problem?

 Wired: low BER

 Wireless: high BER (channel error, Fading,

Handoffs)

 TCP

 was originally proposed for wired networks

 assumes losses are due to congestion

 corrective measures address congestion only!

 TCP over wireless: does not perform well

 TCP over wireless: can it be improved?

4

OUTLINE of Presentation

 Problem Statement

 Quick TCP Review

 Case for RCP

 Protocol Details

 Performance

 Discussion

 Q&A

5

TCP Recap

 End-to-end argument

 Cater to the end-point specific requirements sender cwnd

1 receiver data packet

2

ACK

 Flow Control

 Congestion Control

 Various flavors of TCP

 Reliable in-order delivery

3

4

7

8

5

6

6

Typical wireless setup

 FH: Fixed Host

 BS: Base Station

 MH: Mobile Host

 Assumption: Most data flow is from FH to MH

7

TCP and wireless networks

 Sender does Congestion control

 Sender reacts to feedback from receiver

 Assumption: any loss is due to congestion

 BS <-> MH connection highly error prone

 MH to FH feedback takes time and resources

 Sender ends up sending less data!

 Reduces network performance. Not Good!!

8

Attempts for Wireless friendly TCP

 Snoop

 Link-layer of BS buffers un-ACKed data and DupACKs

 Retransmit Data, Suppress DupACK from MH to FH

 Prevent FH from decreasing CWND drastically

 Issues: IPSec incompatibility, mess with RTT estimate on

FH, requires change in BS which is difficult

 WTCP

 Do local recovery like Snoop

 BS adds timestamp to ACKs from MH to FH, informing FH to correctly estimate RTT

 Issues: require change in BS, assume all losses are due to errors while congestion is possible!

9

Attempts for Wireless friendly TCP..

 ELN (Explicit Loss Notification)

 BS sets an ELN bit in DupACK header

 FH does not decrease CWND for DupACK with ELN set

 Issue: Still need BS change, consumes resources for feedback

 Freeze-TCP

 Moves intelligence to MH

 Primary focus: handoff; FH still does Congestion Control

 Syndrome

 BS simply adds the number of packets sent to MH

 MH can differentiate W loss and WL loss

 Handoff is still a problem

10

OUTLINE of Presentation

 Problem Statement

 Quick TCP Review

 Case for RCP

 Protocol Details

 Performance

 Discussion

 Q&A

11

Motivation for Receiver-Centric Protocol

 Why does Wireless TCP under-perform?

 Sender over-reacts by reducing CWND when not necessary

 Why cannot Receiver provide more information?

 Magnitude

 Cost

 Latency

 The closer the problem solver is to the problem, the easier it is to solve

 Client specific congestion control mechanisms

 Sender cannot provide custom mechanisms

 Generic mechanism cannot make everyone happy

12

More Reasons

 Multi-homed Devices

(Notebook with Wifi, WIMAX, and 3G cards)

 Technology specific congestion control schemes may be required.

 Receiver-centric more useful

 Users can move from one technology coverage-area to another

 Receiver-centric transport protocol can better handle handoffs

13

Even More Reasons..

 Power issue with mobile devices

 Limited Battery

 Wireless Transmission/Reception consume high

% energy

 Wireless errors happen in bursts

 Need to cut down transmission

 Costly to inform the sender to cut down CWND

 Receiver dropping packets: affects throughput

14

Therefore…

More appropriate to let receiver handle

 How Much data?

 Which data?

15

OUTLINE of Presentation

 Problem Statement

 Quick TCP Review

 Case for RCP

 Protocol Details

 Performance

 Discussion

 Q&A

16

TCP: Connection and Data transfer

SYN

ISN= X

1

SYN

2

ISN= Y ACK= X +1

ACK= Y +1

3

DATA X+3

4

ACK= X +4

5

17

RCP: Transposition of TCP

SYN

ISN= X

1

SYN

2

ISN= Y ACK= X +1

 Either party can initiate connection

 Receiver initiates with transfer

 Cumulative mode

 Pull mode

ACK= Y +1

3

REQ

4

Sender DATA

5

Receiver

18

RCP: Flow Control

 In TCP, receiver advertises its buffer size

 Sender makes sure that sent data is limited by this

 No need to advertise this in RCP

 Buffer internally handled by receiver.

19

RCP: Congestion Control

 TCP: CWND limits amount of unacknowledged data

 RCP: CWND limits number of outstanding REQ packets from receiver

 Slow start, congestion avoidance, fast retransmit, fast recovery etc. same as TCP

 Receiver adjusts the CWND based on channel conditions

 Requested DATA arrives: increase CWND (AI)

 Wireless error detected: sleep or set CWND=0 or ..

 Wired link error detected: decrease CWND (MD)

20

RCP: Reliability

 TCP:

 Receiver performs re-sequencing

 Sender ensures reliability

 RCP:

 Receiver has full control on data

 Any loss recovery mechanism can be used that optimizes the wireless environment

21

RCP: Is that all?

 Extension: R 2 CP, the Radial RCP

 Enables functionality gains in multi-homed systems

 Abstracts a single interface to upper layers

22

More about R 2 CP

 Receiver centric

 Manages multiple RCP instances

 Maintain state specific details of each RCP

 Exports connection & reliability to upper layers

 Single connection

 Multiple interfaces

 Utilizes underlying RCP congestion control

 Packet scheduling between different RCPs

23

R 2 CP: What can it do?

 New functionality gains

 Seamless handoffs between interfaces

 Server migration

 Bandwidth aggregation

24

OUTLINE of Presentation

 Problem Statement

 Quick TCP Review

 Case for RCP

 Protocol Details

 Performance

 Discussion

 Q&A

25

Sounds good. Will it work?

 What to look for?

 TCP friendly?

 Loss recovery?

 Scalable Congestion control?

 Power Management?

 Ns-2 simulator

 20 data flows, reverse flows, varying RCP:TCP

26

RCP: Performance (1)

TCP Friendliness: TCP Throughput same irrespective of RCP:TCP

27

RCP: Performance (2)

TCP Friendliness: Throughput constant with reverse traffic

28

RCP: Performance (3)

Error recovery: With ELN, MH can determine exact cause of loss, hence better throughput

29

RCP: Performance (4)

Power Management

 Transmit=1.65W,Recv=1.4W, Sleep=0.045W

 Vary channel condition using a statistical model (good & bad states)

 Check-(Sleep/Wakeup)-(transmit/receive) cycle

30

R 2 CP: Performance

31

OUTLINE of Presentation

 Problem Statement

 Quick TCP Review

 Case for RCP

 Protocol Details

 Performance

 Discussion

 Q&A

32

So, what do we think about RCP & R 2 CP?

 Sound arguments for receiver-centric transport

 Hybrid RCP-TCP protocol (same binary) for upstream traffic

 Error recovery still needs BS change

 Unanswered questions

 How can sender guarantee fairness to multiple users?

 How to address REQ attacks?

 How bad it will be to the NW if the receiver sends REQ and, before data is delivered, goes to sleep on seeing bad channel?

33

OUTLINE of Presentation

 Problem Statement

 Quick TCP Review

 Case for RCP

 Protocol Details

 Performance

 Discussion

 Q&A

34

Download