Comparison between DSR and AODV DSR Overview AODV

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 o o 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 o o 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: o o o 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: o o o 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: o 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 o 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 o AODV: no source routing or promiscuous listening. It causes AODV to rely on a route discovery flood more often, generating more network overhead o

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 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) o 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 o a sample of proposed solutions o comparisons and comments o

Issues for Wireless TCP • Different packet loss behavior violates the assumption of TCP that all packet losses are due to congestion control: o o 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: o o 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 o 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 o

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 o Category 1: • the network or receiver provides additional feedback information on the loss behavior • enhance TCP to handle bursty loss using SACK o Category 2: • at the sender side, develop mechanisms differentiating packet loss behaviors, modify TCP congestion control to react accordingly • Split-connection approach o o 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 o shield TCP from wireless loss as much as possible o

End to end schemes: Category 1 • Use explicit loss notification or ECN to differentiate loss behaviors o o o 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) o 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 o what do you gain anyway ? o

Link-Layer Solutions • Play with different link-layer recovery schemes by recovering loss locally: o 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: o o o 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: o o o 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 1 st DUP ack (later dup acks for lost packets), discard; (b) 1 st DUP ack, retransmit lost packet with priority.

End-to-end Schemes: Category 2 • Goals: o o o 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: o 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 o 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 o Inter-packet delay as the main mechanism for transmission control o Distinguish the cause of packet loss and adjust the transmission rate accordingly o transmission rate computation at the receiver o

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 o Mobility induced • Disconnection and reconnection: exponential retransmissions may kill TCP easily • Reroute-induced out-of-order delivery: triggers fast retransmit/fast recovery • Stale route: packet loss o Multihop wireless • Hidden terminal: optimal window size • Contention induced loss typically happens before congestion loss

Some proposals • Mobility Explicit link failure notification o Freeze window size during disconnection o • Multihop wireless Do not use packet loss as the indication o Probing the available bandwidth o MAC layer mechanisms o TCP tricks o