08-tcp5

8/13/2019 08-tcp5

1/50

TCP over Wireless Links

Wireless connectivity characteristics Transmission errors

Low bandwidth

Long or variable latency

Asymmetry in bandwidth Impact of transmission errors on TCP performance

Impact of handoffs on TCP performance

Approaches to improve TCP performance

I-TCP Snoop

Link layer retransmissions

M-TCP

8/13/2019 08-tcp5

2/50

Transmission Control Protocol (TCP)

Window based protocol Size of window determines sending rate (data sent per RTT)

Window size based on network state and receive buffer size

Implements congestion avoidance and control

packet loss assumed to be indication of congestion

sending rate reduced drastically on detecting a packet loss

Reliable ordered delivery: reliability by retransmissions

packet loss detected by timeoutsand duplicate acks

End-to-end semantics

Acks confirm delivery of data received by TCP receiver

Ack for data sent only afterdata has reached receiver

8/13/2019 08-tcp5

3/50

Duplicate Acknowledgements

Duplicate ack is generated when a received packet has a

larger-than-expected sequence number Duplicate acks may be generated when

a packet is lost, or

a packet is delivered out-of-order (OOO)

40 39 3837

3634

41 40 3739

34 36

40 39 3738

3634

out-of-order delivery

38 lost due to congestion

38 lost due to errors

8/13/2019 08-tcp5

4/50

Fast Retransmit Mechanism

TCP sender assumes that a packet loss has occurred if itreceives 3 dupacksconsecutively

3 dupacks will be generated if 3 packets are delivered

subsequent to a lost packet

3 dupacks are also generated if a packet is delivered at

least 3 places beyond its in-sequence location

12 8 791011

Fast retransmit useful only if lower layers deliver packets

almost ordered---- otherwise,unnecessaryfast retransmit

12 11 78910

8/13/2019 08-tcp5

5/50

Fast retransmit is followed by fast recovery.

After fast recovery, window size is reduced in half.

0

2

4

6

8

10

0 2 4 6 8 10 12 14

Time (round trips)

Windowsize(segm

ents)

Receivers advertized window

After fast recovery

8/13/2019 08-tcp5

6/50

Window based Flow Control

Congestion window size bounds the amount of data that can be sentper round-trip time (RTT)

Throughput delay*bw ?

Queuing at intermediate routers

increased RTT due to queuing delays

Potentially, packet loss

8/13/2019 08-tcp5

7/50

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

8/13/2019 08-tcp5

8/50

Random Errors May Cause Fast Retransmit

40 39 3738

3634

Example assumes delayed ack - every other packet ackd

8/13/2019 08-tcp5

9/50


41 40 3839

3634


8/13/2019 08-tcp5

10/50


42 41 3940

36

Duplicate acks are not delayed

36

dupack

8/13/2019 08-tcp5

11/50


40

363636

Duplicate acks

4143 42

8/13/2019 08-tcp5

12/50


41

3636

3 duplicate acks trigger

fast retransmit at sender

4244 43

36

8/13/2019 08-tcp5

13/50


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

8/13/2019 08-tcp5

14/50

Impact of Transmission Errors

Packet loss due to errors can trigger fast retransmit and fast recovery,

resulting in retransmission of lost packet

reduction in congestion window

Reducing congestion window in response to errors is unnecessary

unless errors are caused by congestion

Reduction in congestion window in response to errors can

significantly reduce the throughput

TCP cannot distinguish between packet losses due to congestionand

those due to transmission errors.

8/13/2019 08-tcp5

15/50

Impact of Errors

0

400000

800000

1200000

1600000

16384 32768 65536 131072

1/error rate (in bytes)

bits/sec

Exponential error model

2 Mbps wireless full duplex link

No congestion losses

8/13/2019 08-tcp5

16/50

Techniques to Improve TCP Performance

in Presence of Errors

Classification 1

Classification based on nature of actions taken to

improve performance

Hide error losses from the sender

if sender is unaware of the packet losses due to errors, it will not

reduce congestion window

Let sender know, or determine, cause of packet loss

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

congestion window

8/13/2019 08-tcp5

17/50

Techniques to Improve TCP Performance

in Presence of Errors

Classification 2

Classification based on where modifications are needed

At the sender node only

At the receiver node only

At intermediate node(s) only

Combinations of the above

8/13/2019 08-tcp5

18/50

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 TCP

Ideal TCP typically notrealizable

Ideal network behavior: Transmission errors should behidden from the sender -- the errors should be recoveredtransparentlyand efficiently

Proposed schemes attempt to approximate one of the abovetwo ideals

8/13/2019 08-tcp5

19/50

Proposals to Improve Performance of

TCP over Wireless

Split connection approach

Link level mechanisms

TCP-Aware link layer

Explicit notification

TCP-Unaware approximation of TCP-aware link layer

Receiver-based discrimination

Sender-based discrimination

For an overview, see IETF PILC working group documents

8/13/2019 08-tcp5

20/50

Split Connection Approach (I-TCP)

End-to-end TCP connection is broken into

one connection on the wired part of route, and

one over wireless part of the route

Split connection results in independent flow control for the

two parts

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

FH MHBS

Base Station Mobile HostFixed Host

8/13/2019 08-tcp5

21/50

Split Connection Approach

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

8/13/2019 08-tcp5

22/50

Split Connection Approach : Advantages

BS-MH connection can beoptimizedindependent of FH-

BS connection Different flow / error control on the two connections

Local recovery of errors

Fasterrecovery due to relatively shorter RTT on wireless link

Good performanceachievable using appropriateBS-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

8/13/2019 08-tcp5

23/50

Split Connection Approach : Disadvantages

End-to-end semanticsviolated 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

8/13/2019 08-tcp5

24/50


BS retains hard state

BS failure can result in loss of data (unreliability)

If BS fails, packet 40 will be lost

Because it is ackd to sender, the sender does not buffer 40

FH MHBS

40

39

3738

3640

8/13/2019 08-tcp5

25/50


BS retains hard state

Hand-off latency increases due to state transfer

Data that has been ackd to sender, must be moved to new base

station

FH MHBS

40

39

3738

3640

MH

New base station

Hand-off

40

39

8/13/2019 08-tcp5

26/50


Bufferspaceneeded 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

8/13/2019 08-tcp5

27/50


Extra copying of dataat BS

copying from FH-BS socket buffer to BS-MH socket buffer

increases end-to-endlatency

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

8/13/2019 08-tcp5

28/50

Snoop Protocol

Retains local recovery of Split Connection approach and

link level retransmission schemes

Improves on split connection

end-to-end semantics retained

soft state at base station, instead of hard state

8/13/2019 08-tcp5

29/50

Snoop Protocol

Buffers datapackets at the base station BS to allow link layer retransmission

When dupacks received by BS from MH, retransmiton

wireless link, if packet present in buffer

Prevents fast retransmitat TCP sender FH by dropping thedupacks at BS

FH MHBS

8/13/2019 08-tcp5

30/50

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

8/13/2019 08-tcp5

31/50

Snoop : Example

FH MHBS

40 39 3738

3634


36

37

38

35 TCP state

maintained atlink layer

8/13/2019 08-tcp5

32/50

Snoop : Example

41 40 3839

3634

36

37

38

35 39

8/13/2019 08-tcp5

33/50

Snoop : Example

42 41 3940

36

Duplicate acks are not delayed

36

dupack

37

38

39

40

8/13/2019 08-tcp5

34/50

Snoop : Example

40

363636

Duplicate acks

4143 42

37

38

39

40

41

8/13/2019 08-tcp5

35/50

Snoop : Example

FH MHBS

41

3636

3744 43

36

37

38

39

40

41

42

Discard

dupack

Dupack triggers retransmission

of packet 37 from base station

BS needs to be TCP-aware to

be able to interpret TCP headers

8/13/2019 08-tcp5

36/50

Snoop : Example

37

36

36

4245 44

36

37

38

39

40

41

42

43

36

8/13/2019 08-tcp5

37/50

Snoop : Example

42

36

36

4346 45

36

37

38

39

40

41

42

43

41

36

44

TCP sender does not

fast retransmit

8/13/2019 08-tcp5

38/50

Snoop : Example

43

3636

4447 46

36

37

38

39

40

41

42

43

41

36

44

TCP sender does not

fast retransmit

45

8/13/2019 08-tcp5

39/50

Snoop : Example

FH MHBS

44

3636

4548 47

36

42

43

41

36

44

45

43

46

8/13/2019 08-tcp5

40/50

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 layerdelivery

End-to-end semantics retained

Soft state at base station

loss of the soft state affects performance, but not correctness

8/13/2019 08-tcp5

41/50

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)

8/13/2019 08-tcp5

42/50

Link Layer Mechanisms

Forward error correction (FEC)

quick recovery

Link level retransmission: Retransmit a packet at the linklayer, if errors are detected

Retransmission overhead incurred only if errors occur

8/13/2019 08-tcp5

43/50

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

8/13/2019 08-tcp5

44/50

Link Level Retransmissions

Issues

How many times to retransmit at the link level beforegiving up?

Fully reliable or not

What triggers link level retransmissions? Timeout, link layer Nack, TCP dupack (as in Snoop), ...

How much time is required for a link layer retransmission?

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

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

8/13/2019 08-tcp5

45/50

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

8/13/2019 08-tcp5

46/50

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

8/13/2019 08-tcp5

47/50

M-TCP

In the fast retransmit scheme sender starts transmitting soon after handoff

BUT congestion window shrinks

M-TCP attempts to avoid shrinkage in the congestion window

M-TCP Uses TCP Persist Mode

When a newack is received with receivers advertised window = 0, the

sender enters persist mode

Sender does not send any data in persist mode

except when persist timer goes off

When a positive window advertisement is received, sender exits persistmode

On exiting persist mode, RTOand cwndare same as before the persist

mode

8/13/2019 08-tcp5

48/50

M-TCP

Similar to the split connection approach, M-TCP splits oneTCP 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 ackfor the last byteackd by MH

FH MHBS

Ack 1000Ack 999

8/13/2019 08-tcp5

49/50

8/13/2019 08-tcp5

50/50

08-tcp5

Documents

Transcript of 08-tcp5