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.

• Optimizations: 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.

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)

• “Uniform” reaction to different losses in TCP: in TCP, reduce congestion window by half upon packet loss does “one-fit-all” work in the wireless scenario ?

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

• Snoop ACK: 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.

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 non-congestion-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