comparison between dsr and aodv dsr overview aodv overview similarity difference consequence
TRANSCRIPT
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
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