tcp wireless tutorial

8/8/2019 Tcp Wireless Tutorial

http://slidepdf.com/reader/full/tcp-wireless-tutorial 1/291

1

TCP for Wireless and Mobile Hosts

Nitin H. VaidyaUniversity of Illinois at Urbana-Champaign

[email protected]://www.crhc.uiuc.edu/~nhv

© 2001 Nitin Vaidya



2

Notes

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

Many charts included in these slides are based onsimilar results presented in graphs in publishedliteratures. Since, in many cases, exact numbers arenot provided in the papers, the charts in these slidesare based on “guess-timates” obtained frompublished graphs. Please refer original sources for accurate data.

This handout may not be as readable as the originalslides, since the slides contain colored text andfigures.



3

Notes

PowerPoint source for tutorial slides and referencelist for the tutorial are presently available at

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

(follow the link to Seminars)





4

Internet Engineering Task Force (IETF)Activities

IETF pilc ( Performance Implications of LinkCharacteristics) working group

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

http://pilc.grc.nasa.gov Refer [Dawkins99] and [Montenegro99] for an overview of relatedwork

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


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

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

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

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

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






5

Internet Engineering Task Force (IETF)Activities

IETF manet ( Mobile Ad-hoc Networks) working grouphttp://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/manet-charter.html



6

Tutorial Outline

Wireless technologiesTCP basicsImpact of transmission errors on TCP performanceApproaches to improve TCP performance

ClassificationDiscussion of selected approaches

TCP over satellite



7

Tutorial Outline

Impact of mobility on TCP performanceApproaches to improve TCP performance inpresence of mobilityIssues in multi-hop wireless networksIssues needing further workReferences



8

Notable Omissions

Wireless ATM

WAP (Wireless Application Protocol)http://www.wapforum.com



9

Wireless Technologies



10

Wireless Technologies

Wireless local area networksCellular wirelessSatellites

Multi-hop wirelessWireless local loop



11

Wireless Local Area Networks

Local area connectivity using wireless communicationIEEE 802.11 WLAN StandardExample: WaveLan, Aironet

Wireless LAN may be used for last hop to a wireless hostwireless connectivity between hosts on the LAN



12

Cellular Wireless

Space divided into cellsA base station is responsible to communicate withhosts in its cellMobile hosts can change cells while communicatingHand-off occurs when a mobile host startscommunicating via a new base station



14

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

Mobility causes route changes



15

Multi-Hop WirelessMetricom’s Ricochet Network

Around 28.8 Kbps (128 Kbps to come)

Poletopradio

Wireless hosts

internet

modem



16

Satellites

Geostationary Earth Orbit (GEO) Satellitesexample: 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

GEOlong delay - 250-300 ms propagation delay

LEOrelatively low delay - 40 - 200 mslarge variations in delay - multiple hops/route changes,relative motion of satellites, queueing



19

Wireless Connectivity - CharacteristicsTransmission errors

Wireless LANs - 802.11, HyperlanCellular wirelessMulti-hop wirelessSatellites

Low bandwidthCellular wirelessPacket radio (e.g., Metricom)

Long or variable latencyGEO, LEO satellitesPacket radio - high variability

Asymmetry in bandwidth, error characteristicsSatellites (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 semanticsAcknowledgements sent to TCP sender confirm delivery of datareceived by TCP receiver Ack for data sent only after data has reached receiver



23

TCP Basics

Cumulative acknowledgements

An acknowledgement ack’s all contiguously receiveddata

TCP assigns byte sequence numbersFor simplicity, we will assign packet sequence

numbersAlso, we use slightly different syntax for acks thannormal TCP syntax

In our notation, ack i acknowledges receipt of packetsthrough packet i



24

40 39 3738

3533

Cumulative Acknowledgements

A new cumulative acknowledgement is generatedonly 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 untilanother 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 anout-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 AcknowledgementsDuplicate acks are not delayed

Duplicate acks may be generated whena 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



29

Window Based Flow Control

Sliding window protocolWindow size minimum of

receiver’s advertised window - determined by availablebuffer 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 datathat can be sent per round-trip time

Throughput <= W / RTT



33

Ideal Window Size

Ideal size = delay * bandwidthdelay-bandwidth product

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

What if > delay*bw ?Queuing at intermediate routers

• increased RTT due to queuing delaysPotentially, packet loss



34

How does TCP detect a packet loss?

Retransmission timeout ( RTO )

Duplicate acknowledgements



35

Detecting Packet Loss UsingRetransmission Timeout (RTO)

At any time, TCP sender sets retransmission timer for only one packet

If acknowledgement for the timed packet is notreceived before timer goes off, the packet is assumedto be lost

RTO dynamically calculated



36

Retransmission Timeout (RTO) calculation

RTO = mean + 4 mean deviationStandard deviation σ : σ = average of (sample – mean)Mean deviation δ = average of |sample – mean|

Mean deviation easier to calculate than standard deviationMean deviation is more conservative : δ >= σ

Large variations in the RTT increase the deviation, leadingto larger RTO

2 2



37

Timeout Granularity

RTT is measured as a discrete variable, in multiplesof 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 doubledT1 T2 = 2 * T1



39

Fast Retransmission

Timeouts can take too longhow to initiate retransmission sooner?

Fast retransmit



40

Detecting Packet Loss Using DupacksFast Retransmit Mechanism

Dupacks may be generated due topacket loss, or out-of-order packet delivery

TCP sender assumes that a packet loss has occurredif 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 Startinitially, congestion window size cwnd = 1 MSS(maximum segment size)increment window size by 1 MSS on each new ackslow start phase ends when window size reaches theslow-start threshold

cwnd grows exponentially with time during slow startfactor of 1.5 per RTT if every other packet ack’dfactor of 2 per RTT if every packet ack’dCould 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 congestionavoidance

1/2 MSS per RTT if every other packet ack’d1 MSS per RTT if every packet ack’d



43

0

2

4

6

8

1012

14

0 1 2 3 4 5 6 7 8

Time (round tri

C o n g e s t i o n W i n d o w s i z e

( s e g m e n t s )

Slow start

Congestion

avoidance

Slow startthreshold

Example assumes that acks are not delayed



44

Congestion Control

On detecting a packet loss, TCP sender assumesthat network congestion has occurred

On detecting packet loss, TCP sender drasticallyreduces the congestion window

Reducing congestion window reduces amount of datathat can be sent per RTT

throughput may decrease



45

Congestion Control -- Timeout

On a timeout, the congestion window is reduced tothe initial value of 1 MSS

The slow start threshold is set to half the window sizebefore packet loss

more precisely,

ssthresh = maximum of min(cwnd,receiver’sadvertised window)/2 and 2 MSS

Slow start is initiated



46

0

5

10

15

20

25

0 3 6 9 1 2 1 5 2 0 2 2 2 5

Time (round trips)

C o n g e s t i o n w

i n d o w

( s e g m e n t s

)

ssthresh = 8 ssthresh = 10

cwnd = 20

After timeout



47

Congestion Control - Fast retransmit

Fast retransmit occurs when multiple (>= 3) dupackscome back

Fast recovery follows fast retransmit

Different from timeout : slow start follows timeouttimeout occurs when no more packets are getting acrossfast retransmit occurs when a packet is lost, but latter packets

get throughack clock is still there when fast retransmit occursno 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 dupackswhen a new ack comes: cwnd = ssthreh

enter congestion avoidance

Congestion window cut into half



49

0

2

4

6

8

10

0 2 4 6 8 1 0 12 14

Tim e (round tri

W i n d o w s i z e ( s e g m e n t s )

After fast retransmit and fast recovery window sizeisreduced in half.

Receiver’s advertized window

After fast recovery



50

TCP Reno

Slow-startCongestion avoidanceFast retransmitFast 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 atimeout

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

Wireless technologiesTCP basicsImpact of transmission errors on TCP performance

Approaches to improve TCP performanceClassificationDiscussion of selected approaches



54

Random Errors

If number of errors is small, they may be corrected byan error correcting codeExcessive bit errors result in a packet beingdiscarded, 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 inretransmission of lost packetreduction in congestion window

Reducing congestion window in response to errors is

unnecessaryReduction in congestion window reduces thethroughput



61

Sometimes Congestion Response May beAppropriate in Response to Errors

On a CDMA channel, errors occur due to interferencefrom 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 windowIf 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 doesnot unnecessarily attempt retransmissions while thechannel remains in the bad state[Padmanabhan99pilc]



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 notnecessarily obtained using same system model,comparison of absolute numbers in different graphsmay not be valid

Observe trends, rather than absolute numbers



65

Burst Errors May Cause Timeouts

If wireless link remains unavailable for extendedduration, a window worth of data may be lost

driving through a tunnelpassing a truck

Timeout results in slow startSlow start reduces congestion window to 1 MSS,reducing throughputReduction in window in response to errorsunnecessary



66

Random Errors May Also Cause Timeout

Multiple packet losses in a window can result intimeout when using TCP-Reno (and to a lesser extent

when using SACK)



68

Tutorial Outline

Wireless technologiesTCP basicsImpact of transmission errors on TCP performance

Approaches to improve TCP performanceClassificationDiscussion of selected approaches



69

Classification of Schemes toImprove Performance of TCP inPresence of Transmission Errors

Techniques to Improve TCP Performance



70

Techniques to Improve TCP Performancein Presence of Errors

Classification 1

Classification based on nature of actions taken toimprove performance

Hide error losses from the sender if sender is unaware of the packet losses due to errors, it willnot reduce congestion window

Let sender know, or determine, cause of packet lossif sender knows that a packet loss is due to errors, it will notreduce congestion window

Techniques to Improve TCP Performance



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 simplyretransmit a packet lost due to transmission errors, withouttaking any congestion control actions

Such a TCP referred to as Ideal TCPIdeal TCP typically not realizable

Ideal network behavior : Transmission errors should be hiddenfrom the sender -- the errors should be recovered transparently and efficiently

Proposed schemes attempt to approximate one of the abovetwo ideals



74

Selected Schemes toImprove Performance of TCP inPresence of Transmission Errors



75

Caveat

When describing various schemes, only the major features are presented

Often, some additional features are present in theseschemes, to optimize their performance

We will not cover all the details, only the mostrelevant ones



76

Various Schemes

Link level mechanismsSplit connection approachTCP-Aware link layer TCP-Unaware approximation of TCP-aware link layer Explicit notificationReceiver-based discriminationSender-based discrimination

For a brief overview, see [Dawkins99,Montenegro99]



77

Link Level Mechanisms

Li k L M h i



78

Link Layer MechanismsForward Error Correction

Forward Error Correction ( FEC) [Lin83] can be useto 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 theoverhead by choosing appropriate FEC dynamically

Li k L M h i



79

Link Layer MechanismsLink Level Retransmissions

Link level retransmission schemes retransmit apacket 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 isexceeded



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 beforegiving up?

Finite bound -- semi-reliable link layer No bound -- reliable link layer

What triggers link level retransmissions?Link layer timeout mechanismLink 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 RTTLarge 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, thelink to receiver 2 may be in a good stateRetransmissions to receiver 1 are lost, and also blocka 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, potentiallymaking the queue at base station longer

If the queue gets full, packets may be lost, indicatingcongestion 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 functionof measured RTT (round-trip times)

Link level retransmits increase RTT, therefore, RTO

If errors not frequent , RTO will not account for RTTvariations due to link level retransmissions

When errors occur, the sender may timeout & retransmit beforelink level retransmission is successfulSender and link layer both retransmit

Duplicate retransmissions (interference) waste wireless bandwidthTimeouts also result in reduced congestion window



87

RTO Variations

Packet lossRTT sample

RTO

Wireless



88

A More Accurate Picture

Analysis in [DeSimone93] does not accurately model realTCP stacks

With large RTO granularity , interference is unlikely, if

time required for link-level retransmission is smallcompared to TCP RTO [Balakrishnan96Sigcomm]Standard TCP RTO granularity is often largeMinimum RTO (2*granularity) is large enough to allow a smallnumber of link level retransmissions, if link level RTT is relatively

smallInterference due to timeout not a significant issue when wirelessRTT small, and RTO granularity large [Eckhardt98]



Link-Layer RetransmissionsA M A Pi [L d i 98]



90

A More Accurate Picture [Ludwig98]

Timeout interval may actually be larger than RTORetransmission timer reset on an ackIf the ack’d packet and next packet were transmitted in aburst, 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 levelretransmits

Bad for recovery from congestion losses

Need a timeout mechanism that respondsappropriately for both types of losses

Open problem




92


Selective repeat protocols can deliver packets out of

order

Significantly out-of-order delivery can trigger TCP fastretransmit

Redundant retransmission from TCP sender Reduction in congestion window

Example: Receipt of packets

3,4,5 triggers dupacks

6 2 5 234 1

Lost packetRetransmitted packet




93

Link Level RetransmissionsIn-order delivery

To avoid unnecessary fast retransmit, link layer usingretransmission 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 ordereddelivery

audio

Need to be able to specify requirements on a per-packetbasis [Ludwig99]

Should the packet be retransmitted? How many times?Enforce in-order delivery?

Need a standard mechanism to specify the requirementsopen issue (IETF PILC working group)

Adaptive Link Layer Strategies



95

Adaptive Link Layer Strategies[Lettieri98,Eckhardt98,Zorzi97]

Adaptive protocols attempt to dynamically choose:

FEC code

retransmission limit

frame size

k [ d ]



96

Link Layer Retransmissions [Vaidya99]

0

400000

800000

1200000

16000002000000

1 6 3 8 4

3 2 7

6 8

6 5 5 3 6

1 E +

0 5


base TCP

Link layer retransmission

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

20 ms 1 ms

10 Mbps 2 Mbps

Link Layer Schemes: Summary



97

Link Layer Schemes: Summary

When is a reliable link layer beneficial to TCPperformance?

if it provides almost in-order delivery

and

TCP retransmission timeout large enough to tolerate

additional delays due to link level retransmits

Li k L S h Cl ifi i



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

V i S h



99

Various Schemes

Link level mechanismsSplit connection approachTCP-Aware link layer TCP-Unaware approximation of TCP-aware link layer Explicit notificationReceiver-based discriminationSender-based discrimination



100

Split Connection Approach



S lit C ti A h



102


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

FH-MH = FH-BS + BS-MH

FH MHBS

Base Station Mobile HostFixed Host

S lit C ti A h



103


Split connection results in independent flow controlfor the two parts

Flow/error control protocols, packet size, time-outs,may be different for each part

FH MHBS

Base Station Mobile HostFixed Host

S lit C ti A h



104


wireless

physical

link

network

transport

application

physical

link

network

transport

application

physical

link

network

transport

applicationrxmt

Per-TCP connection state

TCP connection TCP connection




105

p ppIndirect TCP [Bakre95,Bakre97]

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




106

p ppSelective Repeat Protocol (SRP) [Yavatkar94]

FH - BS connection : standard TCPBS - FH connection : selective repeat protocol on topof UDP

Performance better than Indirect-TCP (I-TCP),because wireless portion of the connection can betuned to wireless behavior

Split Connection Approach : Other Variations



107


Asymmetric transport protocol (Mobile-TCP)[Haas97icc]

Low overhead protocol at wireless hosts, and higher

overhead protocol at wired hostssmaller 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 tooNo congestion control over wireless hop




108


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 toMH

BS-MH link can use any arbitrary protocol optimizedfor wireless linkIdea similar to [Yavatkar94]

Split Connection Approach : Classification



109

Split Connection Approach : Classification

Hides transmission errors from sender Primary responsibility at base stationIf specialized transport protocol used on wireless,then wireless host also needs modification

Split Connection Approach : Advantages



110

BS-MH connection can be optimized independent of FH-BS connection

Different flow / error control on the two connections

Local recovery of errorsFaster recovery due to relatively shorter RTT on wireless link

Good performance achievable using appropriate BS-MHprotocol

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

Split Connection Approach : Disadvantages



111


End-to-end semantics violatedack may be delivered to sender, before data delivered to thereceiver May not be a problem for applications that do not rely onTCP for the end-to-end semantics

FH MHBS

40

39

3738

3640




112


BS retains hard stateBS failure can result in loss of data (unreliability)

If BS fails, packet 40 will be lostBecause it is ack’d to sender, the sender does not buffer 40

FH MHBS

40

39

3738

3640




113


BS retains hard stateHand-off latency increases due to state transfer

Data that has been ack’d to sender, must be moved to newbase station

FH MHBS

4039

3738

3640

MH

New base station

Hand-off

4039




114


Buffer space needed at BS for each TCP connectionBS buffers tend to get full, when wireless link slower (onewindow worth of data on wired connection could be stored atthe base station, for each split connection)

Window on BS-MH connection reduced in responseto errors

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




115


Extra copying of data at BScopying from FH-BS socket buffer to BS-MH socket buffer increases end-to-end latency

May not be useful if data and acks traverse differentpaths (both do not go through the base station)

Example: data on a satellite wireless hop, acks on a dial-upchannel

FH MH

data

ack

Various Schemes



116

Various Schemes

Link layer mechanismsSplit connection approachTCP-Aware link layer TCP-Unaware approximation of TCP-aware link layer

Explicit notificationReceiver-based discriminationSender-based discrimination



Snoop Protocol [Balakrishnan95acm]



118

Snoop Protocol [Balakrishnan95acm]

Retains local recovery of Split Connection approachand link level retransmission schemes

Improves on split connectionend-to-end semantics retainedsoft state at base station, instead of hard state

Snoop Protocol



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

Snoop Protocol



120

Snoop Protocol

Buffers data packets at the base station BSto allow link layer retransmission

When dupacks received by BS from MH, retransmiton wireless link, if packet present in buffer

Prevents fast retransmit at TCP sender FH bydropping the dupacks at BS

FH MHBS

Snoop : Example



121

FH MHBS40 39 3738

3634


3637

38

35 TCP statemaintained at

link layer

Snoop : Example



122

41 40 3839

3634

3637

38

35 39

Snoop : Example



123

p : p

42 41 3940

36


36

dupack

3738

39

40

Snoop : Example



124

p p

40

363636

Duplicate acks

4143 42

3738

39

4041

Snoop : Example



125

p p

FH MHBS41

3636

3744 43

36

3738

39

4041

42

Discarddupack

Dupack triggers retransmissionof packet 37 from base station

BS needs to be TCP-aware to

be able to interpret TCP headers

Snoop : Example



126

p p

37

36

36

4245 44

36

3738

39

4041

42

43

36

Snoop : Example



127

p p

42

36

36

4346 45

36

3738

39

4041

42

43

41

36

44

TCP sender does notfast retransmit

Snoop : Example



128

p p

43

3636

4447 46

36

3738

39

4041

42

43

41

36

44


45

Snoop : Example



129

p p

FH MHBS44

3636

4548 47

36

42

43

41

36

44

45

43

46

Snoop [Balakrishnan95acm]



130

p

0

400000

800000

1200000

16000002000000

1 6 K

3 2 K

6 4 K

1 2

8 K

2 5 6 K

n o er r or


b i t s / s e c

base TCPSnoop

2 Mbps Wireless link

Snoop ProtocolWhen Beneficial?



131

Snoop prevents fast retransmit from sender despitetransmission errors, and out-of-order delivery on thewireless link

OOO delivery causes fast retransmit only if it resultsin at least 3 dupacks

If wireless link level delay-bandwidth product is lessthan 4 packets, a simple (TCP-unaware) link levelretransmission scheme can suffice

Since delay-bandwidth product is small, the retransmissionscheme can deliver the lost packet without resulting in 3dupacks from the TCP receiver

Snoop Protocol : Classification



132

Hides wireless losses from the sender

Requires modification to only BS (network-centric

approach)



Snoop Protocol : Disadvantages



134

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 traversedifferent paths (both do not go through the basestation)

WTCP Protocol [Ratnam98]



135

Snoop hides wireless losses from the sender But sender’s RTT estimates may be larger inpresence of errorsLarger RTO results in slower response for congestion

losses

FH MHBS

WTCP Protocol



136

WTCP performs local recovery, similar to Snoop

In addition, WTCP uses the timestamp option toestimate RTT

The base station adds base station residence time tothe timestamp when processing an ack received fromthe wireless hostSender’s RTT estimate not affected by

retransmissions on wireless linkFH MHBS

WTCP Example



137

FH BS MH

3 3

34

Numbers in this figure are timestamps

Base station residence time is 1 unit

WTCP : Disadvantages



138

Requires use of the timestamp optionMay be useful only if retransmission times are large

link stays in bad state for a long timelink frequently enters a bad statelink delay large

WTCP does not account for congestion on wirelesshop

assumes that all delay at base station is due to queuing andretransmissionswill not work for shared wireless LAN, where delays alsoincurred due to contention with other transmitters

Various Schemes



139

Link layer mechanismsSplit connection approachTCP-Aware link layer TCP-Unaware approximation of TCP-aware link layer




140

TCP- Unaware Approximation of TCP-Aware Link Layer



Delayed Dupacks Protocol



142wireless

physical

link

network

transport

application

physical

link

network

transport

application

physical

link

network

transport

application

rxmt

TCP connection

Link layer state



144

TCP receiver delays dupacks (third and subsequent)for interval D, when out-of-order packets received

Dupack delay intended to give link level retransmittime to succeed

Benefit: Delayed dupacks can result in recovery froma transmission loss without triggering a response from

the TCP sender

Disadvantage: Recovery from congestion lossesdelayed




145

Delayed dupacks released after interval D, if missingpacket not received by then

Link layer maintains state to allow retransmissionLink layer state is not TCP-specific

Delayed Dupacks : Example

35



146

40 39 3738

3634


Link layer acks are not shown

3637

38

35Link layer state


36



147

BS41 40 3839

3634

36

3738

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

3738

39

40




149

40

363636

Duplicate acks

4143 42

3738

39

4041

Original ack




150

41

3636

3744 43

36

3739

40

41

42

Base station forwards dupacks

dupack dupacksDelayeddupack




151

37

3636

4245 44

36

3740

41

42

36dupacks

Delayed dupacks

43




152

424346 45

36

37

41

42

43

41


44

Delayed dupacks arediscarded if lostpacket received before

delay D expires

Delayed Dupacks [Vaidya99]



153

0

400000

800000

12000001600000

2000000

1 6 3 8 4

3 2 7

6 8

6 5 5 3 6

1 E +

0 5


base TCP

dupack delay80ms + LLRetransmitOnly LL

retransmit

2 Mbps wireless duplex link with 20 ms delayNo congestion losses

20 ms 20 ms

10 Mbps 2 Mbps

Delayed Dupacks [Vaidya99]



154

020000400006000080000

100000120000140000160000

1 6 3 8 4

3 2 7 6 8

6 5 5 3 6

1 E + 0 5


base TCP

dupack delay80ms + LLRetransmitOnly LLretransmit

5% packet loss due to congestion

20 ms 20 ms

10 Mbps 2 Mbps

Delayed Dupacks Scheme : Advantages



155

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

Delayed Dupacks Scheme : Disadvantages



156

Right value of dupack delay D dependent on thewireless link properties

Mechanisms to automatically choose D needed

Delays dupacks for congestion losses too, delayingcongestion loss recovery

Various Schemes



157

Link-layer retransmissionsSplit connection approachTCP-Aware link layer TCP-Unaware approximation of TCP-aware link layer




158

Explicit Notification

Explicit Notification SchemesGeneral Philosophy



159

Approximate Ideal TCP behavior : Ideally, the TCP sender should simply retransmit a packet lost due to transmissionerrors, without taking any congestion control actions

A wireless node somehow determines that packets arelost due to errors and informs the sender using an explicitnotification

Sender, on receiving the notification, does not reducecongestion window , but retransmits lost packet

Explicit Notification Schemes



160

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 notificationwhat the sender does on receiving the notification

Explicit NotificationSpace Communication Protocol Standards-

Transport Protocol (SCPS-TP)



161

Transport Protocol (SCPS-TP)

Satellite

Ground station

wireless

TCP destinations

Space Communication Protocol Standards-Transport Protocol (SCPS-TP)



162

The receiving ground station keeps track of how manypackets with errors are received (their checksums failed)When the error rate exceeds a threshold, the ground stationsends corruption experienced messages to destinations of recent error-free TCP packets

destinations are cachedThe TCP destinations tag acks with corruption-experiencedbitTCP sender, after receiving an ack with corruption-experienced bit, does not back off until it receives an ackwithout that bit (even if timeout or fast retransmit occurs)

Explicit Loss Notification [Balakrishnan98]when MH is the TCP sender



163

Wireless link first on the path from sender to receiver The base station keeps track of holes in the packetsequence received from the sender When a dupack is received from the receiver, the

base station compares the dupack sequence number with the recorded holesif there is a match, an ELN bit is set in the dupack

When sender receives dupack with ELN set, itretransmits packet, but does not reduce congestionwindow

MH FHBS4 3 2 1 134

wireless

Recordhole at 2

111 1

Dupack with ELN set

Explicit Bad State Notification [Bakshi97]when MH is TCP receiver



164

Base station attempts to deliver packets to the MHusing a link layer retransmission scheme

If packet cannot be delivered using a small number of retransmissions, BS sends a Explicit Bad StateNotification (EBSN) message to TCP sender

When TCP sender receives EBSN, it resets its timer timeout delayed, when wireless channel in bad state

Partial Ack Protocols [Cobb95][Biaz97]



165

Send two types of acknowledgementsA partial acknowledgement informs the sender that apacket was received by an intermediate host(typically, base station)

Normal TCP cumulative ack needed by the sender for reliability purposes

Partial Ack Protocols



166

When a packet for which a partial ack is received isdetected to be lost, the sender does not reduce itscongestion window

loss assumed to be due to wireless errors

37

36

Partial ack

37

Cumulative ack

Variations



167

Base station may or may not locally buffer andretransmit lost packetsPartial ack for all packets or a subset ?

37

36

Partial ack

37

Cumulative ack

Explicit Loss Notification [Biaz99thesis]when MH is TCP receiver



168

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 beingforwarded to sender if sequence number for the lost

packet is cached at the base station

Sender takes appropriate action on receiving ELN

Explicit Loss Notification [Biaz99thesis]when MH is TCP receiver



169

37

36

37

3839

39

38

Sequence numberscached at base station

37 37

Dupack with ELN

Various Schemes



170





171

Receiver-Based Discrimination Scheme



Receiver-Based Scheme



173

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 betweenconsecutively 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

Receiver-Based SchemeDiagnostic Accuracy [Biaz99Asset]



176

Congestion losses Error losses

Receiver-Based Scheme : Disadvantages



177

Limited applicability

The slowest link on the path must be the last wirelesshop

to ensure some queuing will occur at the base station

The queueing delays for all packets (at the basestation) should be somewhat uniform

multiple connections on the link will make inter-packetdelays variable



Various Schemes



179





Sender-Based Discrimination Scheme[Biaz98ic3n,Biaz99techrep]



181

Sender can attempt to determine cause of a packet loss

If packet loss determined to be due to errors, do notreduce 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)

Heuristics for Congestion Avoidance



182

loadload

RTT

throughput

knee

cliff

Heuristics for Congestion Avoidance



183

Define condition C as a function of congestion windowsize and observed RTTs

Condition C evaluated when a new RTT is calculatedcondition C typically evaluates to 2 or 3 possible valuesfor now assume 2 values: TRUE or FALSE

If (C == True) reduce congestion window

Several proposals for condition C

Heuristics for Congestion AvoidanceSome proposals



184

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 GradientNTG = 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)

Sender-Based Heuristics



187

Record latest value evaluated for condition C

When a packet loss is detected

if last evaluation of C is TRUE, assume packet loss is dueto congestionelse assume that packet loss is due to transmission errors

If packet loss determined to be due to errors, do notreduce congestion window



Sender-Based SchemesDiagnostic Accuracy [Biaz99ic3n]



189



Sender-Based Heuristics : Advantages



191

Only sender needs to be modified

Needs further investigation to develop better heuristicsinvestigate longer-term heuristics

Why do Statistical Technique Perform Poorly?

The techniques we evaluated use simple statistics on



192

q p

RTT and window size W to draw conclusions aboutstate of the networkUnfortunately, correlation between RTT and W isoften weak

FractionofTCP

connections

Coefficient of correlation (RTT,W)

Statistical TechniquesFuture Work



193

Other statistical measures ?

Mechanisms that achieve good TCP throughput

despite not-too-good diagnostic accuracy

TCP in Presence of Transmission ErrorsSummary



194

Many techniques have been proposed, and severalapproaches perform well in many environments

Recommendation: Prefer end-to-end techniquesEnd-to-end techniques are those which

do not require TCP-Specific help from lower layersLower layers may help improve TCP performance without taking

TCP-specific actions. Examples:• Semi-reliable link level retransmission schemes

• Explicit notification

Tutorial Outline



195

Schemes to improves TCP performance in presenceof transmission errorsTCP over SatelliteImpact of mobility on TCP performance

Approaches to improve TCP performance inpresence of mobilityIssues in multi-hop wireless networksIssues needing further work

References



196

TCP Over Satellite

TCP over Satellite



197

Geostationary Earth Orbit (GEO) Satellitelong latencytransmission errors or channel unavailability

Low Earth Orbit (LEO) Satelliterelatively smaller delaysdelays more variable

Problems Addressed by Various Schemes

d l



198

Long delayLarge delay-bandwidth productsTransmission errors

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



199

Larger congestion window (window scale option)maximum window size up to 2^30

Acknowledge every packet (do not delay acks)

Selective acksfast recovery can only recover one packet loss per RTTSACKS allow multiple packet recovery per RTT

Larger Initial Window[Allman98september] [Allman98august]

All i i i l i d i f d b



200

Allows initial window size of cwnd to be up to

approximately 4 Kbyte

Larger initial window results in faster window growthduring slow startavoids wait for delayed ack timers (which will occur withcwnd = 1 MSS)larger initial window requires fewer RTTs to reach ssthresh

Byte Counting [Allman98august]



201

Increase window by number of new bytes ack’d in anacknowledgement, instead of 1 MSS per ackSpeeds up window growth despite delayed or lost acksNeed to reduce bursts from sender

limiting size of window growth per ackrate control

Space Communications Protocol Standard-Transport Protocol (SCPS-TP) [Durst96]

S d k d f l i b f



202

Sender makes default assumption about source of packet loss

default assumption can be set by network manager on aper-route basisdefault assumption can be changed due to explicit feedback

from the networkCongestion control algorithm derived from TCP-Vegas, to bound window growth, to reducecongestion-induced losses

Space Communications Protocol Standard-Transport Protocol (SCPS-TP)

D i li k t TCP d f it lf d



203

During link outage, TCP sender freezes itself, andresumes when link is restored

outage assumed to occur in both directions simultaneouslyground station can detect outage of incoming link (for instance, by low signal levels), and infers outage of outgoing

linkground stations provide link outage information to anysender that attempts to send packets on the outgoing linksender does not unnecessarily timeout or retransmit until itis informed that link has recovered

Selective acknowledgement protocol to recover losses quickly

Satellite Transport Protocol (STP)[Henderson98]

U lit ti h



204

Uses split connection approachProtocol on satellite channel different from TCP

selective negative acks when receiver detects lossesno retransmission timer transmitter periodically requests receiver to ack receiveddatareduces reverse channel bandwidth usage when losses arerare



Tutorial Outline

TCP over Satellite



206

TCP over SatelliteImpact of mobility on TCP performanceApproaches to improve TCP performance inpresence of mobility

Issues in multi-hop wireless networksIssues needing further workReferences



207

Impact of Mobility on TCP Performance



Impact of Mobility

If link layer performs hand offs and guarantees



209

If link layer performs hand-offs and guaranteesreliability despite handoff, then TCP will not be awareof the handoff

except for potential delays during handoff

Impact of Mobility

If hand off visible to IP



210

If hand-off visible to IPNeed Mobile IP [Johnson96]packets may be lost while a new route is being establishedreliability despite handoff

We consider this case

Mobile IP [Johnson96]



211

Router 1

Router 3

Router 2

S MH

Homeagent

Mobile IP [Johnson96]



212

Router 1

Router 3

Router 2

S MH

Home agent

Foreign agent

move

Packets are tunneledusing IP in IP

Example Hand-Off Procedure

1 Each base station periodically transmits beacon



213

1. Each base station periodically transmits beacon2. Mobile host, on hearing stronger beacon from a new

BS, sends it a greetingchanges routing tables to make new BS its default gatewaysends new BS identity of the old BS

OldBS

NewBS

MH

2

1

3

4

5,6

7

Hand-Off Procedure

3. New BS acknowledges the greeting, and begins toroute the MH’s packets



214

p4. New BS informs old BS5. Old BS changes routing table, to forward any

packets for the MH to the new BS6. Old BS sends an ack to new BS7. New BS sends handoff-completion message to MH

OldBS

NewBS

MH

2

1

3

4

5,6

7

Mobile IP

Mobile IP would need to modify the previous hand-off



215

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 delayRoute directly to foreign agent, instead of via home agent

Hand-off



216

Hand-offs may result in temporary loss of route to MHwith non-overlapping cells, it may be a while before themobile 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 eachother, resulting in loss of packets

Impact of Handoffs on Schemes to ImprovesPerformance in Presence of Errors

Split connection approach



217

Split connection approachhard state at base station must be moved to new base station

Snoop protocolsoft state need not be movedwhile the new base station builds new state, packet losses may notbe recovered locally

Frequent handoffs a problem for schemes that rely onsignificant amount of hard/soft state at base stations

hard state should not be lost

soft state needs to be recreated to benefit performance



Classification



219

Hide mobility from the TCP sender

Make TCP adaptive to mobility

Using Fast Retransmits to Recover fromTimeouts during Handoff [Caceres95]



220

During the long delay for a handoff to complete, awhole window worth of data may be lostAfter handoff is complete, acks are not received bythe TCP sender Sender eventually times out, and retransmitsIf handoff still not complete, another timeout willoccur Performance penalty

Time wasted until timeout occursWindow shrunk after timeout

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

Cell crossing Retransmission



221

Last

timedtransmit

Cell crossing+ beaconarrives

Handoff completeRoutes updatedRetransmissiontimeout

0 0.15 0.8 sec

1.0

Packet loss Idle sender

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

Cell crossing Beacon arrives



222

Last

timedtransmit

0 0.8

2.0

Timeout 1

Cell crossing

Packet loss

Retransmissiontimeout 2Handoff complete

1.0

1.0 1.15

Idle sender

2.8 sec

Performance [Caceres95]

Four environments



223

1. No moves2. Moves (once per 8 sec) between overlapping cells3. Moves between non-overlapping cells, 0 sec delay

4. Moves between non-overlapping cells, 1 sec delay

Experiments using 2 Mbps WaveLan

TCP Performance



224

1600 1510 14001100

0200400600800

10001200140016001800

N o m o v

e s

o v e r l a p

p i n g c

e l l s

n o n - o

v e r l a p

/ 0 d e

l a y

n o n - o

v e r l a p

/ 1 s e c .

Kbit/sec

TCP Performance

Degradation in case 2 (overlapping cells) is due to



225

g ( pp g )encapsulation and forwarding delay during handoff

Additional degradation in cases 3 and 4 due to packetloss and idle time at sender

Mitigation Using Fast Retransmit



226

When MH is the TCP receiver: after handoff iscomplete, 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 retransmitafter completion of handoff

0-second Rendezvous DelayImprovement using Fast Retransmit

Cell crossing Retransmission



227

Last

timedtransmit

g+ beaconarrives

Handoff completeRoutes updatedRetransmissiontimeoutdoes not occur

0 0.15 0.8

1.0

Packet loss

Fast retransmit

Idle sender

TCP Performance Improvement



228

16001510 1490

13801400

1100

0200400600800

10001200140016001800

1 2 3 4

Kbit/secWith fast rxmit

TCP Performance Improvement



229

No change in cases 1 and 2, as expected

Improvement for non-overlapping cells

Some degradation remains in case 3 and 4fast retransmit reduces congestion window

Improving Performance by Smooth Handoffs[Caceres95]



230

Provide sufficient overlap between cells to avoid packetloss

or

Buffer packets at BSDiscard the packets after a short intervalIf handoff occurs before the interval expires, forward the packetsto the new base stationPrevents packet loss on handoff

M-TCP [Brown97]

In the fast retransmit scheme [Caceres95]



231

sender starts transmitting soon after handoff BUT congestion window shrinks

M-TCP attempts to avoid shrinkage in thecongestion window

M-TCP UsesTCP Persist Mode

When a new ack is received with receiver’s advertised



232

window = 0, the sender enters persist mode

Sender does not send any data in persist modeexcept 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 asbefore the persist mode

M-TCP

Similar to the split connection approach, M-TCP splits



233

one TCP connection into two logical partsthe two parts have independent flow control as in I-TCP

The BS does not send an ack to MH, unless BS hasreceived an ack from MH

maintains end-to-end semanticsBS withholds ack for the last byte ack’d by MH

FH MHBS

Ack 1000Ack 999

M-TCP



234

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 startssending packets using same cwnd as before handoff

FH MHBS

M-TCP

The last ack is not withheld, if BS does not expect



235

any other ack from the MHthis happens when the BS has no other unack’d databuffered locallythis is required to prevent a sender timeout at the end of atransfer (or end of a burst of data)

M-TCP

Avoids reduction of congestion window due to handoff,



236

unlike the fast retransmit schemesimulation-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 bemore congested than before.

It is not obvious that starting full speed after handoff isright.



FreezeTCP [Goff99]

TCP receiver determines if a handoff is about to



238

happendetermination may be based on signal strength

Ideally, receiver should attempt to send ZWA1 RTT before handoff Receiver sends 3 dupacks when route isreestablishedNo help needed from the base station

an end-to-end enhancement

FH MHBS

MobileTCP receiver

Using Multicast to Improve Handoffs[Ghai94,Seshan96]

Define a group of base stations including



239

current cell of a mobile hostcells that the mobile host is likely to visit next

Address packets destined to the mobile host to thegroup

Only one base station transmits the packets to themobile host

if rest of them buffer the packets, then packet lossminimized on handoff

Using Multicast to Improve Handoffs



240

Static group definition [Ghai94]groups can be defined taking physical topology into accountstatic definition may not take individual user mobility patterninto account

Dynamic group definition [Seshan96]implemented using IP multicast groupseach user’s group can be different

overhead of updating the multicast groups is a concern witha large scale deployment

Using Multicast to Improve Handoffs

Buffering at multiple base stations incurs memory



241

overhead

Trade-off between buffering overhead and packetloss

Buffer requirement can be reduced by startingbuffering only when a mobile host is likely to leavecurrent cell soon

Tutorial Outline

TCP over Satellite



242

Impact of mobility on TCP performanceApproaches to improve TCP performance inpresence of mobilityIssues in multi-hop wireless networksIssues needing further workReferences



243

TCP in Mobile Ad Hoc Networks

Mobile Ad Hoc Networks (MANET)

May need to traverse multiple links to reach a



244

destination

Mobile Ad Hoc Networks[IETF-MANET]

Mobility causes route changes



245

TCP in Mobile Ad Hoc NetworksIssues

Route changes due to mobility



246

Wireless transmission errorsproblem compounded with multiple hops

Out-of-order packet deliveryfrequent route changes may cause out-of-order deliveryTCP does not perform well if packets are significantly OOO

Multiple access protocolchoice of MAC protocol can impact TCP performancesignificantly

Half-duplex radios

cannot send and receive packets simultaneouslychanging mode (send or receive) incurs overhead

Throughput over Multi-Hop Wireless Paths [Gerla99]



247

When contention-based MAC protocol is used,connections over multiple hops are at a disadvantage compared to shorter connections, because theyhave to contend for wireless access at each hop

extent of packet delay or drop increases with number of hops

Impact of Multi-Hop Wireless Paths [Holland99]

1200

14001600



248

0200400600800

10001200

1 2 3 4 5 6 7 8 9 10

Number of hops

TCPThroughtput(Kbps)

TCP Throughput using 2 Mbps 802.11 MAC

Ideal Throughput

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



249

between sender and destination is I

T(i) = Throughput when path length is I From previous figure

Ideal throughput = Σ f(i) * T(i)



Impact of Mobility



251

Ideal throughput

A c t u a l

t h r o u g

h p u

t20 m/s 30 m/s

Throughput generally degrades with increasingspeed …



252Speed (m/s)

Average

ThroughputOver 50 runs

Ideal

Actual

But not always …



253Mobility pattern #

Actualthroughput

20 m/s

30 m/s

mobility causeslink breakage,

Why Does Throughput Degrade?

TCP d ti tR t i



254

resulting in routefailure

TCP data and acksen route discarded

TCP sender times out.Starts sending packets again

Route isrepaired

Nothroughput

No throughputdespite route repair

mobility causeslink breakage,

Why Does Throughput Degrade?

TCP sender R t i

TCP sender times out.

R



255

resulting in routefailure

TCP data and acksen route discarded

times out.Backs off timer.

Route isrepaired

Resumessending

Larger route repair delaysespecially harmful

No throughput

No throughput

despite route repair

Why Does Throughput Improve?Low Speed Scenario

D D D



256

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.

Why Does Throughput Improve?Higher (double) Speed Scenario

D D D



257

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.

Why Does Throughput Improve?General Principle

TCP timeout interval somewhat (not entirely)

i d d t f d



258

independent of speedNetwork state at higher speed, when timeout occurs,may be more favorable than at lower speedNetwork state

Link/route statusRoute cachesCongestion



Performance Improvement

Without network With feedback



260

Without network feedback

Ideal throughput2 m/s speed

With feedback

Actualthroughput

Performance Improvement

With t t k With f db k



261

Without network feedback

With feedback

Ideal throughput30 m/s speed

Actualthroughput

Performance with Explicit Notification[Holland99]

0 8

1

c t i o n

o f



262

0

0.2

0.4

0.6

0.8

2 10 20 30

mean speed (m/s)

t h r o

u g

h p u

t a s a

f r a

i d e a

lBase TCP

With explicitnotification

IssuesNetwork Feedback

Network knows best (why packets are lost)



263

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 betweenlayers

Impact of Caching

Route caching has been suggested as a mechanism



264

Route caching has been suggested as a mechanismto reduce route discovery overhead [Broch98]

Each node may cache one or more routes to a givendestination

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

To Cache or Not to Cache



265Average speed (m/s)

Why Performance Degrades With Caching

When a route is broken, route discovery returns acached route from local cache or from a nearby node



266

After a time-out, TCP sender transmits a packet onthe new route.However, the cached route has also broken after it

was cached

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

timeout dueto route failure

timeout, cachedroute is broken

timeout, second cachedroute also broken

IssuesTo Cache or Not to Cache

Caching can result in faster route “repair”



267

Faster does not necessarily mean correct

If incorrect repairs occur often enough, cachingperforms poorly

Need mechanisms for determining when cached

routes are stale

Caching and TCP performance

Caching can reduce overhead of route discovery

even if cache accuracy is not very high



268

even if cache accuracy is not very high

But if cache accuracy is not high enough, gains inrouting overhead may be offset by loss of TCP

performance due to multiple time-outs

IssuesWindow Size After Route Repair

Same as before route break: may be too optimistic



269

Same as before route break: may be too optimistic

Same as startup: may be too conservative

Better be conservative than overly optimisticReset window to small value after route repair Impact low on paths with small delay-bw product

IssuesRTO After Route Repair

Same as before route breakIf t l g thi RTO b t ll l di g t ti t



270

Same as before route breakIf 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 largeWill result in slow response to future losses

Proposal : new RTO = function of old RTO, old route length, andnew route length

Example: new RTO = old RTO * new route length / old route lengthNot evaluated yet

Impact of MAC - Delay Variability

As wireless medium is shared between multiple

sources the round-trip delay is variable



271

sources, the round-trip delay is variableAlso, 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 TCPthroughput

Impact of MAC - Delay Variability [Balakrishnan97]

Several techniques may be used to mitigate problem,

based on minimizing ack transmissions



272

based on minimizing ack transmissionsto reduce frequency of send-receive turnaround andcontention between acks and data

Piggybacking link layer acks with dataSending fewer TCP acks - ack every d-th packet ( d may be chosen dynamically)

• but need to use rate control at sender to reduceburstiness (for large d)

Ack filtering - Gateway may drop an older ack in the

queue, if a new ack arrivesreduces number of acks that need to be delivered to thesender

Out-of-Order Packet Delivery

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

delivery



273

delivery

Significantly OOO delivery confuses TCP, triggeringfast retransmit

Potential solutions:Avoid OOO delivery by ordering packets before delivering to IPlayer

•can result in variable delay

turn off fast retransmit

• can result in poor performance in presence of congestion



274

Other Topics

Header Compression for Wireless Networks[Degermark96]

In TCP packet stream, most header bits are identicalVan Jacobson’s scheme exploits this observation to compressheaders, by only sending the “ delta ” between the previous and



275

, y y g pcurrent header Packet losses result in inefficiency, as headers cannot bereconstructed due to lost informationPacket losses likely on wireless links[Degermark96] proposes a technique that works well despitesingle packet loss

“twice” algorithmif current packet fails TCP checksum, assume that a single packet is lostapply delta for the previous packet twice to the current header, and testchecksum again

Twice Algorithm : Example



276

delta 2 delta

Channel State Dependent Packet Scheduling[Bhagwat96]

Head-of-the Line blocking can occur with FIFO (first-

in-first-out) scheduling, if sender attempts to



277

in first out) scheduling, if sender attempts toretransmit packets on a channel in a bad state

M1 M2 M3M2 M1Wireless

card

M1

M2

M3

Channel State Dependent Packet Scheduling

Separate queue for each destination

Channel state monitor somehow determines if a



278

Channel state monitor somehow determines if achannel is in burst error state

M1

M2

M3

M2

M1 Wirelesscard

M1

M2

M3

scheduler

Channel statusmonitor

Per destinationqueues


Packets transmitted on bad channels, only if packets

for no other channels present in queues



279

for no other channels present in queues

M1

M2

M3

M2

M1 Wirelesscard

M1

M2

M3

scheduler




Needs a reasonably good Channel State Monitor



280

M1

M2

M3

M2

M1Wireless

card

M1

M2

M3

scheduler



Automatic TCP Buffer Tuning [Semke98]

Using too small buffers can yield poor performance



281

g y p p

Using too large buffers can limit number of openconnections

Automatic mechanisms to choose buffer sizedynamically would be useful

Tutorial Outline

TCP over Satellite

Impact of mobility on TCP performance



282

p y pApproaches to improve TCP performance inpresence of mobilityIssues in multi-hop wireless networksIssues needing further workReferences



283

Issues for Further Investigation

Link Layer Protocols

“Pure” link layer designs that support higher transport

performance



284

psome recent work in this area as noted earlier

Identifying scenarios where link layer solutions are

inadequate

If TCP-awareness is absolutely needed, provide aninterface that can be used by other transport

protocols too

End-to-End Techniques

Existing techniques typically require cooperation from

intermediate nodes.



285

Such techniques often not applicableencrypted TCP headersTCP data and acks do not go through same base station

End-to-end techniques would rely on informationavailable only at end nodes

Harder to design due to lack of complete information abouterrorsExplicit Notifications may make that easier

Impact of Congestion Losses

Past work typically evaluates performance in absence



286

yp y pof congestion

Relative performance improvement may changesubstantially when congestion occurs

performance improvement may reduce if congestion isdominant, or if RTO becomes larger due to wireless errors

Multiple TCP Transfers

Past work typically measures a single TCP connection

over wirelessTCP th h t i th t i f h i



287

TCP throughput is the metric of choice

When multiple connections share a wireless link, other performance metrics may make sense

fairnessaggregate throughput

Relative performance improvements of variousschemes may change when multiple connections areconsidered

TCP Window & RTO Settings After a Move

Congestion window & RTO size at connection openare chosen to be conservative



288

g pare chosen to be conservativeWhen a route change occurs due to mobility, whichvalues to use?

Same as before route change ---- may be too aggressiveSame as at connection open ---- may be too conservative

Answer unclear some proposals attempt to use same values as before routechange, but not clear if that is the best alternative

TCP for Mobile Ad Hoc Networks

Much work on routing in ad hoc networks

Some recent work on TCP for ad hoc networks



289

Need to investigate many issuesMAC-TCP interactionrouting-TCP interaction

impact of route changes on window size, RTO choice after move

References



290

Please see attached listing for the references cited inthe tutorial

Thank you !!



y

For more information, send e-mail toNitin Vaidya at

tcp wireless tutorial

Documents