Ad-hoc Networks

Announcements… Preliminary presentations next week By default, I will assume that you have completed the “recommended milestones” I have discussed with you during the project definition

Ad-hoc Networks Infrastructure-less wireless networks dynamically formed using only mobile hosts (no routers) Network topology dynamic as all hosts are mobile! Mobile hosts themselves double up as routers!! Multi-hop paths … Highly resource constrained Extreme case of network mobility…

Applications Military applications Disaster-relief applications Sensor Networks Coverage extensions Capacity, Energy arguments

Illustration A B C D

Protocols … Channel allocation Topology control MAC layer Routing Layer Transport layer

Medium Access Control Requirements: hidden/exposed terminal problems, shared channel, low overheads, wireless errors Most approaches use CSMA/CA based schemes IEEE 802.11 used in most related works Is IEEE 802.11 good for ad-hoc networks? node-fairness vs. flow fairness spatial re-use characteristics multi-hop environment

IEEE 802.11 Unicast transmissions Broadcast transmissions Sender sends RTS to receiver Receiver sends CTS to sender Sender sends DATA to receiver Receiver sends ACK to sender Broadcast transmissions Only carrier sensing

Routing Protocols Proactive approaches Reactive approaches DSDV (destination sequenced distance vector), LSR (link state routing), OLSR (optimized link state routing) Reactive approaches DSR (dynamic source routing), AODV (ad-hoc on-demand distance vector) Hybrid approaches ZRP (zone routing protocol), CEDAR (Core extraction distributed ad-hoc routing)

Proactive routing protocols… Unsuitable for such a dynamic n/w For example, consider link-state routing that sends out network-wide floods for every link-state change … Even in the absence of any existing connections, considerable overhead spent in maintaining “network state”

Goals Low overhead route computation Ability to recover from frequent failures at low-cost Scalable (with respect to mobility and number of hosts) Robust

Reactive (On-demand) protocols Compute routes only when needed Even if network state changes, any re-computation done only when any existing connections are affected Example: Dynamic source routing (DSR) Ad-hoc On-demand Distance Vector (AODV)

Dynamic Source Routing Based on source routing On-demand Route computation performed on a per-connection basis Source, after route computation, appends each packet with a source-route Intermediate hosts forward packet based on source route

DSR – Basic Operation When higher layer gives DSR a packet to transmit, and there exists no route in the route-cache, route computation is performed Source S floods the network with a RREQ (route request) packet for the destination D Every host I that receives the RREQ packet checks to see if I=D. If not, I adds its identifier to the RREQ packet header and forwards the packet

DSR – Basic Operation (contd.) Each forward is a local broadcast (unlike in a wireline network where a flood would entail multiple local transmissions) When D receives packet, the RREQ message contains the list of identifiers it traversed through D responds to the sender S with an RREP (route reply) message containing the route in the RREQ – How?

DSR – RREP propagation If MAC layer assumes bi-directionality (e.g.?), D has to use the same route (reversed) that is being conveyed to S If not, and if network can have asymmetric links (why?), D has to use an explicitly computed route from D to S Infinite loop possible?

DSR (Contd.) When S receives the RREP message, it starts using it from thereon Every packet from S to D has the route in its header Intermediate hosts merely forward based on the source route

DSR – Route Maintenance Consider path S-X-Y-Z-D Let Y-Z link break (why?) Y initiates a route error (RERR) message back to S conveying the link failure When S receives the RERR, it switches to an alternate route (or re-issues another RREQ if none available)

Additional Mechanisms - 1 Caching overheard routes Every host caches routes that it overhears (how?) Such routes are later used if needed Cached routes also used in the next mechanism

Additional Mechanisms - 2 Replying to route requests using cached routes When an intermediate host I receives a route request for D, and has a cached route for D, it replies to the source with the cached route+the route thus far from S-I Reduces route computation latency Provides source with multiple route options Cons?

Additional Mechanisms - 3 Preventing route reply storms Too many route replies can be generated if reply-from-cache is enabled Each node waits for a period t (proportional to the hop-count of cached path) before it replies Reply suppressed if source starts using new route

Additional Mechanisms - 4 Expanding ring search Instead of network wide flood, send RREQ with TTL=1 If no reply, send RREQ with TTL=2, and so on … Reduces route computation overhead Trade-offs?

Additional Mechanisms - 5 Packet salvaging If Y-Z fails in S-X-Y-Z-D, Y sends back RERR Y also tries to salvage packets by using any cached route it might have for D

Additional Mechanisms - 6 Route shortening Consider path S-X-Y-Z-D If Y moves within range of S (and still remains connected to Z & D), Y issues an unsolicited route reply to S conveying shorter route (S-Y-Z-D)

AODV Ad-hoc on-demand distance vector Hop-by-hop routing as opposed to source routing On-demand When RREQ propagates, routing tables updated at intermediate nodes (for route to source of RREQ) When RREP is sent by destination, routing tables updated at intermediate nodes (for route to destination), and propagated back to source Trade-offs?

Comparison Link state Local Low maintenance overhead Low update overhead High access overhead Dynamic networks Local Low maintenance overhead Low access overhead High update overhead Static networks Link state

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

Topology control Given a physical layout of nodes in an ad-hoc network, what is the optimal logical topology? Transmission range adjustment used to change logical topology Most approaches rely on min-power optimality assumption Optimal transmission range depends upon load, density of nodes, # of nodes

Puzzle You have a deck of 52 cards You draw out 5 cards randomly and look at the cards You can now show 4 of the cards to a friend, and the friend should identify the 5th card How do you do this?

Recap Ad-hoc networks MAC layer Routing layer Transport layer Topology control