Transcript Routing in Sensor Networks: Directed Diffusion and other

TCP over Wireless Links
ECE 256
Spring 2009
1
Today’s Discussions
 Setting up the context (recap)
 MAC (radios, HTP, antennas, rate/power/CS control), routing
 Motivating a Transport Layer
 The e2e argument
 The basics of flow control and congestion control
 From wireline to wireless
 Peek into the large gamut of research in wireless TCP
 Snoop, ELN, Vegas, Reno, Paris, Hollywood (just kidding !!)
 Performance over wireless links
 What’s hot now ?
2
Recall 1: PHY and MAC
MAC
MAC
PHY
PHY
• Spread Spectrum radios (DS and FH)
•
•
•
•
•
RTS/CTS and Carrier Sensing for Hidden Terminals
Directional antennas to reduce interference
Rate control to extract max capacity from available SINR
Power control for spatial reuse & energy savings – topology control
TDMA scheduling, multi-channel use, encryption security
… and many more
3
Recall 2: Network Layer
Routing
Routing
Routing
Routing
Routing
• The first view of the network
• Coping up with (uncontrolled) user mobility
-Flooding the network reactively, or proactive updation
• Mobile IP, coping with handoffs, etc.
• Ad hoc routing – discovery, optimal metric, maintenance, caching
• Secure routing – Routes bypassing malicious nodes
4
We have a route, now what ?
TCP
TCP
NETWORK
• Transport packets quickly and reliably over this network
• Network properties often unknown (or difficult to track)
- Where is the congestion ? How much cross traffic ?
- What is the bottleneck bandwidth ?
- How much buffers at intermediate nodes ?
 Motivation for end to end TCP
5
The End to End Argument [Reed,Clark]
“The function in question can completely and correctly
be implemented only with the knowledge and help of
the application standing at the end points of the
communication system. Therefore, providing that
questioned function as a feature of the
communication system itself is not possible.”
In other words,
as a middle man, don’t attempt to do it, if you cannot do it completely.
Let the end point handle it completely !!
Caveat: Middle-man involvment OK for performance optimization
Question is: Who is the end point ? TCP ? Application layer ? Human user ?
… the debate goes on
6
Some transmission methods
 Stop & Wait
 Pipelined
 Go Back N
 Selective Repeat
7
Stop-and-wait operation
sender
receiver
first packet bit transmitted, t = 0
last packet bit transmitted, t = L / R
first packet bit arrives
last packet bit arrives, send ACK
RTT
ACK arrives, send next
packet, t = RTT + L / R
U
sender
=
L/R
RTT + L / R
=
.008
30.008
= 0.00027
microsec
onds
8
Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-to-beacknowledged pkts
 range of sequence numbers must be increased
 buffering at sender and/or receiver
 Two generic forms of pipelined protocols: go-Back-N, selective
repeat
9
Pipelining: increased utilization
sender
receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R
first packet bit arrives
last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
RTT
ACK arrives, send next
packet, t = RTT + L / R
Increase utilization
by a factor of 3!
U
sender
=
3*L/R
RTT + L / R
=
.024
30.008
= 0.0008
microsecon
ds
10
Go-Back-N
Sender:


k-bit seq # in pkt header
“window” of up to N, consecutive unack’ed pkts allowed
 ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”
 may receive duplicate ACKs
 timer for each in-flight pkt
 timeout(n): retransmit pkt n and all higher seq # pkts in window
11
GBN in
action
12
Selective Repeat
 receiver individually acknowledges all correctly received
pkts
 buffers pkts, as needed, for eventual in-order delivery to
upper layer
 sender only resends pkts for which ACK not received
 sender timer for each unACKed pkt
 sender window
 N consecutive seq #’s
 again limits seq #s of sent, unACKed pkts
13
Selective Request
 Makes sense to transmit only the lost packets
 But this is true under what assumption ?
 Can you say a case in which Go-BACK-N might be better
14
Selective repeat: sender, receiver windows
15
Selective repeat
sender
data from above :
 if next available seq # in window,
send pkt
timeout(n):
 resend pkt n, restart timer
ACK(n) in [sendbase,sendbase+N]:
 mark pkt n as received
 if n smallest unACKed pkt, advance
window base to next unACKed seq #
receiver
pkt n in
[rcvbase, rcvbase+N-1]
 send ACK(n)
 out-of-order: buffer
 in-order: deliver (also deliver
buffered, in-order pkts),
advance window to next notyet-received pkt
pkt n in
[rcvbase-N,rcvbase-1]
 ACK(n)
otherwise:
 ignore
16
Selective repeat in action
17
Selective repeat:
dilemma
Example:
 seq #’s: 0, 1, 2, 3
 window size=3
 receiver sees no difference
in two scenarios!
 incorrectly passes duplicate
data as new in (a)
Q: what relationship between
seq # size and window size?
What if pkts go out of order
18
TCP
19
TCP Congestion Control
 Problem Definition
 How much data should I pump into the network to ensure
• Intermediate router queues not filling up
• Fairness achieved among multiple TCP flows
 Why is this problem difficult?
 TCP cannot have information about the network
 Only TCP receiver can give some feedbacks
20
The TCP Intuition
Pour
water
Collect
water
21
The Control Problem
 Two main components in TCP
 Flow Control and Congestion Control
 Flow Control
 If receiver’s bucket filling up, pour less water
 Congestion Control
 Don’t pour too much if there are leaks in intermediate pipes
 Regulate your flow based on how much is leaking out
• Aggressive pouring  calls for retransmission of lost packets
• Conservative pouring  lower e2e capacity
 Challenge: At what rate(t) should you pour ?
Why ?
22
The TCP Protocol (in a nutshell)
 T transmits few packets, waits for ACK
 Called slow start
 R acknowledges all packet till seq #i by ACK i
(optimizations possible)
 ACK sent out only on receiving a packet
 Can be Duplicate ACK if expected packet not received
 ACK reaches T  indicator of more capacity
 T transmits larger burst of packets (self clocking) … so on
 Burst size increased until packet drops (i.e., DupACK)
 When T gets DupACK or waits for longer than RTO
 Assumes congestion  reduces burst size (congestion window)
23
TCP Timeline
Host B
Think of a blind
person trying to
stand up in a low
ceiling room
RTT
Host A
Objective:
Don’t bang your
head, but stand
up quickly
time
24
After RTO timeout
25
cwnd = 20
20
15
10
ssthresh = 10
ssthresh = 8
5
25
22
20
15
12
9
6
3
0
0
Congestion window (segments)
When waited for > RTO
Time (round trips)
25
The TCP Protocol (in a nutshell)
 DupACK not necessarily indicator of congestion
 Can happen due to out of order (OOO) delivery of packets
 If 3 OOO pkts, then CW need not be cut drastically
 The DupACK packet retransmitted
 Continue with same pace of transmission as before
(fast recovery)
 R advertizes its receiver window in ACKs
Why ?
 If filling up, T reduces congestion window
26
Fast Recovery on 3 OOO DupACKs
Window size (segments)
After fast recovery
10
Receiver’s advertized window
8
6
4
2
0
0
2
4
6
8
10 12 14
Time (round trips)
27
TCP Round Trip Time and Timeout
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
 Exponential weighted moving average
 influence of past sample decreases exponentially fast
 typical value:  = 0.125
28
Example RTT estimation:
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
RTT (milliseconds)
300
250
200
150
100
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
106
time (seconnds)
SampleRTT
Estimated RTT
29
TCP Round Trip Time and Timeout
Setting the timeout
 EstimtedRTT plus “safety margin”

large variation in EstimatedRTT -> larger safety margin
 first estimate of how much SampleRTT deviates from EstimatedRTT:
DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|
(typically,  = 0.25)
Then set timeout interval:
TimeoutInterval = EstimatedRTT + 4*DevRTT
30
Several flavors of TCP: combines options / optimizations
Reno, Vegas, Eifel, Westwood …
Overall TCP has worked well – proven on the internet
Then why study it again
for wireless networks ?
31
The TCP Intuition
Pour
water
Collect
water
32
Renewed Challenge
 Key assumption in TCP
 A packet loss is indicative of network congestion
 Source needs to regulate flow by reducing CW
 Assumption closely true for wired networks
 BER ~ 10
-6
 With wireless, errors due to fading, fluctuations
 Need not reduce CW in response …
 But, TCP is e2e  CANNOT see the network
 Thus, TCP cannot classify the cause of loss  CHALLENGE
33
The Problem Model
TCP connection
application
application
application
transport
transport
transport
network
network
link
link
link
physical
physical
physical
Wireline
rxmt
network
wireless
34
Impact of Misclassification
2.0E+06
Sequence number (bytes)
Best possible
TCP with no errors
(1.30 Mbps)
1.5E+06
TCP Reno
(280 Kbps)
1.0E+06
5.0E+05
0.0E+00
0
10
20
30
Time (s)
40
50
60
2 MB wide-area TCP transfer over 2 Mbps WaveLAN
35
The Solution Space
 Much research on TCP over wireless
 Difficult to cover complete ground
 We peek into some of the key ideas







Link layer mechanisms
Split connection approach
TCP-Aware link layer
TCP-Unaware approximation of TCP-aware link layer
Explicit notification
Receiver-based discrimination
Sender-based discrimination
36
Link Layer Mechanisms
37
Link Layer Mechanisms
 Forward error corrections
 Add redundancy in the packets to correct bit-errors
 TCP retransmissions can be alleviated
 Link layer retransmissions
 MAC layer ACKnowledgments
 Overhead only when errors occur (unlike FEC)
Such mechanisms require no change in TCP
Is that breaking e2e argument ??
38
Issues with Link Layer Mechanisms
 Link layer cannot guarantee reliability
 Have to drop packets after some finite limit
 What is the retransmission limit (??)
 Retransmission can take quite long
Why?
 Can be significant fraction of RTT
 TCP can timeout and retransmit the same packet again
• Increasing RTO can avoid this
• But that impacts TCP’s recovery from congestion
 Head of the line blocking
 Link layer has to keep retransmitting even if bad channel
 Blocks other streams
39
Findings
 Link layer retransmission good
 When channel errors infrequent
 When retransmit time << RTO
 When modifying TCP is not an acceptable solution
40
Split Connection Approach
41
1 TCP = ½ TCP + ½ (TCP or XXX)
Per-TCP connection state
TCP connection
TCP connection
application
application
transport
transport
transport
network
network
network
link
link
link
physical
physical
physical
Base
Station
rxmt
application
wireless
42
Splitting Approaches
 Indirect TCP [Baker97]
 Fixed host (FH) to base station (BS) uses TCP
 BS to mobile host (MH) uses another TCP connection
 Selective Repeat [Yavatkar94]
 Over FH to BS: Use TCP
 Over BS to MH: Use selective repeat on top of UDP
 No congestion control over wireless [Haas97]
 Also use less headers over wireless
• Header compression
43
Issues with Splitting
 E2E totally broken
 2 separate connections
 BS maintains hard state for each connection
 What if MH disconnected from BS ?
 Huge buffer requirements at BS
 What if BS fails ?
Whats the
Problem ?
 Handoff between BS requires state transfer
 What if Data and ACK travel on different routes ?
 BS will not see the ACK at all – splitting not feasible
44
TCP-Aware Link Layer
45
Snoop
 Link layer at BS buffers un-acknowledged packets
 Now, BS peeks into every returning TCP ACK from MH
 If DupACK
• Retransmits the necessary packet
• Drops the DupACK
 DupACK does not reach sender
 Prevents fast retransmit
46
Snoop : Example
35
36
TCP state
maintained at
link layer
37
38
40
39
38
FH
37
BS
34
MH
36
Example assumes delayed ack - every other packet ack’d
47
Snoop : Example
35
39
36
37
38
41
40
34
39
38
36
48
Snoop : Example
37
40
38
39
42
41
40
36
39
36
dupack
Duplicate acks are not delayed
49
Snoop : Example
37
40
38
41
39
43
42
36
41
40
36
36
Duplicate acks
50
Snoop : Example
44
37
40
38
41
39
42
43
FH
37
41
BS
Discard
dupack
MH
36
36
Dupack triggers retransmission 36
of packet 37 from base station
BS needs to be TCP-aware to
be able to interpret TCP headers
51
Snoop : Example
45
37
40
38
41
39
42
44
43
42
37
36
36
36
36
52
Snoop : Example
46
37
40
43
38
41
44
39
42
45
43
42
36
TCP sender does not
fast retransmit
41
36 36
36
53
Snoop : Example
47
37
40
43
38
41
44
39
42
45
46
44
43
41
TCP sender does not
fast retransmit
36 36
36 36
54
Snoop : Example
42
45
43
46
44
48
47
45
FH
44
BS
41
MH
43
36 36
36 36
55
Snoop [Balakrishnan95acm]
bits/sec
2000000
1600000
1200000
base TCP
Snoop
800000
400000
0
no error
256K
128K
64K
32K
16K
1/error rate
(in bytes)
2 Mbps Wireless link
56
Issues with Snoop
 Link layer needs to be TCP aware
 Smelling cross layer
 Link layer needs to buffer and perform sliding window
 Not useful when TCP headers encrypted
 Not feasible when Data and ACK travel different
routes
 RTT estimates can still go up due to link layer
retransmission
 Affects performance of Snoop
57
Wireless TCP
 WTCP attempts to nullify RTT estimation problem
 When data packets are lost due to errors
 Link layer includes own time stamp in ACK packet
 ACK packets that have BS time stamps indicate a wireless
loss
 RTT of these packets not considered for RTO calculation
• But then, what if wireless hop is also congested !!!!!!
• Time stamping cannot take care of that 
58
Quick look at other schemes
TCP-unaware schemes
Explicit notification
Receiver-based
59
TCP-Unaware, ELN
 Delayed DupACKs
 Receiver waits for sometime before sending DupACK
 If link retransmission solves problem
• Then TCP sender does not send redundant packet
 Explicit Loss Notification (ELN)




BS remembers only packet’s sequence numbers
When DupACKs return through them, they check
If packet was received by BS, then colors the DupACK
Sender realizes that packet lost on wireless link
• Does not cut down CW, just retransmits that packet
60
Receiver-Based TCP
 Receiver estimates cause of packet loss
 If estimate == wireless loss, sets ELN bit
FH
FH
12
11
10
BS
BS
MH
T
12
10
MH
When is this
Mechanism a
Big problem ?
11
Congestion loss
2T
12
FH
BS
11
Error loss
10
MH
61
Closing Thoughts
 Reliable and in-order packet delivery important
 TCP aims to support these features
 Implements congestion control and flow control
 TCP widely tuned for wireline networks
 Proven to be efficient on the internet
 When network periphery has wireless “last mile”
 TCP exhibits myriad problems
 Mainly because of
“misclassification between congestion and channel errors”
 Several solution approaches  but many open problems
62
Questions ?
63
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
64
Marathon Presentations
 7 candidates
 1 Slot on Apr 22
 3 slots on Apr 24
 3 more candidates: We need to decide on a time.
65
What’s Hot Now ??
 TCP over wireless multihop (mesh)
 Each hop has contention-based MAC
• Unpredictable delays and congestion
 Fairness between TCP e2e flows a very challenging problem
 Mobility can significantly affect TCP
(Very difficult set of open problems)
 More fundamental: Is TCP the way to go for wireless
 Strong ongoing debate in community
 Useful queuing solutions in ad hoc networks
 Neighborhood RED solution
… and many many more …
66
If all that did not make sense,
or too heavy for “total recall”,
then here is a visual example
Thanks to Nitin Vaidya for tutorial slides
(Highly recommended for those interested in TCP)
67
Cumulative Acknowledgements
 A new cumulative acknowledgement is generated only
on receipt of a new in-sequence packet
40
39
33
38
34
41
35
40
34
39
35
i
37
data
38
36
i
36
ack
37
68
Delayed Acknowledgements
 An ack is delayed until
 another packet is received, or
 delayed ack timer expires (200 ms typical)
 Reduces ack traffic
40
39
New ack not produced
on receipt of packet 36,
but on receipt of 37
38
33
41
37
35
40
39
35
38
37
69
Duplicate Acknowledgements
 A dupack is generated whenever an
out-of-order segment arrives at the receiver
40
39
38
37
34
42
41
36
40
36
(Above example assumes delayed acks)
39
36
Dupack
On receipt of 38
70
Duplicate Acknowledgements
 Duplicate acks are not delayed
 Duplicate acks may be generated when
 a packet is lost, or
 a packet is delivered out-of-order (OOO)
40
39
37
38
34
41
40
36
39
37
36
36
Dupack
On receipt of 38
71
Number of dupacks depends on how much
OOO a packet is
40
39
37
34
41
36
New Ack
40
39
34
New Ack
41
40
36
New Ack
New Ack
37
36
New Ack
42
38
36
Dupack
39
36
Dupack
38
New Ack
72