TCP over Wireless Links

Wireless connectivity characteristics

Transmission errors Low bandwidth Long or variable latency Asymmetry in bandwidth

Impact of transmission errors on TCP performance Impact of handoffs on TCP performance Approaches to improve TCP performance
I-TCP Snoop Link layer retransmissions M-TCP

Transmission Control Protocol (TCP)

Window based protocol
Size of window determines sending rate (data sent per RTT) Window size based on network state and receive buffer size

Implements congestion avoidance and control

packet loss assumed to be indication of congestion sending rate reduced drastically on detecting a packet loss

Reliable ordered delivery: reliability by retransmissions

packet loss detected by timeouts and duplicate acks

End-to-end semantics
Acks confirm delivery of data received by TCP receiver Ack for data sent only after data has reached receiver

Duplicate Acknowledgements
Duplicate ack is generated when a received packet has a larger-than-expected sequence number Duplicate acks may be generated when
a packet is lost, or a packet is delivered out-of-order (OOO)
40 39
34

37

38
36

out-of-order delivery

41

40
34

39

37
36

38 lost due to congestion

40

39
34

38

37
36

38 lost due to errors

Fast Retransmit Mechanism

TCP sender assumes that a packet loss has occurred if it receives 3 dupacks consecutively 3 dupacks will be generated if 3 packets are delivered subsequent to a lost packet
12 11 10 9 8 7

3 dupacks are also generated if a packet is delivered at least 3 places beyond its in-sequence location
12

11 10 9 7

Fast retransmit useful only if lower layers deliver packets almost ordered ---- otherwise, unnecessary fast retransmit

Fast retransmit is followed by fast recovery. After fast recovery, window size is reduced in half.
After fast recovery

Window size (segments)

10 8 6 4 2 0
0 2 4 6 8

Receivers advertized window

10 12 14

Time (round trips)

Window based Flow Control

Congestion window size bounds the amount of data that can be sent per round-trip time (RTT) Throughput <= W / RTT Ideal window size = delay * bandwidth
delay-bandwidth product

What if window size < delay*bw ?

Inefficiency (wasted bandwidth)

What if window size > delay*bw ?

Queuing at intermediate routers increased RTT due to queuing delays Potentially, packet loss

Burst Errors May Cause Timeouts

If wireless link remains unavailable for extended duration, a window worth of data may be lost
driving through a tunnel passing a truck

Timeout results in slow start Slow start reduces congestion window to 1 MSS, reducing throughput Reduction in window in response to errors unnecessary

Random Errors May Cause Fast Retransmit

40

39
34

38

37
36

Example assumes delayed ack - every other packet ackd

Random Errors May Cause Fast Retransmit

41
34

40

39
36

38

Example assumes delayed ack - every other packet ackd

Random Errors May Cause Fast Retransmit

42

41
36

40

39
36

dupack Duplicate acks are not delayed

Random Errors May Cause Fast Retransmit

43
36

42

41
36

40
36

Duplicate acks

Random Errors May Cause Fast Retransmit

44

43
36

42
36

41
36

3 duplicate acks trigger fast retransmit at sender

Random Errors May Cause Fast Retransmit

Fast retransmit results in
retransmission of lost packet reduction in congestion window

Reducing congestion window in response to errors is unnecessary Reduction in congestion window reduces the throughput

Impact of Transmission Errors

Packet loss due to errors can trigger fast retransmit and fast recovery, resulting in
retransmission of lost packet reduction in congestion window

Reducing congestion window in response to errors is unnecessary

unless errors are caused by congestion

Reduction in congestion window in response to errors can significantly reduce the throughput

TCP cannot distinguish between packet losses due to congestion and those due to transmission errors.

Impact of Errors
1600000 1200000 800000 400000 0 16384 32768 65536 131072 1/error rate (in bytes) bits/sec

Exponential error model 2 Mbps wireless full duplex link No congestion losses

Techniques to Improve TCP Performance in Presence of Errors Classification 1

Classification based on nature of actions taken to improve performance Hide error losses from the sender
if sender is unaware of the packet losses due to errors, it will not reduce congestion window

Let sender know, or determine, cause of packet loss

if sender knows that a packet loss is due to errors, it will not reduce congestion window

Techniques to Improve TCP Performance in Presence of Errors Classification 2

Classification based on where modifications are needed At the sender node only At the receiver node only At intermediate node(s) only Combinations of the above

Ideal Behavior
Ideal TCP behavior: Ideally, the TCP sender should simply retransmit a packet lost due to transmission errors, without taking any congestion control actions
Such a TCP referred to as Ideal TCP Ideal TCP typically not realizable

Ideal network behavior: Transmission errors should be hidden from the sender -- the errors should be recovered transparently and efficiently Proposed schemes attempt to approximate one of the above two ideals

Proposals to Improve Performance of TCP over Wireless

Split connection approach Link level mechanisms TCP-Aware link layer Explicit notification

TCP-Unaware approximation of TCP-aware link layer Receiver-based discrimination Sender-based discrimination For an overview, see IETF PILC working group documents

Split Connection Approach (I-TCP)

End-to-end TCP connection is broken into
one connection on the wired part of route, and one over wireless part of the route

Split connection results in independent flow control for the two parts
Flow/error control protocols, packet size, time-outs, may be different for each part
FH BS MH

Fixed Host

Base Station

Mobile Host

Split Connection Approach

Per-TCP connection state TCP connection application transport network link physical TCP connection application transport network link physical application transport network link physical

rxmt

wireless

Split Connection Approach : Advantages

BS-MH connection can be optimized independent of FHBS connection
Different flow / error control on the two connections

Local recovery of errors

Faster recovery due to relatively shorter RTT on wireless link

Good performance achievable using appropriate BS-MH protocol

Standard TCP on BS-MH performs poorly when multiple packet losses occur per window (timeouts can occur on the BS-MH connection, stalling during the timeout interval) Selective acks improve performance for such cases

Split Connection Approach : Disadvantages

End-to-end semantics violated
ack may be delivered to sender, before data delivered to the receiver May not be a problem for applications that do not rely on TCP for the end-to-end semantics

39 40

38
FH
40

37
MH
36

BS

Split Connection Approach : Disadvantages

BS retains hard state BS failure can result in loss of data (unreliability)
If BS fails, packet 40 will be lost Because it is ackd to sender, the sender does not buffer 40

39 40

38
FH
40

37
MH
36

BS

Split Connection Approach : Disadvantages

BS retains hard state Hand-off latency increases due to state transfer
Data that has been ackd to sender, must be moved to new base station

FH

40

39 40 BS

38

37
36

MH

39 40

MH

Hand-off

New base station

Split Connection Approach : Disadvantages

Buffer space needed at BS for each TCP connection

BS buffers tend to get full, when wireless link slower (one window worth of data on wired connection could be stored at the base station, for each split connection)

Window on BS-MH connection reduced in response to errors

may not be an issue for wireless links with small delay-bw product

Split Connection Approach : Disadvantages

Extra copying of data at BS

copying from FH-BS socket buffer to BS-MH socket buffer increases end-to-end latency

May not be useful if data and acks traverse different paths (both do not go through the base station)
Example: data on a satellite wireless hop, acks on a dial-up channel data FH MH

ack

Snoop Protocol

Retains local recovery of Split Connection approach and link level retransmission schemes Improves on split connection
end-to-end semantics retained soft state at base station, instead of hard state

Snoop Protocol
Buffers data packets at the base station BS
to allow link layer retransmission

When dupacks received by BS from MH, retransmit on wireless link, if packet present in buffer Prevents fast retransmit at TCP sender FH by dropping the dupacks at BS

FH

BS

MH

Snoop Protocol
Per TCP-connection state TCP connection application transport network application transport network rxmt application transport network

link
physical

link
physical

link
physical

FH

BS

wireless

MH

Snoop : Example
35 36 TCP state maintained at link layer

37
38

40
FH

39
BS
34

38

37
MH
36

Example assumes delayed ack - every other packet ackd

Snoop : Example
35 36 39

37
38

41
34

40

39
36

38

Snoop : Example
37 40

38
39

42

41
36

40

39
36

dupack Duplicate acks are not delayed

Snoop : Example
37 40

38
39

41

43
36

42

41
36

40
36

Duplicate acks

Snoop : Example
37 40

38
39

41
42

44
FH

43
BS Discard dupack

37
36

41
MH
36

Dupack triggers retransmission 36 of packet 37 from base station BS needs to be TCP-aware to be able to interpret TCP headers

Snoop : Example
37 40 43

38
39

41
42

45

44

42
36

37
36

36 36

Snoop : Example
37 40 43

38
39

41
42

44

46

45

43
36

42
41

TCP sender does not fast retransmit

36 36 36

Snoop : Example
37 40 43

38
39

41
42

44
45

47

46

44
41

43

TCP sender does not fast retransmit

36 36 36 36

Snoop : Example
42 45

43
44

46

48
FH

47
BS
41

45

44
MH
43

36 36 36 36

Snoop Protocol : Advantages

High throughput can be achieved
performance further improved using selective acks

Local recovery from wireless losses Fast retransmit not triggered at sender despite out-of-order link layer delivery End-to-end semantics retained Soft state at base station
loss of the soft state affects performance, but not correctness

Snoop Protocol : Disadvantages

Link layer at base station needs to be TCP-aware Not useful if TCP headers are encrypted (IPsec) Cannot be used if TCP data and TCP acks traverse different paths (both do not go through the base station)

Link Layer Mechanisms

Forward error correction (FEC)

quick recovery

Link level retransmission: Retransmit a packet at the link layer, if errors are detected
Retransmission overhead incurred only if errors occur

Link Level Retransmissions

Link layer state

TCP connection application transport network application transport network rxmt application transport network

link
physical

link
physical

link
physical

wireless

Link Level Retransmissions Issues

How many times to retransmit at the link level before giving up?
Fully reliable or not

What triggers link level retransmissions?

Timeout, link layer Nack, TCP dupack (as in Snoop), ...

How much time is required for a link layer retransmission?

Small or large fraction of end-to-end round trip time

Should the link layer deliver packets as they arrive, or deliver them in-order?

Impact of Handoffs on Schemes to Improves Performance in Presence of Errors

Split connection approach
hard state at base station must be moved to new base station

Snoop protocol
soft state need not be moved while the new base station builds new state, packet losses may not be recovered locally

Frequent handoffs a problem for schemes that rely on significant amount of hard/soft state at base stations
hard state should not be lost soft state needs to be recreated to benefit performance

Mitigation Using Fast Retransmit

When MH is the TCP receiver: after handoff is complete, it sends 3 dupacks to the sender
this triggers fast retransmit at the sender instead of dupacks, a special notification could also be sent

When MH is the TCP sender: invoke fast retransmit after completion of handoff

M-TCP
In the fast retransmit scheme
sender starts transmitting soon after handoff BUT congestion window shrinks

M-TCP attempts to avoid shrinkage in the congestion window

M-TCP Uses TCP Persist Mode When a new ack is received with receivers advertised window = 0, the sender enters persist mode Sender does not send any data in persist mode except when persist timer goes off When a positive window advertisement is received, sender exits persist mode On exiting persist mode, RTO and cwnd are same as before the persist mode

M-TCP
Similar to the split connection approach, M-TCP splits one TCP connection into two logical parts
the two parts have independent flow control as in I-TCP

The BS does not send an ack to MH, unless BS has received an ack from MH
maintains end-to-end semantics

BS withholds ack for the last byte ackd by MH

Ack 999 FH BS Ack 1000 MH

M-TCP

Withheld ack sent with window advertisement = 0, if MH moves away (handoff in progress) Sender FH put into persist mode during handoff Sender exits persist mode after handoff, and starts sending packets using same cwnd as before handoff

FH

BS

MH

M-TCP
The last ack is not withheld, if BS does not expect any other ack from the MH
this happens when the BS has no other unackd data buffered locally this is required to prevent a sender timeout at the end of a transfer (or end of a burst of data)

Avoids reduction of congestion window due to handoff, unlike the fast retransmit scheme Important Question unanswered : Is not reducing the window a good idea?
When host moves, route changes, and new route may be more congested than before It is not obvious that starting full speed after handoff is right