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

 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