Tema 2.- Redes inalámbricas Ad Hoc. Tema 2.- Redes inalámbricas Ad Hoc. TCPTCP

Overview of TCPThe problems of TCP over MANETsEstudios realizados por el Grupo GRC

Interacción Routing Protocols & TCP

Email WWW Voice...

SMTP HTTP RTP...

TCP UDP

IP

Eth t PPPEthernet PPP…

MultiAccess async sync...

copper fiber radio...

Redes Inalámbricas Ad Hoc Máster Ingeniería de Telecomunicación, Universidad de Málaga 2008/2009Redes Inalámbricas Ad Hoc Máster Ingeniería de Telecomunicación, Universidad de Málaga 2008/2009

009

2Transmission Control Protocol / Internet Protocol

TCP/IPM

IT 2

008/

20

Internet Protocol (IP)Packets may be delivered out-of-orderM Packets may be delivered out-of-orderPackets may be lostPackets may be duplicated

Transmission Control Protocol (TCP)Provide reliable end-to-end message transmissionReliability achieved by means of retransmissions if necessaryImplements congestion avoidance and control

Window and ack basedWindow and ack based

End-to-end semanticsAcknowledgements sent to TCP sender confirm delivery of dataA k f d t t l ft d t h h d i

s A

d H

oc

Ack for data sent only after data has reached receiver

TCP is still needed for MANETs

alám

bric

as

TCP is still needed for MANETs It is widely used in the current InternetWe would like to achieve a smooth integration with the fixed Internet

Red

es I

na

009

3TCP Overview

MIT

200

8/20

How TCP adapt to the network requirements?

M

Flow Control: It regulate the number of packets it sends by inflating or deflating a windowinflating or deflating a window

To do that TCP uses the cumulative acknowledge (ACKs) sent by the receiverIt can affect the average throughput

Sliding Window Protocol: 1 2 3 4 5 6 7 8 9 10 11 12

Congestion Control: It tries to solve the delay caused by packet

Sliding Window Protocol: 1 2 3 4 5 6 7 8 9 10 11 12 ….

s A

d H

oc

Congestion Control: It tries to solve the delay caused by packet losses due to congestion

Congestion control scheme in regular (Tahoe) TCP implementation has th i h

alám

bric

as three main phases:– Slow-start– Congestion Avoidance (CA)

Red

es I

na Congestion Avoidance (CA)

– Fast Retransmit

009

4Cumulative Acknowledge

MIT

200

8/20

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

It ack’s all contiguously received data

41 40 3839

35 373634

i data acki

Duplicate Acknowledgements

i i

s A

d H

oc

Duplicate AcknowledgementsA dupack is generated whenever an out-of-order segment arrives at the receiverD li t k b t d h

alám

bric

as Duplicate acks may be generated whena packet is lost, ora packet is delivered out-of-order (OOO)

Red

es I

na

Thanks to: Nitin Vaidya, University of Illinois at Urbana-Champaign

009

5Window Based Flow Control

MIT

200

8/20

Sliding window protocolM S d g do p otocoWindow size minimum of

receiver’s advertised windowdetermined by available buffer space at the receiver

congestion windowdetermined by the sender based on feedback from the networkdetermined by the sender, based on feedback from the network

Sender’s window

2 3 4 5 6 7 8 9 10 11 131 12Sender’s window

s A

d H

oc

Ack 52 3 4 5 6 7 8 9 10 11 131 12

alám

bric

as

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

Acks received Not transmitted

Red

es I

na

Sender’s windowSender’s window

009

6Congestion Control

MIT

200

8/20

On detecting a packet loss, TCP sender assumes that network congestion has occurredM congestion has occurredOn detecting packet loss, TCP sender drastically reduces the congestion windowgReducing congestion window reduces amount of data that can be sent per RTT

throughput may decrease

Q ti ?Questions?How does TCP detect a packet loss?How Congestion Control Works?

s A

d H

oc

How Congestion Control Works? Multiple choices … TCP-Reno, TCP-Vegas, …

– Slow-start

alám

bric

as Slow start– Congestion Avoidance (CA)– Fast Retransmit

Red

es I

na

009

7How does TCP detect a packet loss?

MIT

200

8/20

1. Retransmission timeout (RTO)If acknowledgement for the timed packet is not received before timer goes offM If acknowledgement for the timed packet is not received before timer goes off, the packet is assumed to be lostRTO dynamically calculatedIf (RTO = mean + 4 mean deviation) It assume packet lost

2 Duplicate acknowledgements2. Duplicate acknowledgementsTimeouts can take too long

how to initiate retransmission sooner?

Fast retransmit:TCP sender assumes that a packet loss has occurred if it receives three d k ti l

s A

d H

oc

dupacks consecutively

Remember:

alám

bric

as

Remember:Dupacks may be generated due to– packet loss, or

out of order packet delivery

Red

es I

na – out-of-order packet delivery

009

8How Congestion Control Works?

MIT

200

8/20

Overview of congestion control mechanismsSl t t h M Slow-start phase:

cwnd start from 1 and increase exponentiallyIt increment window size on each new ackIt increment window size on each new ackslow start phase ends when window size reaches the slow-start threshold

Congestion avoidance (CA):cwnd increase linearly

101214

ndow

size

s)

Congestionavoidance

s A

d H

oc

468

gest

ion

Win

(seg

men

ts

Slow start

Slow start threshold

alám

bric

as

02

0 1 2 3 4 5 6 7 8

Con

g

Red

es I

na

Time (round trips)

009

9Congestion Control -- Timeout

MIT

200

8/20

On a timeout, the congestion window is reduced to 1The slow start threshold is set to half the window size before packetM The slow start threshold is set to half the window size before packet lossSlow start is initiatedSlow start is initiated

25nts)20

25

(seg

men

cwnd = 20

After timeout

10

15w

indo

w

s A

d H

oc

0

5

nges

tion ssthresh = 8 ssthresh = 10

alám

bric

as 00 3 6 9 12 15 20 22 25

Con

Red

es I

na

Time (round trips)

009

10Congestion Control - Fast retransmit

MIT

200

8/20

Fast retransmit occurs when multiple (>= 3) dupacks come backFast recovery follows fast retransmitM Fast recovery follows fast retransmitDifferent from timeout: (slow start follows timeout)

timeout occurs when no more packets are getting acrosstimeout occurs when no more packets are getting acrossfast retransmit occurs when a packet is lost, but latter packets get throughSo, no need to slow start

Fast retransmit - Fast recoveryRetransmit the missing segment (fast retransmit)f f d f d d d h lfAfter fast retransmit and fast recovery window size is reduced in half

After fast recovery

s A

d H

oc

6

8

10

(seg

men

ts) Receiver’s advertized window

alám

bric

as

0

2

4

Win

dow

size

Red

es I

na 0

0 2 4 6 8 10 12 14Time (round trips)

009

11Impact of Transmission Errors and Mobility on TCP

MIT

200

8/20

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

Unnecessarily reduces congestion windowThroughput suffers

There are to many schemes in the literature to Improve Performance of TCP in Presence of Transmission Errors and mobility based on:

Retransmit a packet lost due to transmission errors, without taking any congestion control actionscongestion control actionsTransmission errors should be hidden from the sender -- the errors should be recovered transparently and efficiently

s A

d H

oc

Hide mobility from the TCP senderMake TCP adaptive to mobility

alám

bric

as

In MANET :Issues in multi-hop wireless networks

Red

es I

na Issues in multi hop wireless networks

009

12TCP in Mobile Ad Hoc Networks Issues

MIT

200

8/20

Effects of long partition on TCPEffects of mobility on TCPM Effects of mobility on TCPMAC layer impacts on TCP Network layer impacts on TCPNetwork layer impacts on TCPOut-of-Order Packet Delivery

s A

d H

ocal

ámbr

icas

Red

es I

na

009

13Effects of long partition on TCP

MIT

200

8/20

Problems due to partitionsAfter a packet lost is detected due to timeout TCP retransmits the lost packetM After a packet lost is detected due to timeout TCP retransmits the lost packet and doubles its RTO (Retransmission timeout up to 64 s)What happens if the partition disappears?

Dead time.

s A

d H

ocal

ámbr

icas

Red

es I

na

009

14Effects of mobility on TCP

MIT

200

8/20

Throughput generally degrades with increasing speed …

M

Average

Ideal

AverageThroughputOver 50 runs Actual

mobility causeslink breakagemobility causeslink breakage

Speed (m/s)

link breakage,resulting in routefailure

link breakage,resulting in routefailure

TCP sender times out.Starts sending packets againTCP sender times out.Starts sending packets again

Route isrepairedRoute isrepaired

But not always

Speed (m/s)

No throughput

No throughput

No throughputNo throughput

No throughput

s A

d H

oc

No throughputdespite route repairNo throughputdespite route repair

Actual20 m/s

30 m/s

alám

bric

as

TCP data and acksen route discardedTCP data and acksen route discarded

throughput

Red

es I

na

009

15Why Does Throughput Improve? Low Speed Scenario

MIT

200

8/20

Low Speed ScenarioRoute from A to D is broken for ~1 5 secondM 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.

Higher Speed ScenarioRoute from A to D is broken for ~ 0.75 second.Wh TCP d ti ft 1 d t i i dWhen TCP sender times after 1 second, route is repaired.

D D DC

B

DC

B

D

A

C

B

D

A

s A

d H

oc

TCP i i l h ( i l ) i d d f d

A A

alám

bric

as TCP timeout interval somewhat (not entirely) independent of speedNetwork state at higher speed, when timeout occurs, may be more favorable than at lower speed

Red

es I

na favorable than at lower speed

009

16MAC layer impacts on TCP

MIT

200

8/20

MAC layer problems (hidden node and exposed node) can seriously hurt the TCP performanceM hurt the TCP performance

Hidden and exposed nodes can cause lack of ACKs at the TCP sender.This will either:

– Trigger a TCP retransmission by timeout – Impact the TCP fast retransmission

The more number of hops the lower the expected throughputThe more number of hops the lower the expected throughput

14001600

800100012001400

TCPThroughtput

s A

d H

oc

200400600800 Throughtput

(Kbps)

alám

bric

as 01 2 3 4 5 6 7 8 9 10

Number of hops

Red

es I

na Number of hops

009

17Network layer impacts on TCP

MIT

200

8/20

Problems with approaches using cachesRoute caching has been suggested as a mechanism to reduce route discoveryM Route caching has been suggested as a mechanism to reduce route discovery overhead DSR

Each node may cache one or more routes to a given destinationGenerally: When a route from S to D is detected as broken, node S may:

Use another cached route from local cache, orObtain a new route using cached route at another nodeg

t)

Unless the stale route can be detected and recovery in a fast

TCP b l d t b k ff hp

ut

d t h

roug

hpu

tway, TCP can be led to backoff state, which will deteriorate its performance critically.

Not using caching: tradeoff

s A

d H

oc

tual

th

r ou

g h o

f e x

pect

e d

Not using caching: tradeoff Routing overhead vs route accuracy

TCP

Caching can reduce overhead of

alám

bric

as Act

(as

fra c

tio nroute discovery

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

Red

es I

na

Average speed (m/s)

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

009

18Why Performance Degrades With Caching

MIT

200

8/20

Caching can result in faster route “repair”M Caching can result in faster route repairFaster does not necessarily mean correct

When a route is broken, route discovery returns a cached f l l h f b droute from local cache or from a nearby node

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

s A

d H

oc timeout dueto route failure

timeout, cachedroute is broken

timeout, second cachedroute also broken

alám

bric

as

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

Red

es I

na Process repeats until a good route is found

009

19Network layer impacts on TCP

MIT

200

8/20

Problems with approaches using multiple paths¿Wh i lti l th?M ¿Why using multiple path?Problem with TCP: Out of order packets Retransmission of packetspackets

Some approaches try to use a self-adaptive mechanism to avoid new packets using shorter paths.

Problems with PATH asymmetryAsymmetrical path can seriously affect TCP performance

If TCP can not receive timely ACKs it can not expand the CWND to make use of the full capacity of the channel

– Bandwidth asymmetry, Loss rate asymmetry, Media access asymmetry, Route

s A

d H

oc

asymmetryAsymmetry can also induce inaccuracy on RTT estimation.

Some solutions: Try to reduce the number of ACKs in the

alám

bric

as Some solutions: Try to reduce the number of ACKs in the backward path Delayed Acknowledgements

Since ACKs are cumulative

Red

es I

na

009

20Delayed Acknowledgements

MIT

200

8/20

An ack is delayed until

M

another packet is received, ordelayed ack timer expires (200 ms typical)

Reduces ack traffic New ack not producedon receipt of packet 36,

but on receipt of 37

40 39 3738

but on receipt of 37

3533

s A

d H

ocal

ámbr

icas 41 40 3839

Red

es I

na

35 37

009

21Out-of-Order Packet Delivery

MIT

200

8/20

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

M

Significantly OOO delivery confuses TCP, triggering fast retransmit

Potential solutions:Avoid OOO delivery by ordering packets before delivering to IPAvoid OOO delivery by ordering packets before delivering to IP layer

can result in variable delay

s A

d H

oc turn off fast retransmitcan result in poor performance in presence of congestion

alám

bric

asR

edes

In

a

009

22Other TCP issues

MIT

200

8/20

Window Size After Route RepairSame as before route break: may be too optimisticM Same as before route break: may be too optimisticSame as startup: may be too conservative

RTO After Route RepairpSame as before route break

If new route long, this RTO may be too small, leading to timeouts

S TCP t t (6 d)Same as TCP start-up (6 second)May be too largeWill result in slow response to future losses

ProposalsProposals: new RTO = function of old RTO, old route length, and new route length

MAC Delay variability

s A

d H

oc

MAC Delay variabilityLarge and variable delays result in larger RTOOn packet loss, timeout takes much longer to occur

alám

bric

as

p , gIdle source (waiting for timeout to occur)

Red

es I

na

009

23TCP for Mobile Ad Hoc Networks

MIT

200

8/20

Much work on routing in ad hoc networksS k C f d h kM Some work on TCP for ad hoc networks

TCP variantsNon TCP variants

They try to avoid the exponential backoff mechanism when losses take place by factors others than congestionplace by factors others than congestionHowever other factors should also be considered

– Path asymmetry, cross layer impact?

Need to investigate many issues

s A

d H

oc MAC-TCP interactionRouting-TCP interaction

alám

bric

as Impact of route changes on window size, RTO choice after movePower management, cross-layer, interoperation, security

Red

es I

na

009

24Propuestas del Grupo GRC

MIT

200

8/20

Objective:T fi d th it bl TCP i t f MANET h i dM To find the more suitable TCP variants for MANET has increased

First trial to extensively compare the two TCPs over AODV and OLSR

s A

d H

ocal

ámbr

icas

Dongkyun Kim, Juan-Carlos Cano, Pietro Manzoni, C.K. Toh, "A comparison of the performance of TCP-Reno

Red

es I

na Dongkyun Kim, Juan Carlos Cano, Pietro Manzoni, C.K. Toh, A comparison of the performance of TCP Reno and TCP-Vegas over MANETs", Third IEEE International Symposium on Wireless Communication Systems (ISWCS), 5-8 of September 2006, Valencia (Spain).

009

25TCP-Reno

MIT

200

8/20

Most widely used TCP variant Sl St t C ti A id F t RM Slow Start, Congestion Avoidance, Fast Recovery

cwnd Packet loss

s A

d H

ocal

ámbr

icas

timeSlow Congestion Timeout Slow

Red

es I

na

Start Avoidance Start

009

26TCP-Vegas

MIT

200

8/20

Trying to alleviate TCP’s oscillation.i i il bl b d id h b d h diffM Estimating available bandwidth based on the difference

between expected and actual flows rates.

Upon an ack arrivals:Expected = CWND/BaseRTT Expected = CWND/BaseRTT

Actual = CWND/ActualRTTDiff = (Expected – Actual) BaseRTT

s A

d H

oc

Diff (Expected Actual) BaseRTT

CWND + 1 if Diff < α

alám

bric

as CWND = CWND – 1 if Diff > βCWND otherwise

Red

es I

na

009

27Simulation

MIT

200

8/20

Simulation tool : NS-2Simulation environmentM Simulation environment

Application Protocol FTP

Transport Protocol TCP-Reno, TCP-Vegas

Routing Protocol AODV, OLSR

MAC Protocol 2 Mbps Wireless LAN (CSMA/CA)

Terrain Dimensions 1000×1000

Number of Nodes 50

s A

d H

oc

Number of Nodes 50

Mobility Random waypoint

alám

bric

asR

edes

In

a

009

28Simulation Results

MIT

200

8/20

Performance Comparison of TCP-Reno over AODV and OLSRA long latency of route discovery due to route breakage in AODVM A long latency of route discovery due to route breakage in AODV

TCP Sender experiences many timeout eventsReduce its CWND

However, OLSR forces a node with changed link topology to promptly flood the changeEvery node using OLSR finds another next-hop quicklyContinues transmitting its TCP segments before a timeout event occursContinues transmitting its TCP segments before a timeout event occurs

s A

d H

ocal

ámbr

icas

Red

es I

na

Pause time = 0 Pause time = 20

009

29Simulation Results (con’t)

MIT

200

8/20

The OLSR reduces the dropping of thecontention window sizeM contention window size

s A

d H

ocal

ámbr

icas

Red

es I

na

009

30Simulation Results (con’t)

MIT

200

8/20

Also: TCP throughput decreases as the hop distance between source and destination nodes increaseM between source and destination nodes increase

OLSR obtains easily the shortest pathEach node can view the network topologyEach node can view the network topology

AODV cannot guarantee the usage of shortest pathAODV cannot guarantee the usage of shortest path An RREP corresponding to the RREQ which has reached the receiver earliest is simply sent

s A

d H

ocal

ámbr

icas

Red

es I

na

009

31Simulation Results (con’t)

MIT

200

8/20

Performance Comparison of TCP-Vegas over AODV and OLSRM OLSR

Similar results

s A

d H

ocal

ámbr

icas

Pause time = 0 Pause time = 20

Red

es I

na

009

32Simulation Results (con’t)

MIT

200

8/20

Performance Comparison of TCP-Reno and TCP-Vegas over AODVM AODV (Sometimes we do not have the implementation of a required routing protocol)

TCP-Reno aggressively increase its CWNDUnnecessary increase of window size causes much contention on the shared channelUnnecessary increase of window size causes much contention on the shared channelOccurrences of unnecessary route discovery caused by “hidden node problem”

s A

d H

ocal

ámbr

icas

Pause time = 0 Pause time = 20

Red

es I

na

009

33Simulation Results (con’t)

MIT

200

8/20

Performance Comparison of TCP-Reno and TCP-Vegas over OLSRM OLSR

s A

d H

ocal

ámbr

icas

Pause time = 0 Pause time = 20

Red

es I

na

009

34Simulation Results (con’t)

MIT

200

8/20

Sending rate of a source using TCP-VegasDetermined according to the difference between expected throughput andM Determined according to the difference between expected throughput and actual throughput

If TCP-Vegas begins using a new route due to node mobilityIts base RTT is not a new base RTT, but the base RTT over the old route Inaccuracy results in performance degradation

AODVAODVAdheres to the same route until the route is broken

OLSR

s A

d H

oc Link change triggers node to update their routing tables, which allows another route to be selectedThe frequent change of route causes the inaccuracy of base RTT to be

alám

bric

as The frequent change of route causes the inaccuracy of base RTT to be exaggerated.

Red

es I

na

009

35Conclusions

MIT

200

8/20

TCP is not the most appropriate protocol for MANETs,TCP will be on top of the routing protocol irrespective of TCP VariantsM TCP will be on top of the routing protocol irrespective of TCP VariantsIn summary, from the view of throughput

OLSR is the best routing protocol irrespective of TCP variantsOLSR is the best routing protocol irrespective of TCP variantsTCP-Vegas performs better for AODVTCP-Reno is more suitable for OLSR

we found that which to select among routing protocols is more important than which to select among TCP variants

s A

d H

ocal

ámbr

icas

Red

es I

na