Comparison%20between%20DSR%20and%20AODV

1
Comparison between DSR and AODV

• DSR Overview
• AODV Overview
• Similarity
• Difference
• Consequence

2
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

3
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.

4
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.

5
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.

6
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)

7
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.

8
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

9
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.

10
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.

11
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.

12
Wireless TCP

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

13
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 ?

14
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

15
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

16
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)

17
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

18
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

19
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 ?

20
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 ?

21
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 lt 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.

22
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

23
Illustration on the expected behavior
24
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

25
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

26
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 ?

27
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

28
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