Download TCP for Ad-hoc Networks

Special Topics
on
Wireless Ad-hoc Networks
Lecture 5: TCP for Ad-hoc
Networks
University of Tehran
Dept. of EE and Computer Engineering
By:
Dr. Nasser Yazdani
Univ. of Tehran
Computer Network
1
Covered 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.
Univ. of Tehran
Computer Network
2
Outlines

Problems with TCP in MANET

How to improve TCP in MANET
Univ. of Tehran
Computer Network
3
Issues of TCP in Ad hoc
1.
2.
3.
4.
5.
6.
7.
Induced traffic: Link level transmission affect
neighbors of sender and receiver.
Induced Throughput unfairness: throughput/delay
unfairness in link layer
Separation of congestion control, realiability and
flow control
Power and bandwidth constrains.
Misinterpretation of congestion:
Completely decoupled transport layer:
Dynamic topology.
Univ. of Tehran
Computer Network
4
Performance of TCP
Several 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
Univ. of Tehran
Computer Network
5
Random 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
Univ. of Tehran
Computer Network
6
Impact of Multi-Hop Wireless
Paths
•Connections over multiple hops are at a disadvantage
compared to shorter connections, because they have
to contend for wireless access at each hop
Extent of packet delay or drop
increases with number of hops
1600
1400
1200
1000
800
600
400
200
0
TCP
Throughtput
(Kbps)
1 2 3 4 5 6 7 8 9 10
TCP Throughput using
2 Mbps 802.11 MAC
Number of hops
Univ. of Tehran
Computer Network
7
Mobile Ad Hoc Networks
[IETF-MANET]

Mobility causes route changes
Univ. of Tehran
Computer Network
8
Throughput Degradations with
Increasing Number of Hops

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
Univ. of Tehran
Computer Network
9
Ideal 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 = S f(i) * T(i)
Univ. of Tehran
Computer Network
10
Impact of Mobility
2 m/s
10 m/s
Ideal throughput (Kbps)
Univ. of Tehran
Computer Network
11
Impact of Mobility
20 m/s
30 m/s
Ideal throughput
Univ. of Tehran
Computer Network
12
Throughput degrades with
increasing speed …
Ideal
Average
Throughput
Over
50 runs
Actual
Speed (m/s)
Univ. of Tehran
Computer Network
13
But not always
…
30 m/s
20 m/s
Actual
throughput
Univ. of Tehran
Mobility pattern #
Computer Network
14
Why Does Throughput
Degrade?
mobility causes
link breakage,
resulting in route
failure
Route is
repaired
TCP sender times out.
Starts sending packets again
No throughput
No throughput
despite route repair
TCP data and acks
en route discarded
Univ. of Tehran
Computer Network
15
Why Does Throughput
Degrade?
mobility causes
link breakage,
resulting in route
failure
TCP sender
times out.
Backs off timer.
Route is
repaired
TCP sender
times out.
Resumes
sending
No throughput
No throughput
despite route repair
Larger route repair delays
especially harmful
TCP data and acks
en route discarded
Univ. of Tehran
Computer Network
16
Low Speed Scenario
C
D
B
C
D
B
A
C
D
B
A
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.
Univ. of Tehran
Computer Network
17
Higher (double) Speed
Scenario
C
D
B
C
D
B
A
C
D
B
A
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.
Univ. of Tehran
Computer Network
18
General 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
Univ. of Tehran
Computer Network
19
Improve Throughput
(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
Univ. of Tehran
Computer Network
20
Performance Improvement
With feedback
Actual throughput
Without network
feedback
Univ. of Tehran
Ideal throughput
2 m/s speed
Computer Network
21
Performance Improvement
With feedback
Actual throughput
Without network
feedback
Univ. of Tehran
Ideal throughput
30 m/s
speed
Computer
Network
22
throughput as a fraction of
ideal
Performance with Explicit
Notification
1
0.8
Base TCP
0.6
With explicit
notification
0.4
0.2
0
2
10
20
30
mean speed (m/s)
Univ. of Tehran
Computer Network
23
Issues
Network 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
Univ. of Tehran
Computer Network
24
Impact 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
Univ. of Tehran
Computer Network
25
To Cache or Not to Cache
Average speed (m/s)
Univ. of Tehran
Computer Network
26
Why Performance Degrades
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
timeout due
to route failure


timeout, cached timeout, second cached
route is broken
route also broken
Another route discovery, and TCP time-out interval
Process repeats until a good route is found
Univ. of Tehran
Computer Network
27
Issues
To 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
Univ. of Tehran
Computer Network
28
Window Size After Route
Repair



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
Univ. of Tehran
Computer Network
29
Issues
RTO After Route Repair

Same as before route break


Same as TCP start-up (6 second)



If new route long, this RTO may be too small, leading to
timeouts
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
Univ. of Tehran
Computer Network
30
Out-of-Order Packet Delivery

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
Univ. of Tehran
Computer Network
31
Impact of Acknowledgements


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
Univ. of Tehran
Computer Network
32
Impact 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
Univ. of Tehran
Computer Network
33
TCP in Mobile Ad Hoc Networks
Issues (summary)


Route changes due to mobility
Wireless transmission errors


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


problem compounded with multiple hops
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
Univ. of Tehran
Computer Network
34
Impact of MAC - Delay Variability


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
Univ. of Tehran
Computer Network
35
Impact of MAC - Delay
Variability
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
Univ. of Tehran
Computer Network
36
Header Compression for
Wireless 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
Univ. of Tehran
Computer Network
37
Automatic TCP Buffer Tuning



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
Univ. of Tehran
Computer Network
38
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-CTSdata-Ack, more than 70 bytes of overhead
Multipath routing: out of order packet and dupAck.
Network partitioning and remerging
Sliding
size ofComputer
the window
39
Univ. ofWindow:
Tehran
Network
Design goals
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Maximize throughput per connection
Throughput fairness
Minimum connection setup and maintenance overhead.
Mechanisms for congestion and flow controls
Reliable and unreliable connections
Adapt to the dynamics of the network.
Resource, Bandwidth, used efficiently.
Aware of resource, battery, constraints.
End to end semantics
Use information from the lower layer
Well-defined cross-layer interaction for effective and
40
Univ. of Tehran
Computer Network
scalable
protocol
Different 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)

Univ. of Tehran
Computer Network
41
ACTP 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
Univ. of Tehran
Computer Network
42
ATP 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
Univ. of Tehran
Computer Network
43
ATP 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.
Univ. of Tehran
Computer Network
44
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
Univ. of Tehran
Computer Network
45
Issues for Further
Investigation
Univ. of Tehran
Computer Network
46
Link 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
Univ. of Tehran
Computer Network
47
End-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
Univ. of Tehran
Computer Network
 Explicit Notifications may make that easier

48
Impact of Congestion Losses


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
Univ. of Tehran
Computer Network
49
Multiple TCP Transfers

Past work typically measures a single TCP
connection over wireless


When multiple connections share a wireless link,
other performance metrics may make sense



TCP throughput is the metric of choice
fairness
aggregate throughput
Relative performance improvements of various
schemes may change when multiple connections
are considered
Univ. of Tehran
Computer Network
50
TCP Window & RTO Settings
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
Univ. of Tehran
Computer Network
51
TCP for Mobile Ad Hoc
Networks



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
Univ. of Tehran
Computer Network
52