Ad-hoc Storage Overlay System

Transcription

1 Ad-hoc Storage Overlay System (ASOS) David Barbour EECS 800: Survivable Networking Professor James P. G. Sterbenz Presentation based upon paper: Guang Yang, Ling-Jyh Chen, Tony Sun, Biao Zhou, and Mario Gerla. "Ad-hoc Storage Overlay System (ASOS): A Delay-Tolerant Approach in MANETs." Technical Report TR050030, UCLA CSD, 2005.

2 Abstract Designers of the Ado-hoc Storage Overlay System (ASOS) assume that disruptions to mobile ad-hoc networks (MANETs) are unavoidable. ASOS is designed to aid in tolerating disruption. In particular, it attempts to facilitate and make more robust the situation in which local nodes are attempting to send non timecritical data to remote, unaccessible nodes. It does so through probabilistic distribution of messages across local nodes with the storage capacity to aid (so a few destroyed nodes don't eliminate possibly critical data). When the network is connected again, these messages are delivered at the best rate possible.

3 Outline Design Criterion Design and Architecture The Simulations The Results Conclusion Concerns

4 Design Criterion Assumptions: Inevitable Disconnectivity Eventual End-to-End Connectivity Scenario: Sensor Network on mobile nodes Possibly for Military nodes easily destroyed, desired recovery of critical information Apparently designed for nodes that push data.

5 Alternatives to ASOS (Offered) Buffer at local node Re-send when connectivity resumes Pros: Very simple, and is default behavior for E2E Cons: Data loss is probable Small Buffers on weaker nodes Loss of Node is possible (especially in military) (Not Offered) Delay Tolerant Routing e.g. Store-Carry-Forward Note: ASOS only compared against default E2E.

6 Design Principles ASOS takes over when E2E fails. Goals: Robust Storage Available Efficient Friendly Approach: Peer to Peer Overlay Cloud of nodes can store data redundantly. Nodes with abundant storage become ASOS peers

7 ASOS Architecture Advertising Ops HELLO List of stored messages Broadcast on wireless, so others may listen in. ADVERTISE message Aggregation of HELLO data from other nodes. Less detail! (Saves bandwidth) Allows knowledge of multiple hops out.

8 ASOS Architecture Access Ops PULL if a node hears its name advertised. PUSH if an ASOS peer knows a node with data destined for it is nearby.

9 ASOS Design ASOS activates when a routing error (RERR) occurs. Alternatively it is always up. Probabilistic, redundant storage for robustness. Algorithm optimizes to pick a near node, a far node, and nodes with lesser loads. Resists clustered failures.

10 Simulation I Virtual Track: grouped nodes run around a track, and pseudorandomly re-form new groups at special points. (Realistic? No, but it is a standard model!) Connectivity difficult to predict. Rarely have E2E Note: Wireless is ranged across nearby groups. Only used to determine probabilistic selections!

11 Simulation II Simulation of UCLA Campus (1600 m x 1600 m) Random Waypoint Model (0-10 m/s) CBR Traffic: 80 Kbps for 10 seconds per minute per node 30 nodes Single target node (#30) 5 nodes sit still, 5 move individually, 20 are grouped. Runs 10 minutes.

12 Simulation Results I For the first simulation, results were not numerically specified. The algorithm for choosing peers for file distribution was based on node velocity. The following assertions were made as to the results: Algorithm chose nodes close to destination Algorithm favored nodes carrying fewer files Algorithm favored a subset of nodes far away These were the specified, desired results.

13 Simulation Results II Ideal > ASOS > Non-ASOS* Non-ASOS = Talk only while connected E2E

14 Simulation Results II, ctd. Load: No ASOS node was overloaded or starved. Overhead: Total control traffic < 1.6 Kbps. (Much less than data traffic.) Static nodes did worst; grouped mobile did best

15 Conclusions ASOS is a P2P protocol for improving robustness of message storage and delivery when connectivity fails. ASOS aids delivery robustness when large collections of local nodes are available ASOS also aids delivery rate, compared to standard E2E, when continuous connectivity is poor.

16 Concerns Assumes eventual connectivity Memory and Processing overhead not mentioned Never compared to Store-and-Forward or Store-Carry-Forward or any other Delay and Disruption Tolerant protocol Combination with other optimizations? Scalability? Not considered for huge subnets. Noisy Protocol Expensive on power, vulnerable to detection