Comparison between DSR and AODV

DSR Overview AODV Overview Similarity Difference Consequence

DSR Overview
Source routing: routes are stored in a route cache, data packets carry the source route in the packet header Route discovery

Condition: a node sends data to a destination for which it does not know the route Actions: source floods the network with RREQ. Each node receiving RREQ rebroadcasts it unless it is destination or it has the route to the destination in its cache.

Route reply

A destination node or a node knowing the route to the destination in its cache replies with RREP. RREQ and RREP are also source routed. Route carried back by RREP is cached at the source

DSR Overview (II)

Error handling:

If any link on a source route is broken, the source is notified by a RERR packet Source removes any route using this link from its cache A new Route Discovery process must be initiated by the source, if the route is needed. Salvaging: an intermediate node uses an alternative route from its cache, when a data packet meets a failed link on its source route Gratuitous route repair: A source node receiving RERR piggybacks the RERR in the following RREQ, to clean the caches of other nodes that may use the failed link Promiscuous listening: when a node overhears a packet not addressed to itself, it checks whether the packet could be routed via itself to gain a shorter route. If so, sends a gratuitous RREP to the source with the new better route.

Optimizations:

AODV Overview
Discovers routes on an on-demand basis via a similar route discovery process, but uses a different mechanism to maintain routing info. AODV uses routing table, one entry per destination. It relies on routing table entries to propagate a RREP back to the source, and route data packets to the destination. AODV uses sequence # maintained at each destination to determine freshness of routing info. And to prevent routing loops. These sequence # are carried by all routing packets.

AODV Overview (II)

Maintain timer-based states in each node. A routing table entry is expired if not used recently. A set of predecessor nodes is maintained for each routing table entry, indicating neighbors that use the entry to route packets. These nodes are notified with RERR when the next-hop link breaks. Each predecessor node forwards RERR to its predecessors, erasing all routes using the broken link. Optimization:

Expanding ring search: control the RREQ flood in the route discovery process. The search is controlled by the TTL field, increasingly larger neighborhoods are searched to find the destination.

Common features of DSR and AODV

Both discover routes only in the presence of data packets in the need for a route to the destination Route discovery is based on query and rely cycles and route information is stored in all intermediate nodes on the route

Route table entires (AODV), route caches (DSR)

High level difference

DSR uses source routing, but AODV uses a table-driven routing framework and destination sequence # to prevent loops and determine route freshness. DSR does not rely on any timer-based activities, but AODV does. DSR uses routing cache aggressively, and maintains multiple routes per dest. AODV uses one route per destination.

Differences between DSR and AODV (I)

DSR has access to greater amount of routing information than AODV by the virtual of SR. AODV can gather limited information.
DSR: in a single query-reply cycle, source learns route to each intermediate node in the route in addition to the dest. Each intermediate node also learns route to other nodes on the route. Promiscuous listening also helps to learn the route to every node on the route AODV: no source routing or promiscuous listening. It causes AODV to rely on a route discovery flood more often, generating more network overhead

Difference (II)
DSR uses route caching aggressively and replies to all requests reaching a destination from a single request cycle. Source learns many alternative routes to the destination, useful when the primary route fails. This saves overhead due to discovery flood. AODV maintains at most one entry per dest. In the routing table. The destination replies only once to the request arriving first and ignores the rest.

Difference III
DSR does not have explicit mechanism to expire stale routes in the cache (except that some are deleted by RERR) or prefer fresher routes. RERR backtracks the data packet that meets a failed link. Nodes not on the upstream route of this data packet but using the failed link are not notified promptly. AODV is more conservative, the fresher route is always chosen. The route deletion using RERR is also conservative. Using the predecessor list, RERR packets reach all nodes using a failed link on its route to any destination.

Consequence
For application-oriented metris --- delay and throughput, DSR outperforms AODV in less stressful situations (smaller # of nodes and lower load and/or mobility). AODV outperforms DSR in more stress situations (more load, higher mobility)

DSR: Aggressive use of caching, lack of mechanism to expire stale cache

DSR consistently generates less routing load than AODV.

Wireless TCP
Why we study this work
issues for TCP over wireless a sample of proposed solutions comparisons and comments

Issues for Wireless TCP

Different packet loss behavior violates the assumption of TCP that all packet losses are due to congestion control:

congestion-induced loss: new flow joins, etc. channel-error-induced loss: bursty or random channel error handoff-induced packet loss: happens during handoff transition routing-induced packet loss: stale routing tables (in a dynamic ad hoc network) in TCP, reduce congestion window by half upon packet loss does one-fit-all work in the wireless scenario ?

Uniform reaction to different losses in TCP:

Solution Space
Where you are allowed to modify/add the design, what is the information you can get
Scenario 1: no change at any intermediate node (e.g. base station), change is only allowed at both the sender & receiver sides; however, wireless link may provide information regarding whether it is wireless-related loss or not Scenario 2: no change at any intermediate node, no change at the receiver side, only sender side is allowed to be modified; no addition information feedback other than loss

Solution Space (contd)

Scenario 3: Intermediate node is allowed to change, TCP sender & receiver sides should be kept intact as much as possible Scenario 4: you can change anywhere, TCP senders & receivers, as well as intermediate nodes

Solutions
End-to-end protocols

Category 1:
the network or receiver provides additional feedback information on the loss behavior enhance TCP to handle bursty loss using SACK

Category 2:
at the sender side, develop mechanisms differentiating packet loss behaviors, modify TCP congestion control to react accordingly

Split-connection approach

split into two connections: one for wireline part, the other for wireless part since the wireless connection is only one hop, much easier to handle (link layer solution is possible)

Solutions (contd)
Link-layer solution
provide higher layer a logical lossless link, by using link layer techniques for loss recovery: retransmissions, FEC shield TCP from wireless loss as much as possible

End to end schemes: Category 1

Use explicit loss notification or ECN to differentiate loss behaviors

upon ELN, retransmit lost packet, do not invoke congestion control algorithm an alternative scheme: invoke congestion control only upon ECN comments: what about severe wireless loss (indeed the effective channel capacity decreases at the moment), treat it as congestion or non-congestion ?

Use TCP SACK to handle multiple back-to-back loss

Split-Connection Schemes
Split a single end-to-end TCP connection at an intermediate node (typically a base station), maintain two separate TCP connections for wireline links and for wireless links Comments:
duplicate data copying across layers (there are optimization techniques for sure) even if wireless TCP is a single hop, it is still TCP, you still need to modify it to perform properly over the wireless link what do you gain anyway ?

Link-Layer Solutions
Play with different link-layer recovery schemes by recovering loss locally:

ARQ, FEC, channel-swapping, hybrid

suppress DUP_ACKs from TCP to some degree how much you can shield from the standard TCP ?

TCP Snoop for cellular networks

Cache packets at the base station and perform local retransmissions across the wireless link Snoop data packets:

A new packet in the normal TCP sequence: add to the snoop cache, forward to MH Out-of-sequence packet that cached earlier (compare its seq # with latest ACK#): sender timeouts or fast retransmit Out-of-sequence packet that NOT cached: congestion or out-of-order delivery, forwarded to MH and marked as rexmitted by sender A new ACK: flush the cached acked data packets, update RTT estimate, propagate ACK to sender A spurious ACK (seq #< last ACK): discarded DUP ack: (a) if not 1st DUP ack (later dup acks for lost packets), discard; (b) 1st DUP ack, retransmit lost packet with priority.

Snoop ACK:

End-to-end Schemes: Category 2

Goals:

maintain TCP like congestion control mechanism, in particular AIMD principle basic design relies on packet loss indication only able to better adapt if network can provide additional information feedback differentiating different packet loss behaviors: congestion induced loss, channel error induced loss, (capacity) probe loss, etc. tailor rate adaptation to different loss behaviors

Illustration on the expected behavior

End-to-end Schemes: Category 2

Key ideas:

use history of packet loss and congestion profile to distinguish congestion-induced loss from noncongestion-induced loss
maintain moving average & deviation for effective transmission rate check whether the current is within the deviation

reacts gently to non-congestion-induced loss and reacts aggressively to congestion-induced loss, thereby achieving high efficiency, as well as quick response to the onset of congestion
gentle loss: small decrease factor heavy loss: exponential growth for decrease factor

WTCP
End-to-end design Congestion control
Rate-based design Inter-packet delay as the main mechanism for transmission control Distinguish the cause of packet loss and adjust the transmission rate accordingly transmission rate computation at the receiver

Further Comments
We only talk about reliable data delivery here, what about streamed media transport over wireless ? What about multi-hop mobile ad hoc scenarios ?

TCP over Ad-Hoc Mobile Networks

Issues

Mobility induced
Disconnection and reconnection: exponential retransmissions may kill TCP easily Reroute-induced out-of-order delivery: triggers fast retransmit/fast recovery Stale route route: packet loss

Multihop wireless
Hidden terminal: optimal window size Contention induced loss typically happens before congestion loss

Some proposals
Mobility
Explicit link failure notification Freeze window size during disconnection

Multihop wireless
Do not use packet loss as the indication Probing the available bandwidth MAC layer mechanisms TCP tricks