1

TCP over Wireless (I) some slides adapted, notably from tutorial by Nitin Vaidya

2

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)

3

TCP/IP over Wireless

De facto standard for internetworking

Allows wireless devices to connect seamlessly to the Internet

TCP over wireless introduces some problems not faced in wired networks (transmission errors, mobility …) We will overview these issues as well as existing solutions

What type of wireless network (cellular, last hop, ad hoc, satellite …)?

4

Quick review ofTransmission Control Protocol / Internet Protocol

TCP/IP

5

Internet Protocol (IP)

Packets may be delivered out-of-order

Packets may be lost

Packets may be duplicated

6

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

7

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

8

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

9

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

10

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

11

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

12

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

13

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

14

Window Based Flow Control

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

15

Ack Clock

TCP window flow control is “self-clocking”

New data sent when old data is ack’d

Helps maintain “equilibrium”

16

Window Based Flow Control

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

Throughput <= W / RTT

17

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

18

How does TCP detect a packet loss?

Retransmission timeout (RTO)

Duplicate acknowledgements

19

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

20

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

21

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

22

Exponential Backoff

Double RTO on each timeout

Packettransmitted

Time-out occursbefore ack received,packet retransmitted

Timeout interval doubled

T1 T2 = 2 * T1

23

Fast Retransmission

Timeouts can take too long how to initiate retransmission sooner?

Fast retransmit

24

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

25

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

26

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

27

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

28

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

29

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

30

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

31

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

32

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

33

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

34

TCP Reno

Slow-start Congestion avoidance Fast retransmit Fast recovery

35

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

36

Does IEEE 802.11 Work Well in Multi-hop Wireless Network?

Author: Shugong Xu, Tarek Saadawi

City University of New York

37

Overview of The Paper

This paper is about TCP over multi-hop networks, but its also about cross-layer interactions

Conclusion: Cross Layer interactions between 802.11 Protocol, routing and TCP can be destructive.

Experimental Scenario: A Static String Topology

TCP as Transport Layer Protocol

Problems: Instability Problem Unfairness Problem

0 1 2 3 4 5 6 7

38

Simulation Environment

Simulator: ns-2 with wireless extensions MAC Layer: IEEE 802.11 MAC Distributed Coordination

function(DCF). Transport Layer: TCP connections carrying bulk transfers

(always have data) Network Scenario

A Static String Network Topology Interference range is a little more than two times of the

communication range

0 1 2 3 4 5 6 7

Interference Range Communication Range

39

Instability Problem—Experiment Setup

1 2 3 4 5Source Destination

A single TCP connection, with node 1 as the source and node 5 as the destination.

Three sets of experiments with Maximum Window Size(window_) 32, 8, and 4 respectively.

40

Instability Problem—Experiment Result

When window_=32 or 8, serious oscillation of throughput is observed. When window_4, throughput is stable.

41

Instability Problem—Trace Analysis(1)

1 2 3 4 5Data

Ack

RTS

CTS

Interference Range of Node 2

42

Instability Problem—Summary

Collision and exposed terminal problem prevent node 2 from receiving RTS from or sending CTS to node 1.

The random back-off, big data packet, and sending back-to-back packets worsen the above problems.

When window_ = 4, the chance to send back a CTS is greatly increased, so the throughput becomes stable.

After node 1 fails seven times to receive CTS, node 1 believes there is a route failure and starts a route discovery.

Before a route is available, node 1 can not send out a data packet. This period usually is long enough to cause a timeout at the TCP sender.

For TCP, timeout triggers Slow Start, which significantly reduces the throughput.

43

Unfairness Problem—Experiment Setup

2 3 4 5 6

Source Destination

Source

First SessionSecond Session

In the first session, data flow from 6 to 4. In the second session, data flow from 2 to 3.

The first session starts at 10.0s. The second session starts at 30.0s.

44

Unfairness Problem (1)

The first session has a throughput of about 450kbps from 10s to 30s, and 0kbps after 30s.

The second session has a throughput of about 900kbps from 30s to 130s.

45

Unfairness Problem (2)

The first session never succeeds to send out packet with sequence number 2164.

46

Unfairness Problem—Trace Analysis(1)

2 3 4 5 6RTSData

CTS

Interfering Range of Node 5

Ack

Interfering Range of Node 4

Data

No Route

47

Unfairness Problem—Trace Analysis(2)

2 3 4 5 6RTSData

CTS

Interfering Range of Node 5

Ack

Interfering Range of Node 4

Data

No Route

48

Unfairness Problem—Summary

In one-hop TCP connections, the interval between packet transmission is larger than that of the multi-hop TCP connections, which gives the one-hop connection more chances to transmit data.

Random back-off is actually advantageous to the last succeeding host.

Problem called “One-hop unfairness problem” Authors argue that since one-hop connection is common

in a wireless network problem must be addressed

49

Discussion?

Problems Shown: Instability Problem Unfairness problem

Conclusions: IEEE 802.11 does not work well in multi-hop wireless

networks. It may be inappropriate to take IEEE 802.11 as the MAC

layer to simulate routing or transport protocols for multi-hop wireless networks.

Are Cross Layer Solutions needed?

Maybe a different set of protocols that play nicer together?

50

More discussion

Rooted in IEEE 802.11 MAC? TCP is not designed with wireless networking in mind. Timeout Slow Start

Interfering range and communication range If interfering range is the same as the communication range, the two

problems presented in this paper will disappear. Is the configuration of the interfering range simply an engineering issue?

Only a simple topology is considered What happens if more complex scenarios are considered? Different traffic? Multiple connections? Different spacing between nodes? More realistic wireless channel?

Can you relate to other stuff we have discussed so far?