1. Ad-hoc Networks

2. Transport Layer UDP? TCP problems:
Wireless losses
Mobility induced losses
Why different from the mobility in the Internet?

3. Transport Layer (Contd.)
Wireless errors: Solutions
Reliable link layer
IEEE inherently has an ACK scheme
Any issues?
Mobility induced losses: Solutions
ELFN: Explicit link failure notification

4. Three broad classes of works
Simple extensions to TCP to enhance TCP performance over ad-hoc networks
Layer integrated approach to enhance TCP performance over ad-hoc networks
New transport protocols for reliable transport over ad-hoc networks

5. TCP - ELFN
Cellular wireless networks – random wireless errors with occasional handoffs
Ad-hoc networks – random wireless errors and mobility related losses equally important
Can TCP be made to recognize losses due to mobility?

6. TCP-ELFN (contd.) Route failure detection?
When upstream node of failed link infers a link failure
Node upstream of failure sends an ELFN (explicit link failure notification) to source
TCP source, when it receives the ELFN, freezes TCP state and enters “probe” mode
When response to probe received, sender de-freezes state and proceeds as normal
Sender does not cut down congestion window due to mobility related losses

7. TCP-ELFN (contd.)
MAC layer (CSMA/CA) recovers from random wireless losses
TCP is notified upon route failures and hence does not react adversely to route failure induced packet losses
Is everything then perfect?

8. Other factors … Losses MAC failure detection time
Failure notification latency
Route computation time

9. Losses
ELFN does not prevent losses from occurring in the network due to route failure
It merely hides the impact of such losses from TCP
Why are losses bad?
Wastage of resources and possible impact on TCP

10. MAC Failure Detection Time (FDT)
A MAC protocol such as has to go through multiple transmissions before it can infer a link failure
Under heavy load conditions, this latency can be of the order of several round-trip times!
TCP would have pumped in an entire window worth of packets before failure is detected
Timeouts possible even before the ELFN reaches the TCP sender

11. Link Failure Notification Latency
In DSR, RERR is sent only to the source whose packet experiences a route failure
What about other sources that are using that link ?
Such sources will have to wait till one of their packets experiences a route failure

12. Route Computation Latency
Once a source is informed of a path failure, a new route needs to be re-computed
Route computation latency can increase with increasing load in the network
For example, in a 100 second simulation with 25 TCP-ELFN connections and 20m/s mobility, each connection spent an average of 15 seconds(!) in route re-computation
Under-utilization and timeouts!

13. Reduce # of Route Failures?
The choice of forward and reverse paths for a TCP connection is left to DSR, which can end up using different paths!
Why is this bad?
Probability of a route failure for the connection increases to 1-(1-p)(h1+h2) where p is the link failure probability, and h1&h2 are the hop-counts of the forward and reverse paths
Solution: perform symmetric route pinning – pin the ACK path to the DATA path

14. Reduce Losses and MAC FDT
Predict link failures in advance?
Solution: Signal strength can be used as an indication of the distance between two nodes
Monitor the progression of signal strengths on a per-packet basis
If the progression indicates an impending link failure, issue a proactive link failure prediction to the source!
Source re-computes route before current route fails

15. Reduce Failure Notification Latency
Maintain a cache of flows currently traversing link
When a link failure is inferred, issue notification to all sources

16. Why NOT to use TCP
What if TCP mechanisms are fundamentally inappropriate for ad-hoc networks?
TCP mechanisms
Window based transmissions
Slow-start
Loss based congestion detection
Linear increase multiplicative decrease
Self-clocking (reliance on ACKs)

17. Why use TCP? Backward compatibility & deployment issues
Are these real problems for ad-hoc networks?
Maybe not!

18. Window Based Transmissions - Burstiness
Why is burstiness bad?
Varying round-trip times and RTO inflation!!
Higher induced load can pose a problem under heavy load conditions

19. Window Based Transmissions (Contd.)

20. Slow Start Exponential growth to available capacity
But, still “slow” – Under-utilization of network resources if connections stay in slow-start for their entire lifetime
Unfairness a problem as in the case of satellite network environments

21. Slow start (contd.)

22. Loss Based Congestion Indication
TCP detects congestion through the occurrence of losses
Losses in ad-hoc networks can occur either due to congestion or due to route failures
Significant portion of losses “perceived” to be due to route failures

23. Loss Based Congestion Indication (contd.)

24. Linear Increase Multiplicative Decrease
TCP performs loss detection through occurrence of losses
Losses can be due to route failures
Is it right to perform LIMD after a route failure?
NO!

25. LIMD (Contd.)

26. Dependence on ACKs
TCP relies on self-clocking for correct progression of its congestion window adaptation
# of ACKs ~ # of DATA packets
Reverse path can induce congestion (if the same path is used) or increase probability of route failures!

27. A Reliable Transport Protocol for Ad-hoc Networks (ATP)
Layer coordination
Rate based transmissions
Decoupling of congestion control and reliability
Assisted congestion control
TCP friendliness & fairness

28. Layer Coordination Similar to ELFN
ATP uses layer coordination for three purposes:
Initial rate feedback for start-up rate estimation
Progressive rate feedback
Path failure notification

29. Rate based transmissions
Avoid drawbacks due to burstiness
Since transmissions are scheduled by timers, the need for self-clocking through arrival of ACKs is eliminated

30. Decoupling of Congestion Control & Reliability
Reliability feedback provided by SACKs from the receiver
Congestion control feedback provided by intermediate nodes (piggybacked on forward path and returned by sender)

31. Assisted Congestion Control
Each node in the network maintains Qt (the average queuing delay), and Tt (the average transmission delay for HOL packet
Every packet is stamped with Qt+Tt
Receiver performs exponential averaging of average delay
Periodically, sender is informed of available rate

32. Other Aspects
“Maintain phase” possible as direct feedback from network available
Quick-start possible as intermediate nodes can stamp their current Qt+Tt value on rate probe
Suffix losses handled by period probes from sender (when it does not receive any feedback from receiver)

33. Some Performance Results

34. Recap Rate based transmissions Loss distinction Fast start
Decoupling of congestion control and reliability
Attempt to stay in a “maintain” phase during cctrl
Less reliance on reverse path characteristics
Layer coordination
Avoid use of retransmission timeouts
Question: A universal wireless/wireline transport layer protocol?

35. Recap
Ad-hoc networks
MAC layer
Routing layer
Transport layer

36. Puzzle
Consider a game played by 2 players. Each player has an infinite number of cigarettes.
There is a circular table.
Each player has to alternately place one cigarette on the table such that it does not touch any of the cigarettes on the table.
Cigarettes can be placed vertically or horizontally.
The first player who fails to do so loses …
Suggest a scheme wherein the first player will always win.