MObile TCP - Udd

You might also like

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 286

Mobile TCP

Prepared by
Dr Mrs U D Dalal
Associate Prof.,ECED, SVNIT

1
Wireless Technologies

 Wireless local area networks


 Cellular wireless
 Satellites
 Multi-hop wireless
 Wireless local loop

2
Transmission Control Protocol / Internet Protocol

TCP/IP

Two Basic Protocols


User Datagram Protocol (UDP)—Connection less—No
session establishment, data flow, congestion control and
session termination
Transport Control Protocol (TCP)—Connection oriented—
Session establishment and termination, data flow,
recovery, congestion control, buffering, retransmission

3
Through Internet Protocol (IP)…..

 Packets may be delivered out-of-order

 Packets may be lost

 Packets may be duplicated

4
Port

 A port is a Service Access Point (software) for data


input and output through which a service
(application) is rendered by a node.
 Function of the transport layer is to transport the port
data.
 Port data to the layer L4 includes the application layer
protocol header.

5
Transmission Control Protocol (TCP)

 Transmission as data streams—A segment is transmitted as a


data stream of bytes which are packetized at layer L3
 Buffering and Retransmission of segments with ACK provision--
Reliability achieved by means of retransmissions if necessary
 End-to-end semantics
• Acknowledgements sent to TCP sender confirm delivery of data
received by TCP receiver
• Ack for data sent only after data has reached receiver
• Cumulative, delayed or duplicate acknowledgements handling
 Sessions
 Reliable ordered delivery in sequential order-- TCP assigns
packet sequence numbers
 Implements congestion control and avoidance

6
UDP Header

7
TCP Header

8
9
TCP provides Data Delivery mechanism for
Data Streams
 Stream consists of bytes. The number of bytes in a stream is
equal to TPDU that are placed in a memory buffer
 Streams are delivered using virtual connection between sockets.
 Each socket has a port number and an IP address for rendering
service to an application.
 At an IP address there can be sockets for
 HTTP application data streams
 FTP stream
 SMTP data stream
etc.
Each has an assigned port number as per IETF

RTT—Round Trip Time

10
Strategies
 The port numbers are divided into three ranges: the
Well Known Ports, the Registered Ports, and the
Dynamic and/or Private Ports.

 The Well Known Ports are those from 0 through 1023.


 The Registered Ports are those from 1024 through 49151
 The Dynamic and/or Private Ports are those from 49152
through 65535
 Well Known ports and registered ports SHOULD
NOT be used without IANA—(Internet Assigned
Number Authority) registration. The registration
procedure is defined in [RFC4340], Section 19.9.
 A value of 0 in the port numbers registry below
indicates that no port has been allocated.
11
TCP mechanism--Connection Establishment—
Three Phases

12
TCP Termination

 While it takes three segments to establish a connection, it takes


four to terminate a connection. This is caused by TCP's half-
close.
 Since a TCP connection is full-duplex, each direction must be
shut down independently.
 The rule is that either end can send a FIN when it is done
sending data (or application close click). When a TCP receives
a FIN, it must notify the application that the other end has
terminated that direction of data flow.
 The receipt of a FIN only means there will be no more data
flowing in that direction. A TCP can still send data after
receiving a FIN. While it's possible for an application to take
advantage of this half-close, in practice few TCP applications
use it.
13
14
15
 Five modes/states
 FIN_WAIT_1
 FIN_WAIT_2
 CLOSE_WAIT
 CLOSING
 CLOSED

There are various possibilities to acquire a state. So, many


times state diagrams are better to represent.

16
17
18
TCP Data Flow Control

 Required because a few packets of a data stream may reach


the other end with an error or may be lost or may not reach at
the expected time.

 Need of retransmissions

Handled as follows:
 1. Window size adjustment (TCP Tuning)
 2. Cumulative ACK
 3. reverse packet ACK
 4. Duplicate ACK
 5. Delayed ACK

19
TCP tuning

 Window size w (in terms of bytes) is adjusted and


throughput depends on RTT interval for the ACK.
 The transmitter TCPa transmits all bytes received
upto a sequence number specified by w at the
window size field of the other end TCPb

 Three ways– Adjusting the window size field as per


receiver’s capacity
---Window Scaling method
---Sliding Window Protocol

20
Session between browser (receiver) and server
(sender) with sub segments

21
Comments

 Initial window size is 999, Last received byte


sequence number is 999, ACK generated for that by
the next seq number.
 New window size is 3000
 Next byte sequence number 1000

22
Cumulative Acknowledgements
 The receiver acknowledges all the bytes received
upto a sequence number defined in the ack field. A
new cumulative acknowledgement is generated only
on receipt of a new in-sequence packet.
40 39 38 37

33 34 35 36

41 40 39 38

34 35 36 37

i data i ack 23
Duplicate Acknowledgements

 A dupack is generated whenever an


out-of-order segment arrives at the receiver

40 39 38 37

34 36

42 41 40 39

36 36

Dupack
On receipt of 38 24
(Above example assumes delayed acks)
Duplicate ACK

25
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 36

41 40 39 37

36 36

Dupack
On receipt of 38 26
Number of dupacks depends on how much
OOO a packet is
40 39 37 38

34 36
New Ack New Ack

41 40 39 37

34 36 36

New Ack New Ack Dupack

42 41 40 39

36 36 38

New Ack Dupack New Ack 27


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

33 35

41 40 39 38

35 37
28
Window Based Flow Control

 Sliding window protocol


 Window size minimum of
 receiver’s advertised window - determined by available
buffer space at the receiver
 congestion window - determined by the sender, based on
feedback from the network

Sender’s window

1 2 3 4 5 6 7 8 9 10 11 12 13

Acks received Not transmitted


29
Window Based Flow Control

Sender’s window

1 2 3 4 5 6 7 8 9 10 11 12 13

Ack 5

1 2 3 4 5 6 7 8 9 10 11 12 13

Sender’s window 30
Window Based Flow Control

 Congestion window size bounds the amount of data


that can be sent per round-trip time

 Throughput <= W / RTT

31
How does TCP detect a packet loss?

 1. Retransmission timeout (RTO)


 At any time, TCP sender sets retransmission timer for only
one packet. If acknowledgement for the timed packet is not
received before timer goes off, the packet is assumed to be
lost
 RTO dynamically calculated
 Timeout Granularity--RTT is measured as a discrete
variable, in multiples of a “tick”, 1 tick = 500 ms in many
implementations
 RTO is at least 2 clock ticks

 2. Duplicate acknowledgements

32
Detecting Packet Loss Using Dupacks
(Fast Retransmit Mechanism is better)
 Dupacks may be generated due to
 packet loss, or
 out-of-order packet delivery

 TCP sender assumes that a packet loss has occurred


if it receives three dupacks consecutively

3 dupacks are also generated if a packet


12 8 11 10 9 7 is delivered at least 3 places beyond its
in-sequence location

Fast retransmit useful only if lower layers deliver packets


“almost ordered” ---- otherwise, unnecessary fast retransmit
33
General remedies to Control the Congestion or
packet loss
 Exponential Backoff --Double RTO on each timeout
T1 T2 = 2 * T1
Timeout interval doubled
Packet
transmitted
Time-out occurs
before ack received,
packet retransmitted

 Fast retransmission

34
Congestion Avoidance and Control

Two Schemes—1. Slow start and 2. Fast Recovery


Both are based on various phases

Slow Start
 initially, congestion window size cwnd = 1 MSS

(maximum segment size)


 increment window size by 1 MSS on each new ack

 slow start phase ends when window size reaches the

slow-start threshold which is equal to ½ of the original


window size.
 cwnd grows exponentially with time during slow start

 factor of 2 per RTT if every packet ack’d


 Could be less if sender does not always have data to send 35
Congestion Avoidance

 On each new ack, increase cwnd by 1/cwnd packets


 cwnd increases linearly with time during congestion
avoidance
 1/2 MSS per RTT if every other packet ack’d
 1 MSS per RTT if every packet ack’d

36
Congestion
14 avoidance
12
Congestion Window size

10
(segments)

8 Slow start
6 threshold
Slow start
4
2
0
0 1 2 3 4 5 6 7 8
Time (round trips)

Example assumes that acks are not delayed 37


Congestion Control

 On detecting a packet loss, TCP sender assumes


that network congestion has occurred

 On detecting packet loss, TCP sender drastically


reduces the congestion window

 Reducing congestion window reduces amount of data


that can be sent per RTT
 throughput may decrease

38
Congestion Control -- Timeout

 On a timeout, the congestion window is reduced to


the initial value of 1 MSS

 The slow start threshold is set to half the window size


before packet loss
 more precisely,
ssthresh = maximum of min(cwnd,receiver’s advertised
window)/2 and 2 MSS

 Slow start is initiated

39
Congestion window (segments) After timeout
25
cwnd = 20
20

15

10
ssthresh = 8 ssthresh = 10
5

0
12

15

22

25
0

20
Time (round trips)

40
Congestion Control - Fast retransmit

 Fast retransmit occurs when multiple (>= 3) dupacks


come back

 Fast recovery follows fast retransmit

 Different from timeout : slow start follows timeout


 timeout occurs when no more packets are getting across
 fast retransmit occurs when a packet is lost, but latter
packets get through
 ack clock is still there when fast retransmit occurs
 no need to slow start

41
Fast Recovery

 ssthresh =
min(cwnd, receiver’s advertised window)/2 (at least 2
MSS)
 retransmit the missing segment (fast retransmit)
 cwnd = ssthresh + number of dupacks
 when a new ack comes: cwnd = ssthreh
 enter congestion avoidance

Congestion window cut into half

42
After fast recovery

10
Receiver’s advertized window
8
Window size (segments)

6
4
2
0

Time (round trips)

After fast retransmit and fast recovery window size


is 43
reduced in half.
TCP Reno

44
45
Fast Recovery
Fast recovery can result in a timeout with multiple losses per
RTT
.
 TCP New-Reno [Hoe96]

 stay in fast recovery until all packet losses in window are recovered
 can recover 1 packet loss per RTT without causing
a timeout

 Selective Acknowledgements (SACK) [mathis96rfc2018]


 provides information about out-of-order packets received by
receiver
 can recover multiple packet losses per RTT

46
Impact of transmission errors
on TCP performance

47
Tutorial Outline

 Wireless technologies
 TCP basics
 Impact of transmission errors on TCP performance
 Approaches to improve TCP performance
 Classification
 Discussion of selected approaches

48
Random Errors

 If number of errors is small, they may be corrected by


an error correcting code
 Excessive bit errors result in a packet being
discarded, possibly before it reaches the transport
layer

49
Random Errors May Cause Fast Retransmit

40 39 38 37

34 36

Example assumes delayed ack - every other packet ack’d

50
Random Errors May Cause Fast Retransmit

41 40 39 38

34 36

Example assumes delayed ack - every other packet ack’d

51
Random Errors May Cause Fast Retransmit

42 41 40 39

36 36

dupack

Duplicate acks are not delayed

52
Random Errors May Cause Fast Retransmit

43 42 41 40

36 36 36

Duplicate acks

53
Random Errors May Cause Fast Retransmit

44 43 42 41

36 36 36

3 duplicate acks trigger


fast retransmit at sender

54
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

55
Sometimes Congestion Response May be
Appropriate in Response to Errors

 On a CDMA channel, errors occur due to interference


from other user, and due to noise [Karn99pilc]
 Interference due to other users is an indication of
congestion. If such interference causes transmission errors,
it is appropriate to reduce congestion window
 If noise causes errors, it is not appropriate to reduce window

 When a channel is in a bad state for a long duration,


it might be better to let TCP backoff, so that it does
not unnecessarily attempt retransmissions while the
channel remains in the bad state
[Padmanabhan99pilc]
56
This Tutorial

 We consider errors for which reducing congestion


window is an inappropriate response

57
Impact of Random Errors [Vaidya99]

1600000

1200000

800000 bits/sec

400000

0
16384 32768 65536 131072
1/error rate (in bytes)

Exponential error model


2 Mbps wireless full duplex link
No congestion losses 58
Note

 Since results from different papers are not


necessarily obtained using same system model,
comparison of absolute numbers in different graphs
may not be valid

 Observe trends, rather than absolute numbers

59
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

60
Random Errors May Also Cause Timeout

 Multiple packet losses in a window can result in


timeout when using TCP-Reno (and to a lesser extent
when using SACK)

61
Impact of Transmission Errors

 TCP cannot distinguish between packet losses due to


congestion and transmission errors
 Unnecessarily reduces congestion window
 Throughput suffers

62
Tutorial Outline

 Wireless technologies
 TCP basics
 Impact of transmission errors on TCP performance
 Approaches to improve TCP performance
 Classification
 Discussion of selected approaches

63
Classification of Schemes to
Improve Performance of TCP in
Presence of Transmission Errors

64
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

65
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

66
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

67
Tutorial Outline

 Wireless technologies
 TCP basics
 Impact of transmission errors on TCP performance
 Approaches to improve TCP performance
 Classification
 Discussion of selected approaches

68
Selected Schemes to
Improve Performance of TCP in
Presence of Transmission Errors

69
Caveat

 When describing various schemes, only the major


features are presented

 Often, some additional features are present in these


schemes, to optimize their performance

 We will not cover all the details, only the most


relevant ones

70
Various Schemes

 Link level mechanisms


 Split connection approach
 TCP-Aware link layer
 TCP-Unaware approximation of TCP-aware link layer
 Explicit notification
 Receiver-based discrimination
 Sender-based discrimination

For a brief overview, see [Dawkins99,Montenegro99]

71
Link Level Mechanisms

72
Link Layer Mechanisms
Forward Error Correction

 Forward Error Correction (FEC) [Lin83] can be use


to correct small number of errors

 Correctable errors hidden from the TCP sender

 FEC incurs overhead even when errors do not occur


 Adaptive FEC schemes [Eckhardt98] can reduce the
overhead by choosing appropriate FEC dynamically

73
Link Layer Mechanisms
Link Level Retransmissions

 Link level retransmission schemes retransmit a


packet at the link layer, if errors are detected

 Retransmission overhead incurred only if errors occur


 unlike FEC overhead

74
Link Layer Mechanisms

In general

 Use FEC to correct a small number of errors

 Use link level retransmission when FEC capability is


exceeded

75
Link Level Retransmissions
Link layer state

TCP connection

application application application


transport transport transport
network network network
rxmt
link link link
physical physical physical

wireless
76
Link Level Retransmissions
Issues
 How many times to retransmit at the link level before
giving up?
 Finite bound -- semi-reliable link layer
 No bound -- reliable link layer

 What triggers link level retransmissions?


 Link layer timeout mechanism
 Link level acks (negative acks, dupacks, …)
 Other mechanisms (e.g., Snoop, as discussed later)

 How much time is required for a link layer


retransmission?
 Small fraction of end-to-end TCP RTT
 Large fraction/multiple of end-to-end TCP RTT
77
Link Level Retransmissions
Issues

 Should the link layer deliver packets as they arrive, or


deliver them in-order?
 Link layer may need to buffer packets and reorder if
necessary so as to deliver packets in-order

78
Link Level Retransmissions
Issues

 Retransmissions can cause head-of-the-line blocking

Receiver 1

Base station Receiver 2

 Although link to receiver 1 may be in a bad state, the


link to receiver 2 may be in a good state
 Retransmissions to receiver 1 are lost, and also block
a packet from being sent to receiver 2

79
Link Level Retransmissions
Issues

 Retransmissions can cause congestion losses

Receiver 1

Base station Receiver 2


 Attempting to retransmit a packet at the front of the queue,
effectively reduces the available bandwidth, potentially
making the queue at base station longer
 If the queue gets full, packets may be lost, indicating
congestion to the sender
 Is this desirable or not ?

80
Link Level Retransmissions
An Early Study [DeSimone93]

 The sender’s Retransmission Timeout (RTO) is a


function of measured RTT (round-trip times)
 Link level retransmits increase RTT, therefore, RTO

 If errors not frequent, RTO will not account for RTT


variations due to link level retransmissions
 When errors occur, the sender may timeout & retransmit
before link level retransmission is successful
 Sender and link layer both retransmit
 Duplicate retransmissions (interference) waste wireless
bandwidth
 Timeouts also result in reduced congestion window
81
RTO Variations

Wireless
Packet loss
RTT sample
RTO

82
A More Accurate Picture

 Analysis in [DeSimone93] does not accurately model


real TCP stacks

 With large RTO granularity, interference is unlikely,


if time required for link-level retransmission is small
compared to TCP RTO [Balakrishnan96Sigcomm]
 Standard TCP RTO granularity is often large
 Minimum RTO (2*granularity) is large enough to allow a
small number of link level retransmissions, if link level RTT is
relatively small
 Interference due to timeout not a significant issue when
wireless RTT small, and RTO granularity large [Eckhardt98]

83
Link Level Retransmissions
A More Accurate Picture

 Frequent errors increase RTO significantly on slow


wireless links
 RTT on slow links large, retransmissions result in large
variance, pushing RTO up
 Likelihood of interference between link layer and TCP
retransmissions smaller
 But congestion response will be delayed due to larger RTO
 When wireless losses do cause timeout, much time wasted

84
Link-Layer Retransmissions
A More Accurate Picture [Ludwig98]

 Timeout interval may actually be larger than RTO


 Retransmission timer reset on an ack
 If the ack’d packet and next packet were transmitted in a
burst, next packet gets an additional RTT before the timer
will go off

data ack
1 2
Timeout = RTO
Reset, Timeout = RTO

Effectively, Timeout = RTT of packet 1 + RTO 85


Large TCP Retransmission Timeout Intervals

 Good for reducing interference with link level


retransmits

 Bad for recovery from congestion losses

 Need a timeout mechanism that responds


appropriately for both types of losses
 Open problem

86
Link Level Retransmissions
 Selective repeat protocols can deliver packets out of
order

 Significantly out-of-order delivery can trigger TCP fast


retransmit
 Redundant retransmission from TCP sender
 Reduction in congestion window

 Example: Receipt of packets


Lost packet
3,4,5 triggers dupacks
Retransmitted packet

6 2 5 4 3 2 1 87
Link Level Retransmissions
In-order delivery

 To avoid unnecessary fast retransmit, link layer using


retransmission should attempt to deliver packets
“almost in-order”

6 5 4 3 2 2 1

6 5 2 4 3 2 1
88
Link Level Retransmissions
In-order delivery

 Not all connections benefit from retransmissions or ordered


delivery
 audio

 Need to be able to specify requirements on a per-packet


basis [Ludwig99]
 Should the packet be retransmitted? How many times?
 Enforce in-order delivery?

 Need a standard mechanism to specify the requirements


 open issue (IETF PILC working group)

89
Adaptive Link Layer Strategies
[Lettieri98,Eckhardt98,Zorzi97]

Adaptive protocols attempt to dynamically choose:

 FEC code

 retransmission limit

 frame size

90
Link Layer Retransmissions [Vaidya99]

2000000
1600000
base TCP
1200000
800000 Link layer
retransmission
400000
0
16384

32768

65536

1E+05
20 ms 1 ms
1/error rate (in bytes)
10 Mbps 2 Mbps

2 Mbps wireless duplex link with 1 ms delay


Exponential error model
No congestion losses 91
Link Layer Schemes: Summary

When is a reliable link layer beneficial to TCP


performance?

 if it provides almost in-order delivery

and

 TCP retransmission timeout large enough to tolerate


additional delays due to link level retransmits

92
Link Layer Schemes: Classification

 Hide wireless losses from TCP sender

 Link layer modifications needed at both ends of


wireless link
 TCP need not be modified

93
Various Schemes

 Link level mechanisms


 Split connection approach
 TCP-Aware link layer
 TCP-Unaware approximation of TCP-aware link layer
 Explicit notification
 Receiver-based discrimination
 Sender-based discrimination

94
Split Connection Approach

95
Split Connection Approach

 End-to-end TCP connection is broken into one


connection on the wired part of route and one over
wireless part of the route

 A single TCP connection split into two TCP


connections
 if wireless link is not last on route, then more than two TCP
connections may be needed

96
Split Connection Approach

 Connection between wireless host MH and fixed host


FH goes through base station BS

 FH-MH = FH-BS + BS-MH

FH BS MH

Fixed Host Base Station Mobile Host 97


Split Connection Approach

 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 98


Split Connection Approach

Per-TCP connection state

TCP connection TCP connection

application application application


rxmt
transport transport transport
network network network
link link link
physical physical physical

wireless 99
Split Connection Approach
Indirect TCP [Bakre95,Bakre97]

 FH - BS connection : Standard TCP


 BS - MH connection : Standard TCP

100
Split Connection Approach
Selective Repeat Protocol (SRP) [Yavatkar94]

 FH - BS connection : standard TCP


 BS - FH connection : selective repeat protocol on top
of UDP

 Performance better than Indirect-TCP (I-TCP),


because wireless portion of the connection can be
tuned to wireless behavior

101
Split Connection Approach : Other Variations

 Asymmetric transport protocol (Mobile-TCP)


[Haas97icc]

Low overhead protocol at wireless hosts, and higher


overhead protocol at wired hosts
 smaller headers used on wireless hop (header compression)
 simpler flow control - on/off for MH to BS transfer
 MH only does error detection, BS does error correction too
 No congestion control over wireless hop

102
Split Connection Approach : Other Variations

 Mobile-End Transport Protocol [Wang98infocom]


 Terminate the TCP connection at BS
 TCP connection runs only between BS and FH
 BS pretends to be MH (MH’s IP functionality moved to
BS)

 BS guarantees reliable ordered delivery of packets to


MH
 BS-MH link can use any arbitrary protocol optimized
for wireless link
 Idea similar to [Yavatkar94]
103
Split Connection Approach : Classification

 Hides transmission errors from sender


 Primary responsibility at base station
 If specialized transport protocol used on wireless,
then wireless host also needs modification

104
Split Connection Approach : Advantages
 BS-MH connection can be optimized independent of FH-
BS 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

105
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 37
FH BS MH
40 36

106
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 ack’d to sender, the sender does not buffer 40

39

40
38 37
FH BS MH
40 36

107
Split Connection Approach : Disadvantages

 BS retains hard state


Hand-off latency increases due to state transfer
 Data that has been ack’d to sender, must be moved to new
base station
39
40 38 37
FH BS MH
40 36

39
40 MH Hand-off

108
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

109
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

110
ack
Various Schemes

 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

111
TCP-Aware Link Layer

112
Snoop Protocol [Balakrishnan95acm]

 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

113
Snoop Protocol

Per TCP-connection state

TCP connection

application application application


transport transport transport
network network network
rxmt
link link link
physical physical physical

FH BS MH
wireless
114
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

115
Snoop : Example
35 TCP state
maintained at
36
link layer
37

38

40 39 38 37
FH BS MH
34 36

Example assumes delayed ack - every other packet ack’d

116
Snoop : Example
35 39

36

37

38

41 40 39 38

34 36

117
Snoop : Example

37 40

38

39

42 41 40 39

36 36

dupack

Duplicate acks are not delayed

118
Snoop : Example

37 40

38 41

39

43 42 41 40

36 36 36

Duplicate acks

119
Snoop : Example

37 40

38 41

39 42

44 43 37 41
FH BS MH
36 36
Discard
dupack
Dupack triggers retransmission 36
of packet 37 from base station

BS needs to be TCP-aware to
be able to interpret TCP headers 120
Snoop : Example

37 40 43

38 41

39 42

45 44 42 37

36 36

36

36
121
Snoop : Example

37 40 43

38 41 44

39 42

46 45 43 42

36 41

TCP sender does not


fast retransmit 36 36

36
122
Snoop : Example

37 40 43

38 41 44

39 42 45

47 46 44 43

41

TCP sender does not


fast retransmit 36 36

36 36
123
Snoop : Example

42 45

43 46

44

48 47 45 44
FH BS MH
41 43

36 36

36 36
124
Snoop [Balakrishnan95acm]

2000000
1600000
bits/sec

1200000 base TCP


800000 Snoop

400000
0
16K
32K
64K

128K
256K
no error
1/error rate (in bytes)

2 Mbps Wireless link


125
Snoop Protocol
When Beneficial?

 Snoop prevents fast retransmit from sender despite


transmission errors, and out-of-order delivery on the
wireless link

 OOO delivery causes fast retransmit only if it results


in at least 3 dupacks

 If wireless link level delay-bandwidth product is less


than 4 packets, a simple (TCP-unaware) link level
retransmission scheme can suffice
 Since delay-bandwidth product is small, the retransmission
scheme can deliver the lost packet without resulting in 3
dupacks from the TCP receiver
126
Snoop Protocol : Classification

 Hides wireless losses from the sender

 Requires modification to only BS (network-centric


approach)

127
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

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

129
WTCP Protocol [Ratnam98]

 Snoop hides wireless losses from the sender


 But sender’s RTT estimates may be larger in
presence of errors
 Larger RTO results in slower response for congestion
losses

FH BS MH

130
WTCP Protocol

 WTCP performs local recovery, similar to Snoop

 In addition, WTCP uses the timestamp option to


estimate RTT
 The base station adds base station residence time to
the timestamp when processing an ack received from
the wireless host
 Sender’s RTT estimate not affected by
retransmissions on wireless link
FH BS MH

131
WTCP Example

3 3
FH BS MH
4 3

Numbers in this figure are timestamps

Base station residence time is 1 unit

132
WTCP : Disadvantages

 Requires use of the timestamp option


 May be useful only if retransmission times are large
 link stays in bad state for a long time
 link frequently enters a bad state
 link delay large

 WTCP does not account for congestion on wireless


hop
 assumes that all delay at base station is due to queuing and
retransmissions
 will not work for shared wireless LAN, where delays also
incurred due to contention with other transmitters
133
Various Schemes

 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

134
TCP-Unaware Approximation of
TCP-Aware Link Layer

135
Delayed Dupacks Protocol [Mehta98,Vaidya99]

 Attempts to imitate Snoop, without making the base


station TCP-aware

 Snoop implements two features at the base station


 link layer retransmission
 reducing interference between TCP and link layer
retransmissions (by dropping dupacks)

 Delayed Dupacks implements the same two features


 at BS : link layer retransmission
 at MH : reducing interference between TCP and link layer
retransmissions (by delaying dupacks)
136
Delayed Dupacks Protocol

Link layer state


TCP connection

application application application


transport transport transport
network network network
rxmt
link link link
physical physical physical

wireless
137
Delayed Dupacks Protocol
 Link layer retransmission scheme at the base station

 Link layer delivers packets out-of-order when


transmission errors occur

 Why may a link layer deliver packets out-of-order?


• Only an issue when the link layer does not use stop-and-
go protocol

 With OOO link layer delivery, loss of a packet from one flow
does not block delivery of packets from another flow

 If in-order delivery is enforced, when retransmission for a


packet is being performed, packets from other other flows
may also be blocked from being delivered to the upper layer
138
Delayed Dupacks Protocol

 TCP receiver delays dupacks (third and subsequent)


for interval D, when out-of-order packets received

 Dupack delay intended to give link level retransmit


time to succeed

 Benefit: Delayed dupacks can result in recovery from a


transmission loss without triggering a response from
the TCP sender

 Disadvantage: Recovery from congestion losses


delayed
139
Delayed Dupacks Protocol

 Delayed dupacks released after interval D, if missing


packet not received by then

 Link layer maintains state to allow retransmission


 Link layer state is not TCP-specific

140
Delayed Dupacks : Example
35
Link layer state
36

37

38

40 39 38 37

34 36

Example assumes delayed ack - every other packet ack’d

Link layer acks are not shown 141


Delayed Dupacks : Example
36

37

38

39

41 40 39 38
BS
34 36

35 Removed from BS link layer buffer on receipt of a


link layer ack (LL acks not shown in figure)
142
Delayed Dupacks : Example

37 40

38

39

42 41 40 39

36 36

dupack

Duplicate acks are not delayed

143
Delayed Dupacks : Example

37 40

38 41

39

43 42 41 40

36 36 36

Original ack Duplicate acks

144
Delayed Dupacks : Example

37

39 41

40 42

44 43 37 41

36 36
36
dupack dupacks
Delayed
dupack
Base station forwards dupacks

145
Delayed Dupacks : Example

37 42

40 43

41

45 44 42 37

36 36
36

dupacks 36

Delayed dupacks

146
Delayed Dupacks : Example

37 43

41 44

42

46 45 43 42

36 41

Delayed dupacks are


discarded if lost
TCP sender does not packet received before
fast retransmit delay D expires
147
Delayed Dupacks [Vaidya99]
2000000
1600000
base TCP
1200000
800000 dupack delay
80ms + LL
400000
Retransmit
0 Only LL
retransmit
16384

32768

65536

1E+05
1/error rate (in bytes) 20 ms 20 ms

10 Mbps 2 Mbps

2 Mbps wireless duplex link with 20 ms delay


No congestion losses
148
Delayed Dupacks [Vaidya99]
160000
140000
120000 base TCP
100000
80000
60000 dupack delay
40000 80ms + LL
20000 Retransmit
0 Only LL
retransmit
16384

32768

65536

1E+05
1/error rate (in bytes) 20 ms 20 ms

10 Mbps 2 Mbps

5% packet loss due to congestion


149
Delayed Dupacks Scheme : Advantages

 Link layer need not be TCP-aware

 Can be used even if TCP headers are encrypted

 Works well for relatively small wireless RTT


(compared to end-to-end RTT)
 relatively small delay D sufficient in such cases

150
Delayed Dupacks Scheme : Disadvantages

 Right value of dupack delay D dependent on the


wireless link properties

 Mechanisms to automatically choose D needed

 Delays dupacks for congestion losses too, delaying


congestion loss recovery

151
Various Schemes

 Link-layer retransmissions
 Split connection approach
 TCP-Aware link layer
 TCP-Unaware approximation of TCP-aware link layer
 Explicit notification
 Receiver-based discrimination
 Sender-based discrimination

152
Explicit Notification

153
Explicit Notification Schemes
General Philosophy

 Approximate Ideal TCP behavior: Ideally, the TCP sender


should simply retransmit a packet lost due to transmission
errors, without taking any congestion control actions

 A wireless node somehow determines that packets are


lost due to errors and informs the sender using an explicit
notification

 Sender, on receiving the notification, does not reduce


congestion window, but retransmits lost packet

154
Explicit Notification Schemes

 Motivated by the Explicit Congestion Notification


(ECN) proposals [Floyd94]

Variations proposed in literature differ in

 who sends explicit notification


 how they know to send the explicit notification
 what the sender does on receiving the notification

155
Explicit Notification
Space Communication Protocol Standards-
Transport Protocol (SCPS-TP)

Satellite

wireless

TCP destinations
Ground station

156
Space Communication Protocol Standards-
Transport Protocol (SCPS-TP)
 The receiving ground station keeps track of how many
packets with errors are received (their checksums failed)
 When the error rate exceeds a threshold, the ground
station sends corruption experienced messages to
destinations of recent error-free TCP packets
 destinations are cached
 The TCP destinations tag acks with corruption-
experienced bit
 TCP sender, after receiving an ack with corruption-
experienced bit, does not back off until it receives an ack
without that bit (even if timeout or fast retransmit occurs)

157
Explicit Loss Notification [Balakrishnan98]
when MH is the TCP sender
 Wireless link first on the path from sender to receiver
 The base station keeps track of holes in the packet
sequence received from the sender
 When a dupack is received from the receiver, the
base station compares the dupack sequence number
with the recorded holes
 if there is a match, an ELN bit is set in the dupack
 When sender receives dupack with ELN set, it
retransmits packet, but does not reduce congestion
window Record
hole at 2
4 3 2 1 4 3 1
MH BS FH
wireless 1 1 1 1 158
Dupack with ELN set
Explicit Bad State Notification [Bakshi97]
when MH is TCP receiver

 Base station attempts to deliver packets to the MH


using a link layer retransmission scheme

 If packet cannot be delivered using a small number of


retransmissions, BS sends a Explicit Bad State
Notification (EBSN) message to TCP sender

 When TCP sender receives EBSN, it resets its timer


 timeout delayed, when wireless channel in bad state

159
Partial Ack Protocols
[Cobb95][Biaz97]
 Send two types of acknowledgements
 A partial acknowledgement informs the sender that a
packet was received by an intermediate host
(typically, base station)
 Normal TCP cumulative ack needed by the sender for
reliability purposes

160
Partial Ack Protocols

 When a packet for which a partial ack is received is


detected to be lost, the sender does not reduce its
congestion window
 loss assumed to be due to wireless errors

37

37 36

Partial ack Cumulative ack

161
Variations

 Base station may or may not locally buffer and


retransmit lost packets
 Partial ack for all packets or a subset ?

37

37 36

Partial ack Cumulative ack

162
Explicit Loss Notification [Biaz99thesis]
when MH is TCP receiver
 Attempts to approximate hypothetical ELN proposed
in [Balakrishnan96] for the case when MH is receiver

 Caches TCP sequence numbers at base station,


similar to Snoop. But does not cache data packets,
unlike Snoop.

 Duplicate acks are tagged with ELN bit before being


forwarded to sender if sequence number for the lost
packet is cached at the base station

 Sender takes appropriate action on receiving ELN


163
Explicit Loss Notification [Biaz99thesis]
when MH is TCP receiver

Sequence numbers 39
cached at base station
38

37
39 38 37

36 37 37

Dupack with ELN

164
Various Schemes

 Link-layer retransmissions
 Split connection approach
 TCP-Aware link layer
 TCP-Unaware approximation of TCP-aware link layer
 Explicit notification
 Receiver-based discrimination
 Sender-based discrimination

165
Receiver-Based Discrimination Scheme

166
Receiver-Based Scheme [Biaz98Asset]

 MH is TCP receiver
 Receiver uses a heuristic to guess cause of packet
loss
 When receiver believes that packet loss is due to
errors, it sends a notification to the TCP sender
 TCP sender, on receiving the notification, retransmits
the lost packet, but does not reduce congestion
window

167
Receiver-Based Scheme

 Packet loss due to congestion


12 11 10

FH BS MH

12 10
FH BS MH

11
Congestion loss 168
Receiver-Based Scheme

 Packet loss due to transmission error


12 11 10

FH BS MH

2T

12 11 10
Error loss
FH BS MH

169
Receiver-Based Scheme

 Receiver uses the inter-arrival time between


consecutively received packets to guess the cause of
a packet loss

 On determining a packet loss as being due to errors,


the receiver may
 tag corresponding dupacks with an ELN bit, or
 send an explicit notification to sender

170
Receiver-Based Scheme
Diagnostic Accuracy [Biaz99Asset]

Congestion losses Error losses


171
Receiver-Based Scheme : Disadvantages

 Limited applicability

 The slowest link on the path must be the last wireless


hop
 to ensure some queuing will occur at the base station

 The queueing delays for all packets (at the base


station) should be somewhat uniform
 multiple connections on the link will make inter-packet
delays variable

172
Receiver-Based Scheme : Advantages

 Can be implemented without modifying the base


station (an “end-to-end” scheme)

 May be used despite encryption, or if data & acks


traverse different paths

173
Various Schemes

 Link-layer retransmissions
 Split connection approach
 TCP-Aware link layer
 TCP-Unaware approximation of TCP-aware link layer
 Explicit notification
 Receiver-based discrimination
 Sender-based discrimination

174
Sender-Based Discrimination Scheme

175
Sender-Based Discrimination Scheme
[Biaz98ic3n,Biaz99techrep]

 Sender can attempt to determine cause of a packet


loss

 If packet loss determined to be due to errors, do not


reduce congestion window

 Sender can only use statistics based on round-trip


times, window sizes, and loss pattern
 unless network provides more information (example: explicit
loss notification)

176
Heuristics for Congestion Avoidance

throughput
cliff
knee
RTT

load load

177
Heuristics for Congestion Avoidance

 Define condition C as a function of congestion window


size and observed RTTs

 Condition C evaluated when a new RTT is calculated


 condition C typically evaluates to 2 or 3 possible values
 for now assume 2 values: TRUE or FALSE

 If (C == True) reduce congestion window

 Several proposals for condition C


178
Heuristics for Congestion Avoidance
Some proposals

 Normalized Delay Gradient [jain89]

r = [RTT(i)-RTT(i-1)] / [RTT(i)+RTT(i-1)]

w = [W(i)-W(i-1)] / [W(i)+W(i-1)]

Condition C = (r/w > 0)

179
Heuristics for Congestion Avoidance
Some proposals

 Normalized Throughput Gradient [Wang91]

Throughput gradient
TG(i) = [T(i) - T(i-1) ] / [ W(i)-W(i-1)]

Normalized Throughout Gradient


NTG = TG(i) / TG(1)

Condition C = (NTG < 0.5)

180
Heuristics for Congestion Avoidance
Some proposals

 TCP Vegas [Brakmo94]

expected throughput ET = W(i) / RTTmin

actual throughput AT = W(i) / RTT(i)

Condition C = ( ET-AT > beta)

181
Sender-Based Heuristics

 Record latest value evaluated for condition C

 When a packet loss is detected

 if last evaluation of C is TRUE, assume packet loss is due


to congestion
 else assume that packet loss is due to transmission errors

 If packet loss determined to be due to errors, do not


reduce congestion window

182
Sender-Based Schemes
Diagnostic Accuracy [Biaz99ic3n]

183
Sender-Based Schemes
Diagnostic Accuracy [Biaz99ic3n]

184
Sender-Based Heuristics : Disadvantage

 Does not work quite well enough as yet !!

Reason

 Statistics collected by the sender garbled by other


traffic on the network

 Not much correlation between observed short-term


statistics, and onset of congestion

185
Sender-Based Heuristics : Advantages

 Only sender needs to be modified

Needs further investigation to develop better heuristics


 investigate longer-term heuristics

186
Why do Statistical Technique Perform Poorly?
 The techniques we evaluated use simple statistics on
RTT and window size W to draw conclusions about
state of the network
 Unfortunately, correlation between RTT and W is
often weak
Fraction of TCP
connections

Coefficient of correlation (RTT,W) 187


Statistical Techniques
Future Work

 Other statistical measures ?

 Mechanisms that achieve good TCP throughput


despite not-too-good diagnostic accuracy

188
TCP in Presence of Transmission Errors
Summary

 Many techniques have been proposed, and several


approaches perform well in many environments

 Recommendation: Prefer end-to-end techniques


 End-to-end techniques are those which
do not require TCP-Specific help from lower layers
 Lower layers may help improve TCP performance without
taking TCP-specific actions. Examples:
• Semi-reliable link level retransmission schemes
• Explicit notification
189
Tutorial Outline

 Schemes to improves TCP performance in presence


of transmission errors
 TCP over Satellite
 Impact of mobility on TCP performance
 Approaches to improve TCP performance in
presence of mobility
 Issues in multi-hop wireless networks
 Issues needing further work
 References

190
TCP Over Satellite

191
TCP over Satellite

 Geostationary Earth Orbit (GEO) Satellite


 long latency
 transmission errors or channel unavailability

 Low Earth Orbit (LEO) Satellite


 relatively smaller delays
 delays more variable

192
Problems Addressed by Various Schemes

 Long delay
 Large delay-bandwidth products
 Transmission errors

193
Improving TCP-over-Satellite [Allman98sept]
[IETF-TCPSAT]

 Larger congestion window (window scale option)


 maximum window size up to 2^30
 Acknowledge every packet (do not delay acks)
 Selective acks
 fast recovery can only recover one packet loss per RTT
 SACKS allow multiple packet recovery per RTT

194
Larger Initial Window
[Allman98september] [Allman98august]

 Allows initial window size of cwnd to be up to

approximately 4 Kbyte

 Larger initial window results in faster window growth


during slow start
 avoids wait for delayed ack timers (which will occur with
cwnd = 1 MSS)
 larger initial window requires fewer RTTs to reach ssthresh

195
Byte Counting [Allman98august]

 Increase window by number of new bytes ack’d in an


acknowledgement, instead of 1 MSS per ack
 Speeds up window growth despite delayed or lost
acks
 Need to reduce bursts from sender
 limiting size of window growth per ack
 rate control

196
Space Communications Protocol Standard-
Transport Protocol (SCPS-TP) [Durst96]
 Sender makes default assumption about source of
packet loss
 default assumption can be set by network manager on a
per-route basis
 default assumption can be changed due to explicit feedback
from the network
 Congestion control algorithm derived from TCP-
Vegas, to bound window growth, to reduce
congestion-induced losses

197
Space Communications Protocol Standard-
Transport Protocol (SCPS-TP)
 During link outage, TCP sender freezes itself, and
resumes when link is restored
 outage assumed to occur in both directions simultaneously
 ground station can detect outage of incoming link (for
instance, by low signal levels), and infers outage of outgoing
link
 ground stations provide link outage information to any
sender that attempts to send packets on the outgoing link
 sender does not unnecessarily timeout or retransmit until it is
informed that link has recovered
 Selective acknowledgement protocol to recover
losses quickly

198
Satellite Transport Protocol (STP)
[Henderson98]
 Uses split connection approach
 Protocol on satellite channel different from TCP
 selective negative acks when receiver detects losses
 no retransmission timer
 transmitter periodically requests receiver to ack received
data
 reduces reverse channel bandwidth usage when losses are
rare

199
Early Acks

 Spoofing
 Ground station acks packets
 Should take responsibility for delivering packets
 Early acks from ground station result in faster congestion
window growth

 ACKprime approach [Scott98]


 Acks from ground station only used to grow congestion
window
 Reliable delivery assumed only on reception of an ack from
the receiver
• this is similar to the partial ack approach [Biaz97]

200
Tutorial Outline

 TCP over Satellite


 Impact of mobility on TCP performance
 Approaches to improve TCP performance in
presence of mobility
 Issues in multi-hop wireless networks
 Issues needing further work
 References

201
Impact of Mobility on TCP Performance

202
Impact of Mobility

 Hand-offs occur when a mobile host starts


communicating with a new base station (in cellular
wireless systems)

203
Impact of Mobility

 If link layer performs hand-offs and guarantees


reliability despite handoff, then TCP will not be aware
of the handoff
 except for potential delays during handoff

204
Impact of Mobility

 If hand-off visible to IP
 Need Mobile IP [Johnson96]
 packets may be lost while a new route is being established
reliability despite handoff
 We consider this case

205
Mobile IP [Johnson96]

MH Router
S
3

Home
agent

Router Router
1 2

206
Mobile IP [Johnson96]

move

Router
S MH
3

Foreign agent

Home agent

Router Router Packets are tunneled


using IP in IP
1 2

207
Example Hand-Off Procedure

1. Each base station periodically transmits beacon


2. Mobile host, on hearing stronger beacon from a new
BS, sends it a greeting
 changes routing tables to make new BS its default gateway
 sends new BS identity of the old BS

4
Old New
BS 5,6 BS
1
2
3
MH
7
208
Hand-Off Procedure
3. New BS acknowledges the greeting, and begins to
route the MH’s packets
4. New BS informs old BS
5. Old BS changes routing table, to forward any
packets for the MH to the new BS
6. Old BS sends an ack to new BS
7. New BS sends handoff-completion message to MH
4
Old New
BS 5,6 BS
1
2
3
MH
7 209
Mobile IP

 Mobile IP would need to modify the previous hand-off


procedure to inform the home agent the identity of
the new foreign agent

 Triangular optimization can reduce the routing delay


 Route directly to foreign agent, instead of via home agent

210
Hand-off

 Hand-offs may result in temporary loss of route to MH


 with non-overlapping cells, it may be a while before the
mobile host receives a beacon from the new BS

 While routes are being reestablished during handoff,


MH and old BS may attempt to send packets to each
other, resulting in loss of packets

211
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

212
Techniques to
Improve TCP Performance
in Presence of Mobility

213
Classification

 Hide mobility from the TCP sender

 Make TCP adaptive to mobility

214
Using Fast Retransmits to Recover from
Timeouts during Handoff [Caceres95]

 During the long delay for a handoff to complete, a


whole window worth of data may be lost
 After handoff is complete, acks are not received by
the TCP sender
 Sender eventually times out, and retransmits
 If handoff still not complete, another timeout will
occur
 Performance penalty
 Time wasted until timeout occurs
 Window shrunk after timeout
215
0-second Rendezvous Delay : Beacon arrives
as soon as cell boundary crossed
Cell crossing Retransmission
Handoff complete
+ beacon timeout
Routes updated
arrives

Last
timed 1.0
transmit

0 0.15 0.8 sec

Packet loss Idle sender


216
1-second Rendezvous Delay : Beacon arrives 1
second after cell boundary crossed
Beacon arrives
Cell crossing Retransmission
timeout 2
Timeout 1 Handoff
complete
Last
timed 1.0 2.0
transmit

0 0.8 1.0 1.15 2.8 sec

Packet loss Idle sender


217
Performance [Caceres95]

Four environments
1. No moves
2. Moves (once per 8 sec) between overlapping cells
3. Moves between non-overlapping cells, 0 sec delay
4. Moves between non-overlapping cells, 1 sec delay

Experiments using 2 Mbps WaveLan

218
TCP Performance

1800 1600 1510


1600 1400
1400 1100
1200
1000 Kbit/sec
800
600
400
200
0

es lls l ay ec.
v e s
o c de /1
m
i ng /0 p
No pp
p rla
rla e
rla e o v
e ov -
ov n -
no
n
no

219
TCP Performance

 Degradation in case 2 (overlapping cells) is due to


encapsulation and forwarding delay during handoff

 Additional degradation in cases 3 and 4 due to packet


loss and idle time at sender

220
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

221
0-second Rendezvous Delay
Improvement using Fast Retransmit
Cell crossing Retransmission
Handoff complete
+ beacon timeout
Routes updated
arrives does not occur
Fast retransmit
Last
timed 1.0
transmit

0 0.15 0.8

Packet loss
Idle sender
222
TCP Performance Improvement

1800 1600
1600 1510 1490
1400 1380
1400
1200 1100
1000 Kbit/sec
800 With fast rxmit
600
400
200
0
1 2 3 4

223
TCP Performance Improvement

 No change in cases 1 and 2, as expected

 Improvement for non-overlapping cells

 Some degradation remains in case 3 and 4


 fast retransmit reduces congestion window

224
Improving Performance by Smooth Handoffs
[Caceres95]

 Provide sufficient overlap between cells to avoid


packet loss

or

 Buffer packets at BS
 Discard the packets after a short interval
 If handoff occurs before the interval expires, forward the
packets to the new base station
 Prevents packet loss on handoff

225
M-TCP [Brown97]

 In the fast retransmit scheme [Caceres95]


 sender starts transmitting soon after handoff
 BUT congestion window shrinks

 M-TCP attempts to avoid shrinkage in the


congestion window

226
M-TCP Uses
TCP Persist Mode
 When a new ack is received with receiver’s 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
227
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 ack’d by MH

Ack 999 Ack 1000

FH BS MH

228
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

229
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 unack’d data
buffered locally
 this is required to prevent a sender timeout at the end of a
transfer (or end of a burst of data)

230
M-TCP

 Avoids reduction of congestion window due to handoff,


unlike the fast retransmit scheme
 simulation-based performance results look good

 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.
231
FreezeTCP [Goff99]

 M-TCP needs help from base station


 Base station withholds ack for one byte
 The base station uses this ack to send a zero window
advertisement when a mobile host moves to another cell

 FreezeTCP requires the receiver to send zero


window advertisement (ZWA)

Mobile
TCP receiver

FH BS MH

232
FreezeTCP [Goff99]

 TCP receiver determines if a handoff is about to


happen
 determination may be based on signal strength
 Ideally, receiver should attempt to send ZWA
1 RTT before handoff
 Receiver sends 3 dupacks when route is
reestablished
 No help needed from the base station
 an end-to-end enhancement
Mobile
TCP receiver

FH BS MH
233
Using Multicast to Improve Handoffs
[Ghai94,Seshan96]
 Define a group of base stations including
 current cell of a mobile host
 cells that the mobile host is likely to visit next
 Address packets destined to the mobile host to the
group
 Only one base station transmits the packets to the
mobile host
 if rest of them buffer the packets, then packet loss minimized
on handoff

234
Using Multicast to Improve Handoffs

 Static group definition [Ghai94]


 groups can be defined taking physical topology into account
 static definition may not take individual user mobility pattern
into account

 Dynamic group definition [Seshan96]


 implemented using IP multicast groups
 each user’s group can be different
 overhead of updating the multicast groups is a concern with
a large scale deployment

235
Using Multicast to Improve Handoffs

 Buffering at multiple base stations incurs memory


overhead

 Trade-off between buffering overhead and packet


loss

 Buffer requirement can be reduced by starting


buffering only when a mobile host is likely to leave
current cell soon

236
Tutorial Outline

 TCP over Satellite


 Impact of mobility on TCP performance
 Approaches to improve TCP performance in
presence of mobility
 Issues in multi-hop wireless networks
 Issues needing further work
 References

237
TCP in Mobile Ad Hoc Networks

238
Mobile Ad Hoc Networks (MANET)

 May need to traverse multiple links to reach a


destination

239
Mobile Ad Hoc Networks
[IETF-MANET]
 Mobility causes route changes

240
TCP in Mobile Ad Hoc Networks
Issues
 Route changes due to mobility
 Wireless transmission errors
 problem compounded with multiple hops
 Out-of-order packet delivery
 frequent route changes may cause out-of-order delivery
 TCP does not perform well if packets are significantly OOO
 Multiple access protocol
 choice of MAC protocol can impact TCP performance
significantly
 Half-duplex radios
 cannot send and receive packets simultaneously
 changing mode (send or receive) incurs overhead

241
Throughput over Multi-Hop Wireless Paths
[Gerla99]

 When contention-based MAC protocol is used,


connections over multiple hops are at a disadvantage
compared to shorter connections, because they
have to contend for wireless access at each hop
 extent of packet delay or drop increases with number of
hops

242
Impact of Multi-Hop Wireless Paths
[Holland99]
1600
1400
1200
1000 TCP
800 Throughtput
600 (Kbps)
400
200
0
1 2 3 4 5 6 7 8 9 10
Number of hops

TCP Throughput using 2 Mbps 802.11 MAC


243
Ideal Throughput

 f(i) = fraction of time for which shortest path length


between sender and destination is I

 T(i) = Throughput when path length is I


 From previous figure

 Ideal throughput =  f(i) * T(i)

244
Impact of Mobility
TCP Throughput

2 m/s 10 m/s
Actual throughput

Ideal throughput (Kbps)


245
Impact of Mobility

20 m/s 30 m/s
Actual throughput

Ideal throughput
246
Throughput generally degrades with increasing
speed …

Ideal

Average
Throughput
Over
50 runs Actual

Speed (m/s)
247
But not always …

30 m/s

20 m/s
Actual
throughput

Mobility pattern # 248


Why Does Throughput Degrade?
mobility causes
link breakage,
resulting in route Route is TCP sender times out.
failure repaired Starts sending packets again

No
throughput
No throughput
despite route repair

TCP data and acks


en route discarded 249
Why Does Throughput Degrade?
TCP sender
mobility causes
times out.
link breakage, TCP sender
Route is Resumes
resulting in route times out.
repaired sending
failure Backs off timer.

No throughput
No throughput
despite route repair

Larger route repair delays


especially harmful
TCP data and acks
en route discarded 250
Why Does Throughput Improve?
Low Speed Scenario

D D D
C C C
B B B A
A A

1.5 second route failure

Route from A to D is broken for ~1.5 second.

When TCP sender times after 1 second, route still broken.

TCP times out after another 2 seconds, and only then resumes.
251
Why Does Throughput Improve?
Higher (double) Speed Scenario

D D D
C C C
B B B A
A A

0.75 second route failure

Route from A to D is broken for ~ 0.75 second.

When TCP sender times after 1 second, route is repaired.


252
Why Does Throughput Improve?
General Principle
 TCP timeout interval somewhat (not entirely)
independent of speed
 Network state at higher speed, when timeout occurs,
may be more favorable than at lower speed
 Network state
 Link/route status
 Route caches
 Congestion

253
How to Improve Throughput
(Bring Closer to Ideal)

 Network feedback

 Inform TCP of route failure by explicit message

 Let TCP know when route is repaired


 Probing
 Explicit notification

 Reduces repeated TCP timeouts and backoff

254
Performance Improvement

Without network With feedback


feedback
Actual throughput

Ideal throughput
2 m/s speed 255
Performance Improvement

Without network With feedback


feedback
Actual throughput

Ideal throughput
256
30 m/s speed
Performance with Explicit Notification
[Holland99]
throughput as a fraction of
1

0.8
Base TCP
0.6
ideal

0.4 With explicit


notification
0.2

0
2 10 20 30
mean speed (m/s)

257
Issues
Network Feedback

 Network knows best (why packets are lost)

+ Network feedback beneficial


- Need to modify transport & network layer to
receive/send feedback

 Need mechanisms for information exchange between


layers

258
Impact of Caching

 Route caching has been suggested as a mechanism


to reduce route discovery overhead [Broch98]

 Each node may cache one or more routes to a given


destination

 When a route from S to D is detected as broken,


node S may:
 Use another cached route from local cache, or
 Obtain a new route using cached route at another node
259
Actual throughput (as fraction of expected throughput)

Average speed (m/s)


To Cache or Not to Cache

260
Why Performance Degrades With Caching

 When a route is broken, route discovery returns a


cached route from local cache or from a nearby node

 After a time-out, TCP sender transmits a packet on


the new route.
However, the cached route has also broken after it
was cached

timeout due timeout, cached timeout, second cached


to route failure route is broken route also broken

 Another route discovery, and TCP time-out interval


 Process repeats until a good route is found
261
Issues
To Cache or Not to Cache
 Caching can result in faster route “repair”

 Faster does not necessarily mean correct

 If incorrect repairs occur often enough, caching


performs poorly

 Need mechanisms for determining when cached


routes are stale

262
Caching and TCP performance

 Caching can reduce overhead of route discovery


even if cache accuracy is not very high

 But if cache accuracy is not high enough, gains in


routing overhead may be offset by loss of TCP
performance due to multiple time-outs

263
Issues
Window Size After Route Repair

 Same as before route break: may be too optimistic

 Same as startup: may be too conservative

 Better be conservative than overly optimistic


 Reset window to small value after route repair
 Impact low on paths with small delay-bw product

264
Issues
RTO After Route Repair

 Same as before route break


 If new route long, this RTO may be too small, leading to timeouts
• Except when RTT small compared to clock granularity

 Same as TCP start-up (6 second)


 May be too large
 Will result in slow response to future losses

 Proposal: new RTO = function of old RTO, old route length, and
new route length
 Example: new RTO = old RTO * new route length / old route length
 Not evaluated yet

265
Impact of MAC - Delay Variability

 As wireless medium is shared between multiple


sources, the round-trip delay is variable
 Also, on slow wireless networks, delay is large
 made larger by send-receive turnaround time
 Large and variable delays result in larger RTO
 On packet loss, timeout takes much longer to occur
 Idle source (waiting for timeout to occur) lowers TCP
throughput

266
Impact of MAC - Delay Variability
[Balakrishnan97]
Several techniques may be used to mitigate problem,
based on minimizing ack transmissions
 to reduce frequency of send-receive turnaround and
contention between acks and data
 Piggybacking link layer acks with data
 Sending fewer TCP acks - ack every d-th packet (d
may be chosen dynamically)
• but need to use rate control at sender to reduce
burstiness (for large d)
 Ack filtering - Gateway may drop an older ack in the
queue, if a new ack arrives
 reduces number of acks that need to be delivered to the
sender

267
Out-of-Order Packet Delivery

 Route changes may result in out-of-order (OOO)


delivery

 Significantly OOO delivery confuses TCP, triggering


fast retransmit

 Potential solutions:
 Avoid OOO delivery by ordering packets before delivering to IP
layer
• can result in variable delay
 turn off fast retransmit
• can result in poor performance in presence of congestion

268
Other Topics

269
Header Compression for Wireless Networks
[Degermark96]
 In TCP packet stream, most header bits are identical
 Van Jacobson’s scheme exploits this observation to compress
headers, by only sending the “delta” between the previous and
current header
 Packet losses result in inefficiency, as headers cannot be
reconstructed due to lost information
 Packet losses likely on wireless links
 [Degermark96] proposes a technique that works well despite
single packet loss
 “twice” algorithm
 if current packet fails TCP checksum, assume that a single packet is lost
 apply delta for the previous packet twice to the current header, and test
checksum again

270
Twice Algorithm : Example

delta 2 delta

271
Channel State Dependent Packet Scheduling
[Bhagwat96]
 Head-of-the Line blocking can occur with FIFO (first-
in-first-out) scheduling, if sender attempts to
retransmit packets on a channel in a bad state

M1

Wireless
M1 M2 M2 M3 M1 card
M2

M3

272
Channel State Dependent Packet Scheduling

 Separate queue for each destination


 Channel state monitor somehow determines if a
channel is in burst error state

M1
M1 M1
Wireless
M2 M2 scheduler card
M2
Per
M3
destination
queues
Channel status M3
monitor
273
Channel State Dependent Packet Scheduling

 Packets transmitted on bad channels, only if packets


for no other channels present in queues

M1
M1 M1
Wireless
M2 M2 scheduler card
M2
Per
M3
destination
queues
Channel status M3
monitor
274
Channel State Dependent Packet Scheduling

 Needs a reasonably good Channel State Monitor

M1
M1 M1
Wireless
M2 M2 scheduler card
M2
Per
M3
destination
queues
Channel status M3
monitor
275
Automatic TCP Buffer Tuning [Semke98]

 Using too small buffers can yield poor performance

 Using too large buffers can limit number of open


connections

 Automatic mechanisms to choose buffer size


dynamically would be useful

276
Tutorial Outline

 TCP over Satellite


 Impact of mobility on TCP performance
 Approaches to improve TCP performance in
presence of mobility
 Issues in multi-hop wireless networks
 Issues needing further work
 References

277
Issues for Further Investigation

278
Link Layer Protocols

 “Pure” link layer designs that support higher transport


performance
 some recent work in this area as noted earlier

 Identifying scenarios where link layer solutions are


inadequate

 If TCP-awareness is absolutely needed, provide an


interface that can be used by other transport
protocols too

279
End-to-End Techniques

 Existing techniques typically require cooperation from


intermediate nodes.
 Such techniques often not applicable
 encrypted TCP headers
 TCP data and acks do not go through same base station

 End-to-end techniques would rely on information


available only at end nodes
 Harder to design due to lack of complete information about
errors
 Explicit Notifications may make that easier

280
Impact of Congestion Losses

 Past work typically evaluates performance in absence


of congestion

 Relative performance improvement may change


substantially when congestion occurs
 performance improvement may reduce if congestion is
dominant, or if RTO becomes larger due to wireless errors

281
Multiple TCP Transfers

 Past work typically measures a single TCP connection


over wireless
 TCP throughput is the metric of choice

 When multiple connections share a wireless link, other


performance metrics may make sense
 fairness
 aggregate throughput

 Relative performance improvements of various


schemes may change when multiple connections are
considered
282
TCP Window & RTO Settings After a Move

 Congestion window & RTO size at connection open


are chosen to be conservative
 When a route change occurs due to mobility, which
values to use?
 Same as before route change ---- may be too aggressive
 Same as at connection open ---- may be too conservative
 Answer unclear
 some proposals attempt to use same values as before route
change, but not clear if that is the best alternative

283
TCP for Mobile Ad Hoc Networks

 Much work on routing in ad hoc networks


 Some recent work on TCP for ad hoc networks
 Need to investigate many issues
 MAC-TCP interaction
 routing-TCP interaction
 impact of route changes on window size, RTO choice after
move

284
References

 Please see attached listing for the references cited in


the tutorial

285
Thank you !!

For more information, send e-mail to


Nitin Vaidya at
nhv@uiuc.edu

© 2001 Nitin Vaidya


286

You might also like