TCP over Wireless Links

1
TCP over Wireless Links
ECE 256 Spring 2009
2
Todays 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
• Whats hot now ?

3
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

4
Recall 2 Network Layer

• 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

5
We have a route, now what ?
Data
NETWORK
Data
Data

• 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

6
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, dont 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
7
Some transmission methods

• Stop Wait
• Pipelined
• Go Back N
• Selective Repeat

8
Stop-and-wait operation
sender
receiver
first packet bit transmitted, t 0
last packet bit transmitted, t L / R
first packet bit arrives
RTT
last packet bit arrives, send ACK
ACK arrives, send next packet, t RTT L / R
9
Pipelined protocols

• Pipelining sender allows multiple, in-flight,
  yet-to-be-acknowledged 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

10
Pipelining increased utilization
sender
receiver
first packet bit transmitted, t 0
last bit transmitted, t L / R
first packet bit arrives
RTT
last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
ACK arrives, send next packet, t RTT L / R
Increase utilization by a factor of 3!
11
Go-Back-N

• Sender
• k-bit seq in pkt header
• window of up to N, consecutive unacked 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

12
GBN inaction
13
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

14
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

15
Selective repeat sender, receiver windows
16
Selective repeat

• data from above
• if next available seq in window, send pkt
• timeout(n)
• resend pkt n, restart timer
• ACK(n) in sendbase,sendbaseN
• mark pkt n as received
• if n smallest unACKed pkt, advance window base to
  next unACKed seq

• pkt n in rcvbase, rcvbaseN-1
• send ACK(n)
• out-of-order buffer
• in-order deliver (also deliver buffered,
  in-order pkts), advance window to next
  not-yet-received pkt
• pkt n in rcvbase-N,rcvbase-1
• ACK(n)
• otherwise
• ignore

17
Selective repeat in action
18
Selective repeat dilemma

• Example
• seq s 0, 1, 2, 3
• window size3
• 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
19
TCP
20
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

21
The TCP Intuition
Pour water
Collect water
22
The Control Problem

• Two main components in TCP
• Flow Control and Congestion Control
• Flow Control
• If receivers bucket filling up, pour less water
• Congestion Control
• Dont 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 ?
23
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)

24
TCP Timeline
Host A
Host B
Think of a blind person trying to stand up in a
low ceiling room Objective Dont bang
your head, but stand up quickly
one segment
RTT
two segments
four segments
25
When waited for gt RTO
After RTO timeout
cwnd 20
ssthresh 10
ssthresh 8
26
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
• If filling up, T reduces congestion window

Why ?
27
Fast Recovery on 3 OOO DupACKs
After fast recovery
Receivers advertized window
28
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

29
Example RTT estimation
30
TCP Round Trip Time and Timeout

• Setting the timeout
• EstimtedRTT plus safety margin
• large variation in EstimatedRTT -gt 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 4DevRTT
31

• 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 ?

32
The TCP Intuition
Pour water
Collect water
33
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

34
The Problem Model
TCP connection
Wireline
35
Impact of Misclassification
Best possible TCP with no errors (1.30 Mbps)
TCP Reno (280 Kbps)
Sequence number (bytes)
Time (s)
2 MB wide-area TCP transfer over 2 Mbps WaveLAN
36
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

37

• Link Layer Mechanisms

38
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 ??

39
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
• Can be significant fraction of RTT
• TCP can timeout and retransmit the same packet
  again
• Increasing RTO can avoid this
• But that impacts TCPs recovery from congestion
• Head of the line blocking
• Link layer has to keep retransmitting even if bad
  channel
• Blocks other streams

Why?
40
Findings

• Link layer retransmission good
• When channel errors infrequent
• When retransmit time ltlt RTO
• When modifying TCP is not an acceptable solution

41

• Split Connection Approach

42
1 TCP ½ TCP ½ (TCP or XXX)
Per-TCP connection state
TCP connection
TCP connection
Base Station
43
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

44
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 ?
• 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

Whats the Problem ?
45

• TCP-Aware Link Layer

46
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

47
Snoop Example
35
TCP state maintained at link layer
36
37
38
40
39
37
38
FH
MH
BS
36
34
Example assumes delayed ack - every other packet
ackd
48
Snoop Example
35
39
36
37
38
41
40
38
39
36
34
49
Snoop Example
37
40
38
39
42
41
39
40
36
36
dupack
Duplicate acks are not delayed
50
Snoop Example
37
40
38
41
39
40
41
43
42
36
36
36
Duplicate acks
51
Snoop Example
37
40
38
41
39
42
41
37
44
43
FH
MH
BS
36
36
Discard dupack
36
Dupack triggers retransmission of packet 37 from
base station BS needs to be TCP-aware to be
able to interpret TCP headers
52
Snoop Example
37
40
43
38
41
39
42
37
42
45
44
36
36
36
36
53
Snoop Example
37
40
43
38
41
44
39
42
42
43
46
45
36
41
TCP sender does not fast retransmit
36
36
36
54
Snoop Example
37
40
43
38
41
44
39
42
45
43
44
47
46
41
TCP sender does not fast retransmit
36
36
36
36
55
Snoop Example
42
45
43
46
44
44
45
48
47
FH
MH
BS
41
43
36
36
36
36
56
Snoop Balakrishnan95acm
2 Mbps Wireless link
57
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

58
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 ?

59

• Quick look at other schemes
• TCP-unaware schemes
• Explicit notification
• Receiver-based

60
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 packets 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

61
Receiver-Based TCP

• Receiver estimates cause of packet loss
• If estimate wireless loss, sets ELN bit

10
12
11
FH
MH
BS
T
10
12
FH
MH
BS
11
Congestion loss
2 T
10
11
12
Error loss
FH
MH
BS
62
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

63

• Questions ?

64
(No Transcript)
65
Marathon Presentations

• 7 candidates
• 1 Slot on Apr 22
• 3 slots on Apr 24
• 3 more candidates We need to decide on a time.

66
Whats 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

67

• 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)

68
Cumulative Acknowledgements

• A new cumulative acknowledgement is generated
  only on receipt of a new in-sequence packet

40
39
37
38
35
33
36
34
41
40
38
39
35
37
36
34
i
data
ack
i
69
Delayed Acknowledgements

• An ack is delayed until
• another packet is received, or
• delayed ack timer expires (200 ms typical)
• Reduces ack traffic

New ack not produced on receipt of packet 36, but
on receipt of 37
40
39
37
38
35
33
41
40
38
39
35
37
70
Duplicate Acknowledgements

• A dupack is generated whenever an
• out-of-order segment arrives at the receiver

71
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
38
37
36
34
41
40
37
39
36
36
Dupack
On receipt of 38
72
Number of dupacks depends on how much OOO a
packet is
40
39
38
37
36
34
New Ack
New Ack
41
40
37
39
36
36
34
Dupack
New Ack
New Ack
42
41
39
40
36
36
38
New Ack
Dupack
New Ack