1 tcp for wireless and mobile hosts nitin h. vaidya university of illinois at urbana-champaign...

1

TCP for Wireless and Mobile Hosts

Nitin H. Vaidya

University of Illinois at Urbana-Champaign

[email protected]

http://www.crhc.uiuc.edu/~nhv

© 2001 Nitin Vaidya

2

Notes

Names in brackets, as in [Vaidya99], refer to a document in the list of references

Many charts included in these slides are based on similar results presented in graphs in published literatures. Since, in many cases, exact numbers are not provided in the papers, the charts in these slides are based on “guess-timates” obtained from published graphs. Please refer original sources for accurate data.

This handout may not be as readable as the original slides, since the slides contain colored text and figures.

3

Notes

PowerPoint source for tutorial slides and reference list for the tutorial are presently available at

http://www.cs.tamu.edu/faculty/vaidya/

(follow the link to Seminars)

http://www.cs.tamu.edu/faculty/vaidya/

4

Internet Engineering Task Force (IETF)Activities

IETF pilc (Performance Implications of Link Characteristics) working group http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov Refer [Dawkins99] and [Montenegro99] for an overview of

related work

IETF tcpsat (TCP Over Satellite) working group http://www.ietf.org/html.charters/tcpsat-charter.html http://tcpsat.grc.nasa.gov/tcpsat/ Refer [Allman98] for overview of satellite related work

http://www.ietf.org/html.charters/pilc-charter.html

http://pilc.grc.nasa.gov/

http://pilc.grc.nasa.gov/

http://www.ietf.org/html.charters/tcpsat-charter.html

http://tcpsat.grc.nasa.gov/tcpsat/

5

Internet Engineering Task Force (IETF)Activities

IETF manet (Mobile Ad-hoc Networks) working group http://www.ietf.org/html.charters/manet-charter.html

IETF mobileip (IP Routing for Wireless/Mobile Hosts) working group http://www.ietf.org/html.charters/mobileip-charter.html

http://www.ietf.org/html.charters/manet-charter.html

http://www.ietf.org/html.charters/mobileip-charter.html

6

Tutorial Outline

Wireless technologies TCP basics Impact of transmission errors on TCP performance Approaches to improve TCP performance

Classification Discussion of selected approaches

TCP over satellite

7

Tutorial Outline

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

8

Notable Omissions

Wireless ATM

WAP (Wireless Application Protocol)

http://www.wapforum.com

9

Wireless Technologies

10

Wireless Technologies

Wireless local area networks Cellular wireless Satellites Multi-hop wireless Wireless local loop

11

Wireless Local Area Networks

Local area connectivity using wireless communication IEEE 802.11 WLAN Standard Example: WaveLan, Aironet Wireless LAN may be used for

last hop to a wireless host wireless connectivity between hosts on the LAN

12

Cellular Wireless

Space divided into cells A base station is responsible to communicate with

hosts in its cell Mobile hosts can change cells while communicating Hand-off occurs when a mobile host starts

communicating via a new base station

13

Multi-Hop Wireless

May need to traverse multiple links to reach a destination

14

Multi-Hop Wireless - MobilityMobile Ad Hoc Networks (MANET)

Mobility causes route changes

15

Multi-Hop Wireless Metricom’s Ricochet Network

Around 28.8 Kbps (128 Kbps to come)

Poletopradio

Wireless hosts

internet

modem

16

Satellites

Geostationary Earth Orbit (GEO) Satellites example: Inmarsat

SAT

ground stations

17

Satellites

Low-Earth Orbit (LEO) Satellites example: Iridium (66 satellites) (2.4 Kbps data)

SAT

ground stations

SAT

SAT

constellation

18

Satellites

GEO long delay - 250-300 ms propagation delay

LEO relatively low delay - 40 - 200 ms large variations in delay - multiple hops/route changes,

relative motion of satellites, queueing

19

Wireless Connectivity - Characteristics Transmission errors

Wireless LANs - 802.11, Hyperlan Cellular wireless Multi-hop wireless Satellites

Low bandwidth Cellular wireless Packet radio (e.g., Metricom)

Long or variable latency GEO, LEO satellites Packet radio - high variability

Asymmetry in bandwidth, error characteristics Satellites (example: DirectPC)

20

Transmission Control Protocol / Internet Protocol

TCP/IP

21

Internet Protocol (IP)

Packets may be delivered out-of-order

Packets may be lost

Packets may be duplicated

22

Transmission Control Protocol (TCP)

Reliable ordered delivery

Implements congestion avoidance and control

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

23

TCP Basics

Cumulative acknowledgements

An acknowledgement ack’s all contiguously received data

TCP assigns byte sequence numbers For simplicity, we will assign packet sequence

numbers Also, we use slightly different syntax for acks than

normal TCP syntax In our notation, ack i acknowledges receipt of packets

through packet i

24

40 39 3738

3533

Cumulative Acknowledgements

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

41 40 3839

35 37

3634

3634

i data acki

25

Delayed Acknowledgements

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

Reduces ack traffic

40 39 3738

3533

41 40 3839

35 37

New ack not producedon receipt of packet 36,

but on receipt of 37

26

Duplicate Acknowledgements

A dupack is generated whenever an

out-of-order segment arrives at the receiver

40 39 3738

3634

42 41 3940

36 36

Dupack

(Above example assumes delayed acks)On receipt of 38

27

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 3837

3634

41 40 3739

36 36

DupackOn receipt of 38

28

Number of dupacks depends on how much OOO a packet is

40 39 3837

3634

41 40 3739

36 36

Dupack

42 41 3940

36 36 38

New Ack

New AckNew Ack

New Ack

34

New Ack

DupackNew Ack

29

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

2 3 4 5 6 7 8 9 10 11 131 12

Sender’s window

Acks received Not transmitted

30


2 3 4 5 6 7 8 9 10 11 131 12

Sender’s window

2 3 4 5 6 7 8 9 10 11 131 12

Sender’s window

Ack 5

31

Ack Clock

TCP window flow control is “self-clocking”

New data sent when old data is ack’d

Helps maintain “equilibrium”

32


Congestion window size bounds the amount of data that can be sent per round-trip time

Throughput <= W / RTT

33

Ideal Window Size

Ideal size = delay * bandwidth delay-bandwidth product

What if window size < delay*bw ? Inefficiency (wasted bandwidth)

What if > delay*bw ? Queuing at intermediate routers

• increased RTT due to queuing delays Potentially, packet loss

34

How does TCP detect a packet loss?

Retransmission timeout (RTO)

Duplicate acknowledgements

35

Detecting Packet Loss Using 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

36

Retransmission Timeout (RTO) calculation

RTO = mean + 4 mean deviation Standard deviation average of (sample – mean) Mean deviation average of |sample – mean| Mean deviation easier to calculate than standard deviation Mean deviation is more conservative

Large variations in the RTT increase the deviation, leading to larger RTO

2 2

37

Timeout Granularity

RTT is measured as a discrete variable, in multiples of a “tick”

1 tick = 500 ms in many implementations

smaller tick sizes in more recent implementations (e.g., Solaris)

RTO is at least 2 clock ticks

38

Exponential Backoff

Double RTO on each timeout

Packettransmitted

Time-out occursbefore ack received,packet retransmitted

Timeout interval doubled

T1 T2 = 2 * T1

39

Fast Retransmission

Timeouts can take too long how to initiate retransmission sooner?

Fast retransmit

40

Detecting Packet Loss Using DupacksFast Retransmit Mechanism

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

12 8 7910113 dupacks are also generated if a packetis delivered at least 3 places beyond itsin-sequence location

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

41

Congestion Avoidance and Control

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

cwnd grows exponentially with time during slow start factor of 1.5 per RTT if every other packet ack’d factor of 2 per RTT if every packet ack’d Could be less if sender does not always have data to send

42

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

43

0

2

4

6

8

10

12

14

0 1 2 3 4 5 6 7 8

Time (round trips)

Con

gest

ion

Win

dow

size

(s

egm

ents

)

Slow start

Congestionavoidance

Slow start threshold

Example assumes that acks are not delayed

44

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

45

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

46

0

5

10

15

20

25

0 3 6 9 12 15 20 22 25

Time (round trips)

Con

gest

ion

win

dow

(se

gmen

ts)

ssthresh = 8 ssthresh = 10

cwnd = 20

After timeout

47

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

48

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

49

0

2

4

6

8

10

Time (round trips)

Win

dow

size

(seg

men

ts)

After fast retransmit and fast recovery window size isreduced in half.

Receiver’s advertized window

After fast recovery

50

TCP Reno

Slow-start Congestion avoidance Fast retransmit Fast recovery

51

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

52

Impact of transmission errorson TCP performance

53

Tutorial Outline



54

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

55

Random Errors May Cause Fast Retransmit

40 39 3738

3634

Example assumes delayed ack - every other packet ack’d

56


41 40 3839

3634


57


42 41 3940

36

Duplicate acks are not delayed

36

dupack

58


40

363636

Duplicate acks

4143 42

59


41

3636

3 duplicate acks triggerfast retransmit at sender

4244 43

36

60


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

61

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]

62

This Tutorial

We consider errors for which reducing congestion window is an inappropriate response

63

Impact of Random Errors [Vaidya99]

0

400000

800000

1200000

1600000

16384 32768 65536 131072

1/error rate (in bytes)

bits/sec

Exponential error model2 Mbps wireless full duplex linkNo congestion losses

64

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

65

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

66

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)

67

Impact of Transmission Errors

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

Unnecessarily reduces congestion window Throughput suffers

68

Tutorial Outline



69

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

70

Techniques to Improve TCP Performancein 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

71

Techniques to Improve TCP Performancein 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

72

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

73

Tutorial Outline



74

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

75

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

76

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]

77

Link Level Mechanisms

78

Link Layer MechanismsForward 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

79

Link Layer MechanismsLink 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

80

Link Layer Mechanisms

In general

Use FEC to correct a small number of errors

Use link level retransmission when FEC capability is exceeded

81

Link Level Retransmissions

wireless

physical

link

network

transport

application

physical

link

network

transport

application

physical

link

network

transport

application

rxmt

TCP connection

Link layer state

82

Link Level RetransmissionsIssues

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

83


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

84


Retransmissions can cause head-of-the-line blocking

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

Base station

Receiver 1

Receiver 2

85


Retransmissions can cause congestion losses

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 ?

Base station

Receiver 1

Receiver 2

86

Link Level RetransmissionsAn 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

87

RTO Variations

Packet loss

RTT sample

RTO

Wireless

88

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]

89

Link Level RetransmissionsA 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

90

Link-Layer RetransmissionsA 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

1 2

data ack

Timeout = RTO

Effectively, Timeout = RTT of packet 1 + RTO

Reset, Timeout = RTO

91

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

92

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

3,4,5 triggers dupacks

6 2 5 234 1

Lost packet

Retransmitted packet

93

Link Level RetransmissionsIn-order delivery

To avoid unnecessary fast retransmit, link layer using retransmission should attempt to deliver packets “almost in-order”

6 5 4 223

6 5 2 234

1

1

94

Link Level RetransmissionsIn-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)

95

Adaptive Link Layer Strategies[Lettieri98,Eckhardt98,Zorzi97]

Adaptive protocols attempt to dynamically choose:

FEC code

retransmission limit

frame size

96

Link Layer Retransmissions [Vaidya99]

0

400000

800000

1200000

1600000

2000000

16384

32768

65536

1E+

05


base TCP

Link layerretransmission

2 Mbps wireless duplex link with 1 ms delayExponential error modelNo congestion losses

20 ms 1 ms

10 Mbps 2 Mbps

97

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

98

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

99

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

100

Split Connection Approach

101


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

102


Connection between wireless host MH and fixed host FH goes through base station BS

FH-MH = FH-BS + BS-MH

FH MHBS

Base Station Mobile HostFixed Host

103


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 MHBS

Base Station Mobile HostFixed Host

104


wireless

physical

link

network

transport

application

physical

link

network

transport

application

physical

link

network

transport

application rxmt

Per-TCP connection state

TCP connection TCP connection

105

Split Connection ApproachIndirect TCP [Bakre95,Bakre97]

FH - BS connection : Standard TCP BS - MH connection : Standard TCP

106

Split Connection ApproachSelective 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

107

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

108

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]

109

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

110

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

111

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

FH MHBS

40

39

3738

3640

112


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

FH MHBS

40

39

3738

3640

113


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

FH MHBS

40

39

3738

3640

MH

New base station

Hand-off

40

39

114


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

115


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

FH MH

data

ack

116

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

117

TCP-Aware Link Layer

118

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

119

Snoop Protocol

FH MHBSwireless

physical

link

network

transport

application

physical

link

network

transport

application

physical

link

network

transport

application

rxmt

Per TCP-connection state

TCP connection

120

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 MHBS

121

Snoop : Example

FH MHBS

40 39 3738

3634


36

37

38

35 TCP statemaintained at

link layer

122

Snoop : Example

41 40 3839

3634

36

37

38

35 39

123

Snoop : Example

42 41 3940

36


36

dupack

37

38

39

40

124

Snoop : Example

40

363636

Duplicate acks

4143 42

37

38

39

40

41

125

Snoop : Example

FH MHBS

41

3636

3744 43

36

37

38

39

40

41

42

Discarddupack

Dupack triggers retransmissionof packet 37 from base station

BS needs to be TCP-aware to

be able to interpret TCP headers

126

Snoop : Example

37

36

36

4245 44

36

37

38

39

40

41

42

43

36

127

Snoop : Example

42

36

36

4346 45

36

37

38

39

40

41

42

43

41

36

44

TCP sender does notfast retransmit

128

Snoop : Example

43

3636

4447 46

36

37

38

39

40

41

42

43

41

36

44


45

129

Snoop : Example

FH MHBS

44

3636

4548 47

36

42

43

41

36

44

45

43

46

130

Snoop [Balakrishnan95acm]

0

400000

800000

1200000

1600000

2000000

16

K

32

K

64

K

12

8K

25

6K

no

erro

r


bit

s/s

ec

base TCP

Snoop

2 Mbps Wireless link

131

Snoop ProtocolWhen 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

132

Snoop Protocol : Classification

Hides wireless losses from the sender

Requires modification to only BS (network-centric approach)

133

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

134

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)

135

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 MHBS

136

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 MHBS

137

WTCP Example

FH BS MH3 3

34

Numbers in this figure are timestamps

Base station residence time is 1 unit

138

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

139

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

140

TCP-Unaware Approximation of TCP-Aware Link Layer

141

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)

142

Delayed Dupacks Protocol

wireless

physical

link

network

transport

application

physical

link

network

transport

application

physical

link

network

transport

application

rxmt

TCP connection

Link layer state

143


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

144


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

145


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

146

Delayed Dupacks : Example

40 39 3738

3634


Link layer acks are not shown

36

37

38

35

Link layer state

147


BS

41 40 3839

3634

36

37

38

39

35 Removed from BS link layer buffer on receipt of alink layer ack (LL acks not shown in figure)

148


42 41 3940

36


36

dupack

37

38

39

40

149


40

363636

Duplicate acks

4143 42

37

38

39

40

41

Original ack

150


41

3636

3744 43

36

37

39

40

41

42

Base station forwards dupacks

dupack dupacksDelayeddupack

151


37

3636

4245 44

36

37

40

41

42

36dupacks

Delayed dupacks

43

152


424346 45

36

37

41

42

43

41


44

Delayed dupacks arediscarded if lost

packet received beforedelay D expires

153

Delayed Dupacks [Vaidya99]

0

400000

800000

1200000

1600000

2000000

16384

32768

65536

1E+

05


base TCP

dupack delay80ms + LLRetransmitOnly LLretransmit

2 Mbps wireless duplex link with 20 ms delayNo congestion losses

20 ms 20 ms

10 Mbps 2 Mbps

154

Delayed Dupacks [Vaidya99]

020000400006000080000

100000120000140000160000

16

38

4

32

76

8

65

53

6

1E

+0

5


base TCP

dupack delay80ms + LLRetransmitOnly LLretransmit

5% packet loss due to congestion

20 ms 20 ms

10 Mbps 2 Mbps

155

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

156

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

157

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

158

Explicit Notification

159

Explicit Notification SchemesGeneral 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

160

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

161

Explicit NotificationSpace Communication Protocol Standards-

Transport Protocol (SCPS-TP)

Satellite

Ground station

wireless

TCP destinations

162

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)

163

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

MH FHBS4 3 2 1 134

wireless

Recordhole at 2

111 1

Dupack with ELN set

164

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

165

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

166

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

36

Partial ack

37

Cumulative ack

167

Variations

Base station may or may not locally buffer and retransmit lost packets

Partial ack for all packets or a subset ?

37

36

Partial ack

37

Cumulative ack

168

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

169

Explicit Loss Notification [Biaz99thesis]when MH is TCP receiver

37

36

37

3839

39

38

Sequence numberscached at base station

37 37

Dupack with ELN

170

Various Schemes


171

Receiver-Based Discrimination Scheme

172

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

173

Receiver-Based Scheme

Packet loss due to congestion

FH MHBS

1012 11

FH MHBS

11

1012

T

Congestion loss

174


Packet loss due to transmission error

FH MHBS

1012 11

FH MHBS

101112Error loss

2 T

175


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

176

Receiver-Based SchemeDiagnostic Accuracy [Biaz99Asset]

Congestion losses Error losses

177

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

178

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

179

Various Schemes


180

Sender-Based Discrimination Scheme

181

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)

182

Heuristics for Congestion Avoidance

loadload

RTT

throughput

knee

cliff

183

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

184

Heuristics for Congestion AvoidanceSome 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)

185


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)

186


TCP Vegas [Brakmo94]

expected throughput ET = W(i) / RTTmin

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

Condition C = ( ET-AT > beta)

187

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

188

Sender-Based SchemesDiagnostic Accuracy [Biaz99ic3n]

189

Sender-Based SchemesDiagnostic Accuracy [Biaz99ic3n]

190

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

191

Sender-Based Heuristics : Advantages

Only sender needs to be modified

Needs further investigation to develop better heuristics investigate longer-term heuristics

192

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

Fra

ctio

n o

f T

CP

c

on

ne

cti

on

s

Coefficient of correlation (RTT,W)

193

Statistical TechniquesFuture Work

Other statistical measures ?

Mechanisms that achieve good TCP throughput despite not-too-good diagnostic accuracy

194

TCP in Presence of Transmission ErrorsSummary

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

195

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


196

TCP Over Satellite

197

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

198

Problems Addressed by Various Schemes

Long delay Large delay-bandwidth products Transmission errors

199

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

200

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

201

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

202

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

203

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

204

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

205

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]

206

Tutorial Outline



207

Impact of Mobility on TCP Performance

208

Impact of Mobility

Hand-offs occur when a mobile host starts communicating with a new base station (in cellular wireless systems)

209

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

210

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

211

Mobile IP [Johnson96]

Router1

Router3

Router2

S MH

Home agent

212

Mobile IP [Johnson96]

Router1

Router3

Router2

S MH

Home agent

Foreign agent

move

Packets are tunneledusing IP in IP

213

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

OldBS

NewBS

MH

2

1

3

4

5,6

7

214

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

OldBS

NewBS

MH

2

1

3

4

5,6

7

215

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

216

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

217

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

218

Techniques to Improve TCP Performance

in Presence of Mobility

219

Classification

Hide mobility from the TCP sender

Make TCP adaptive to mobility

220

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

221

0-second Rendezvous Delay : Beacon arrives as soon as cell boundary crossed

Lasttimedtransmit

Cell crossing+ beaconarrives

Handoff completeRoutes updated

Retransmissiontimeout

0 0.15 0.8 sec

1.0

Packet loss Idle sender

222

1-second Rendezvous Delay : Beacon arrives 1 second after cell boundary crossed

Lasttimedtransmit

0 0.8

2.0

Timeout 1

Cell crossing

Packet loss

Retransmissiontimeout 2

Handoffcomplete

Beacon arrives

1.0

1.0 1.15

Idle sender

2.8 sec

223

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

224

TCP Performance

1600 1510 14001100

0200400600800

10001200140016001800

No move

s

overla

pping

cells

non-o

verla

p/0 d

elay

non-o

verla

p/1 s

ec.

Kbit/sec

225

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

226

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

227

0-second Rendezvous DelayImprovement using Fast Retransmit

Lasttimedtransmit

Cell crossing+ beaconarrives

Handoff completeRoutes updated

Retransmissiontimeoutdoes not occur

0 0.15 0.8

1.0

Packet loss

Fast retransmit

Idle sender

228

TCP Performance Improvement

16001510 1490

13801400

1100

0

200

400

600

800

1000

1200

1400

1600

1800

1 2 3 4

Kbit/sec

With fast rxmit

229

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

230

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

231

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

232

M-TCP UsesTCP 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

233

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

FH MHBS

Ack 1000Ack 999

234

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 MHBS

235

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)

236

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.

237

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)

FH MHBS

MobileTCP receiver

238

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

FH MHBS

MobileTCP receiver

239

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

240

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

241

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

242

Tutorial Outline



243

TCP in Mobile Ad Hoc Networks

244

Mobile Ad Hoc Networks (MANET)

May need to traverse multiple links to reach a destination

245

Mobile Ad Hoc Networks[IETF-MANET]

Mobility causes route changes

246

TCP in Mobile Ad Hoc NetworksIssues

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

247

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

248

Impact of Multi-Hop Wireless Paths [Holland99]

0

200

400

600

800

1000

1200

1400

1600

1 2 3 4 5 6 7 8 9 10

Number of hops

TCPThroughtput(Kbps)

TCP Throughput using 2 Mbps 802.11 MAC

249

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)

250

Impact of MobilityTCP Throughput

Ideal throughput (Kbps)

Act

ual t

hrou

ghpu

t

2 m/s 10 m/s

251

Impact of Mobility

Ideal throughput

Act

ual t

hrou

ghpu

t

20 m/s 30 m/s

252

Throughput generally degrades with increasing

speed …

Speed (m/s)

AverageThroughputOver 50 runs

Ideal

Actual

253

But not always …

Mobility pattern #

Actualthroughput

20 m/s

30 m/s

254

mobility causeslink breakage,resulting in routefailure

TCP data and acksen route discarded

Why Does Throughput Degrade?

TCP sender times out.Starts sending packets again

Route isrepaired

No throughput

No throughputdespite route repair

255

mobility causeslink breakage,resulting in routefailure

TCP data and acksen route discarded

Why Does Throughput Degrade?

TCP sendertimes out.Backs off timer.

Route isrepaired

TCP sendertimes out.Resumessending

Larger route repair delaysespecially harmful

No throughput

No throughput

despite route repair

256

Why Does Throughput Improve?Low Speed Scenario

C

B

D

A

C

B

D

A

C

B

D

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.

257

Why Does Throughput Improve?Higher (double) Speed Scenario

C

B

D

A

C

B

D

A

C

B

D

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.

258

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

259

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

260

Performance Improvement

Without networkfeedback

Ideal throughput 2 m/s speed

With feedback

Act

ua

l thr

oug

hpu

t

261

Performance Improvement

Without networkfeedback

With feedback

Ideal throughput 30 m/s speed

Act

ua

l thr

oug

hpu

t

262

Performance with Explicit Notification[Holland99]

0

0.2

0.4

0.6

0.8

1

2 10 20 30

mean speed (m/s)

thro

ug

hp

ut

as a

fra

ctio

n o

f id

eal

Base TCP

With explicitnotification

263

IssuesNetwork 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

264

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

265

To Cache or Not to Cache

Average speed (m/s)Ac t

ual t

hrou

ghpu

t (a s

fra

ctio

n of

exp

ecte

d th

roug

hput

)

266

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

Another route discovery, and TCP time-out interval Process repeats until a good route is found

timeout dueto route failure

timeout, cachedroute is broken

timeout, second cachedroute also broken

267

IssuesTo 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

268

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

269

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

270

IssuesRTO 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

271

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

272

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

273

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

274

Other Topics

275

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

276

Twice Algorithm : Example

delta 2 delta

277

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 M2 M3M2 M1Wireless

card

M1

M2

M3

278

Channel State Dependent Packet Scheduling

Separate queue for each destination Channel state monitor somehow determines if a

channel is in burst error state

M1

M2

M3

M2

M1Wireless

card

M1

M2

M3

scheduler

Channel statusmonitor

Perdestinationqueues

279


Packets transmitted on bad channels, only if packets for no other channels present in queues

M1

M2

M3

M2

M1Wireless

card

M1

M2

M3

scheduler



280


Needs a reasonably good Channel State Monitor

M1

M2

M3

M2

M1Wireless

card

M1

M2

M3

scheduler



281

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

282

Tutorial Outline



283

Issues for Further Investigation

284

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

285

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

286

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

287

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

288

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

289

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

290

References

Please see attached listing for the references cited in the tutorial

1 tcp for wireless and mobile hosts nitin h. vaidya university of illinois at urbana-champaign...

Documents