special topics on wireless ad-hoc networks

Univ. of Tehran Computer Network 1

Special TopicsSpecial Topics on on

Wireless Ad-hoc Wireless Ad-hoc NetworksNetworks

University of TehranDept. of EE and Computer Engineering

By:Dr. Nasser Yazdani

Lecture 5: TCP for Ad-hoc TCP for Ad-hoc NetworksNetworks


Covered topicCovered topic Problems with TCP in MANET

How to improve TCP in MANET

References Chapter 9 of the book ATP: A Reliable Transport protocol for Ad-

hoc Networks.


OutlinesOutlines Problems with TCP in MANET

How to improve TCP in MANET


Issues of TCP in Ad hocIssues of TCP in Ad hoc1. Induced traffic: Link level transmission affect

neighbors of sender and receiver.2. Induced Throughput unfairness:

throughput/delay unfairness in link layer3. Separation of congestion control, realiability

and flow control4. Power and bandwidth constrains.5. Misinterpretation of congestion:6. Completely decoupled transport layer: 7. Dynamic topology.


Performance of TCPPerformance of TCPSeveral factors affect TCP performance in

MANET: Wireless transmission errors Multi-hop routes on shared wireless

medium For instance, adjacent hops typically cannot

transmit simultaneously Route failures due to mobility


Random ErrorsRandom Errors If number of errors is small, they may be

corrected by an error correcting code Excessive bit errors result in a packet being

discarded, possibly before it reaches the transport layer

Problems Fast retransmission of lost packet reduction in congestion window Reduction in congestion window reduces the

throughput Burst Errors May Cause Timeouts


Impact of Multi-Hop Impact of Multi-Hop Wireless PathsWireless Paths

0

200

400

600

800

1000

1200

1400

1600

1 2 3 4 5 6 7 8 9 10

Number of hops

TCPThroughtput(Kbps)

TCP Throughput using 2 Mbps 802.11 MAC

•Connections over multiple hops are at a disadvantage compared to shorter connections, because they have to contend for wireless access at each hopExtent of packet delay or drop

increases with number of hops


Mobile Ad Hoc NetworksMobile Ad Hoc Networks[IETF-MANET][IETF-MANET]

Mobility causes route changes


Throughput Degradations Throughput Degradations withwithIncreasing Number of Increasing Number of HopsHops

Packet transmission can occur on at most one hop among three consecutive hops Increasing the number of hops from 1 to 2, 3 results

in increased delay, and decreased throughput Increasing number of hops beyond 3 allows

simultaneous transmissions on more than one link, however, degradation continues due to contention between TCP Data and Acks traveling in opposite directions

When number of hops is large enough, the throughput stabilizes due to effective pipelining


Ideal ThroughputIdeal Throughput

f(i) = fraction of time for which shortest path length between sender and destination is I

T(i) = Throughput when path length is I

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


Impact of MobilityImpact of Mobility

Ideal throughput (Kbps)

Act

ual t

hrou

ghpu

t

2 m/s 10 m/s


Impact of MobilityImpact of Mobility

Ideal throughput

Act

ual t

hrou

ghpu

t

20 m/s 30 m/s


Throughput degrades with Throughput degrades with

increasing speed increasing speed ……

Speed (m/s)

AverageThroughputOver 50 runs

Ideal

Actual


But But notnot always always ……

Mobility pattern #

Actualthroughput

20 m/s

30 m/s


mobility causeslink breakage,resulting in routefailure

TCP data and acksen route discarded

Why Does Throughput Why Does Throughput Degrade?Degrade?

TCP sender times out.Starts sending packets again

Route isrepaired

No throughput

No throughputdespite route repair


mobility causeslink breakage,resulting in routefailure

TCP data and acksen route discarded

Why Does Throughput Why Does Throughput Degrade?Degrade?

TCP sendertimes out.Backs off timer.

Route isrepaired

TCP sendertimes out.Resumessending

Larger route repair delaysespecially harmful

No throughput

No throughput

despite route repair


Low Speed ScenarioLow Speed Scenario

C

B

D

A

C

B

D

A

C

B

D

A

1.5 second route failure

Route from A to D is broken for ~1.5 second.

When TCP sender times after 1 second, route still broken.

TCP times out after another 2 seconds, and only then resumes.


Higher (double) Speed Higher (double) Speed ScenarioScenario

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.


General PrincipleGeneral Principle The previous two slides show a plausible

cause for improved throughput TCP timeout interval somewhat (not

entirely) independent of speed Network state at higher speed, when

timeout occurs, may be more favorable than at lower speed

Network state Link/route status Route caches Congestion


Improve ThroughputImprove Throughput(Closer to Ideal)(Closer to Ideal)

Network feedback Inform TCP of route failure by

explicit message Let TCP know when route is repaired

Probing Explicit notification

Reduces repeated TCP timeouts and backoff


Performance ImprovementPerformance Improvement

Without networkfeedback

Ideal throughput 2 m/s speed

With feedback

Act

ua

l thr

oug

hpu

t


Performance ImprovementPerformance Improvement

Without networkfeedback

With feedback

Ideal throughput 30 m/s speed

Act

ua

l thr

oug

hpu

t


Performance with Explicit Performance with Explicit NotificationNotification

0

0.2

0.4

0.6

0.8

1

2 10 20 30

mean speed (m/s)

thro

ug

hp

ut

as a

fra

ctio

n o

f id

eal

Base TCP

With explicitnotification


IssuesIssuesNetwork FeedbackNetwork Feedback

Network knows best (why packets are lost)+ Network feedback beneficial- Need to modify transport & network layer to

receive/send feedback Need mechanisms for information exchange

between layers [Holland99] discusses alternatives for

providing feedback (when routes break and repair) [Chandran98] also presents a feedback scheme


Impact of CachingImpact of Caching Route caching has been suggested as a

mechanism to reduce route discovery overhead [Broch98]

Each node may cache one or more routes to a given destination

When a route from S to D is detected as broken, node S may: Use another cached route from local cache, or Obtain a new route using cached route at

another node


To Cache or Not to CacheTo Cache or Not to Cache

Average speed (m/s)Ac t

ual t

hrou

ghpu

t (a s

fra

ctio

n of

exp

ecte

d th

roug

hput

)


Why Performance Why Performance Degrades With CachingDegrades With Caching

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

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

Another route discovery, and TCP time-out interval

Process repeats until a good route is found

timeout dueto route failure

timeout, cachedroute is broken

timeout, second cachedroute also broken


IssuesIssuesTo Cache or Not to CacheTo Cache or Not to Cache

Caching can result in faster route “repair”

Faster does not necessarily mean correct

If incorrect repairs occur often enough, caching performs poorly

Need mechanisms for determining when cached routes are stale


IssuesIssues Window Size After Route Window Size After Route RepairRepair

Same as before route break: may be too optimistic

Same as startup: may be too conservative

Better be conservative than overly optimistic Reset window to small value after route

repair Let TCP figure out the suitable window size Impact low on paths with small delay-bw

product


IssuesIssuesRTO After Route RepairRTO After Route Repair

Same as before route break If new route long, this RTO may be too small, leading to

timeouts Same as TCP start-up (6 second)

May be too large May result in slow response to next packet loss

Another plausible approach: new RTO = function of old RTO, old route length, and new route length Example: new RTO = old RTO * new route length / old

route length Not evaluated yet Pitfall: RTT is not just a function of route length


Out-of-Order Packet Out-of-Order Packet DeliveryDelivery

Out-of-order (OOO) delivery may occur due to: Route changes Link layer retransmissions schemes that deliver OOO

Significantly OOO delivery confuses TCP, triggering fast retransmit

Potential solutions: Deterministically prefer one route over others, even if

multiple routes are known Reduce OOO delivery by re-ordering received packets

can result in unnecessary delay in presence of packet loss Turn off fast retransmit

can result in poor performance in presence of congestion


Impact of Impact of AcknowledgementsAcknowledgements

TCP Acks (and link layer acks) share the wireless bandwidth with TCP data packets

Data and Acks travel in opposite directions In addition to bandwidth usage, acks

require additional receive-send turnarounds, which also incur time penalty

To reduce frequency of send-receive turnaround and contention between acks and data


Impact of Acks: MitigationImpact of Acks: Mitigation Piggybacking link layer acks with data Sending fewer TCP acks - ack every d-

th packet (d may be chosen dynamically)

but need to use rate control at sender to reduce burstiness (for large d)

Ack filtering - Gateway may drop an older ack in the queue, if a new ack arrives reduces number of acks that need to be

delivered to the sender


TCP in Mobile Ad Hoc TCP in Mobile Ad Hoc NetworksNetworksIssues Issues (summary)(summary)

Route changes due to mobility Wireless transmission errors

problem compounded with multiple hops Out-of-order packet delivery

frequent route changes may cause out-of-order delivery TCP does not perform well if packets are significantly OOO

Multiple access protocol choice of MAC protocol can impact TCP performance

significantly Half-duplex radios

cannot send and receive packets simultaneously changing mode (send or receive) incurs overhead


Impact of MAC - Impact of MAC - Delay Delay VariabilityVariability

As wireless medium is shared between multiple sources, the round-trip delay is variable

Also, on slow wireless networks, delay is large made larger by send-receive turnaround time

Large and variable delays result in larger RTO On packet loss, timeout takes much longer to

occur Idle source (waiting for timeout to occur) lowers

TCP throughput


Impact of MAC - Impact of MAC - Delay Delay VariabilityVariability

Several techniques may be used to mitigate problem, based on minimizing ack transmissions to reduce frequency of send-receive turnaround and

contention between acks and data Piggybacking link layer acks with data Sending fewer TCP acks - ack every d-th packet (d

may be chosen dynamically) but need to use rate control at sender to reduce burstiness (for

large d) Ack filtering - Gateway may drop an older ack in

the queue, if a new ack arrives reduces number of acks that need to be delivered to the

sender


Header Compression for Header Compression for Wireless NetworksWireless Networks

In TCP packet stream, most header bits are identical Van Jacobson’s scheme exploits this observation to compress

headers, by only sending the “delta” between the previous and current header

Packet losses result in inefficiency, as headers cannot be reconstructed due to lost information

Packet losses likely on wireless links [Degermark96] proposes a technique that works well despite

single packet loss “twice” algorithm if current packet fails TCP checksum, assume that a single packet is lost apply delta for the previous packet twice to the current header, and test

checksum again


Automatic TCP Buffer Automatic TCP Buffer TuningTuning

Using too small buffers can yield poor performance

Using too large buffers can limit number of open connections

Automatic mechanisms to choose buffer size dynamically would be useful


Sources of problems?Sources of problems? Misinterpretation of packet loss Frequent path breaks Effect of path length Misinterpretation of congestion window Asymmetric link behavior: location dependent

contention Uni-directional path: each Ack requires RTS-CTS-

data-Ack, more than 70 bytes of overhead Multipath routing: out of order packet and dupAck. Network partitioning and remerging Sliding Window: size of the window


Design goalsDesign goals1. Maximize throughput per connection2. Throughput fairness3. Minimum connection setup and maintenance overhead.4. Mechanisms for congestion and flow controls5. Reliable and unreliable connections6. Adapt to the dynamics of the network.7. Resource, Bandwidth, used efficiently.8. Aware of resource, battery, constraints.9. End to end semantics10. Use information from the lower layer11. Well-defined cross-layer interaction for effective and

scalable protocol


Different approachesDifferent approaches Adapt TCP for Ad hoc

Split-TCP End to end approaches Mostly the same problems discussed in

Wireless TCP New Transport protocols

Application Control Transport Protocol (ACTP)

Ad Hoc Transport Protocol (ATP)


ACTP protocolACTP protocol A light weight transport layer protocol Reliability is left to the application It is like UDP with feedback It supports priority Advantages

It is scalable No congestion window, then, path break does not

affect much thoughput Disadvantages:

Not compatible with TCP Might cause congestion in very large ad hoc Networks


ATP protocolATP protocol A reliable transport layer protocol Coordination between different layers of the

protocol stack. Rate based Transmission

Transmission is scheduled by timer No need for self clocking Avoid burstiness

Decoupling of congestion control and reliability. Assisted Congestion control: regulate rate based on

the feedback from network TCP friendliness and fairness


ATP protocolATP protocol Intermediate node: keep Qt and Tt as the average

queuing and transmission delay. They are computed over all packet

Each packet has a D field, rate feedback, which is the maximum of Qt + Tt in the upstream nodes the packet travese.

Receiver: send periodic feedback to the source with value of D. it runs an epoch time of period E

Rate Feedback: an exponential averaging of D, Reliability Feedback: use SACK with bigger blocks (20

here) Flow Control feedback: done by received rate.


ATP protocol (cont)ATP protocol (cont) Sender: Perform quick start, congestion control,

reliability and connection management Quick start: Send a probe packet to calculate

available BW by considering D and the rate Three congestion phases: Increase, decrease and

maintains Increase: done more aggressively. If the current rate was

less the calculated one Decrease: less conservative. Maitain: if the currently rate was close to the feedback rate.

Reliability: receiver sends hole periodicly


Issues for Further Issues for Further InvestigationInvestigation


Link Layer ProtocolsLink Layer Protocols “Pure” link layer designs that support

higher transport performance some recent work in this area as noted

earlier Identifying scenarios where link layer

solutions are inadequate If TCP-awareness is absolutely needed,

provide an interface that can be used by other transport protocols too


End-to-End TechniquesEnd-to-End Techniques Existing techniques typically require

cooperation from intermediate nodes. Such techniques often not applicable

encrypted TCP headers TCP data and acks do not go through same base

station End-to-end techniques would rely on

information available only at end nodes Harder to design due to lack of complete

information about errors Explicit Notifications may make that easier


Impact of Congestion Impact of Congestion LossesLosses

Past work typically evaluates performance in absence of congestion

Relative performance improvement may change substantially when congestion occurs performance improvement may reduce if

congestion is dominant, or if RTO becomes larger due to wireless errors


Multiple TCP TransfersMultiple TCP Transfers Past work typically measures a single TCP

connection over wireless TCP throughput is the metric of choice

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

Relative performance improvements of various schemes may change when multiple connections are considered


TCP Window & RTO TCP Window & RTO Settings After a MoveSettings After a Move

Congestion window & RTO size at connection open are chosen to be conservative

When a route change occurs due to mobility, which values to use? Same as before route change ---- may be too

aggressive Same as at connection open ---- may be too

conservative Answer unclear

some proposals attempt to use same values as before route change, but not clear if that is the best alternative


TCP for Mobile Ad Hoc TCP for Mobile Ad Hoc NetworksNetworks

Much work on routing in ad hoc networks

Some recent work on TCP for ad hoc networks

Need to investigate many issues MAC-TCP interaction routing-TCP interaction impact of route changes on window

size, RTO choice after move

special topics on wireless ad-hoc networks

Documents

tcp performance

tcp data

tcp sender times

iideal throughput

wireless ad

computer engineeringby

induced throughput unfairness

wireless access