Ad-hoc Networks

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

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

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

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?

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

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?

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

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

MAC Failure Detection Time (FDT) A MAC protocol such as 802.11 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

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

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!

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

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

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

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)

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

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

Window Based Transmissions (Contd.)

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

Slow start (contd.)

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

Loss Based Congestion Indication (contd.)

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!

LIMD (Contd.)

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!

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

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

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

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)

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

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)

Some Performance Results

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?

Recap Ad-hoc networks MAC layer Routing layer Transport layer

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.