Deluge: Data Dissemination for Network Programming at Scale

1. Deluge: Data Dissemination for Network Programming at Scale Jonathan Hui UC Berkeley NEST Retreat June 3, 2004

2. Deluge: What’s new? • A lot has happened in 6 months • Real (and useable) implementation • Reduced RAM consumption by 90% • Density-awareness • Page-level CRCs for data integrity • Multiple image support • Integration with network programming • Large-scale simulation analysis • Real-world testing • Demonstration with real applications • Exploration with use of geometric information

3. Why Network Programming? • Traditional approach • Use a physical link to download binary • Instead, use radio link for code propagation • Embedded nature of sensor networks • Network scales reaching thousands of nodes • A necessity in debugging and testing cycle • Always nice to have the ability to download the binary itself • Don’t want to touch the nodes!

4. Deluge Protocol • Disseminate program code over a multi-hop sensor network • Problems • Constrained storage hierarchy • Packet (32 bytes) << RAM (4K) << program (128K) < external flash (512K) • 100% reliability • Rapid propagation • Propagation must be a continuous effort • Scalability

5. Deluge Overview • Epidemic • State-machine strictly local rules • Nodes advertise, request data, and broadcast • Considers many subtle issues • Density-awareness • Robust to asymmetric links • Dynamic adjustment of advertisements • Minimize set of concurrent data broadcasts • Spatial multiplexing Request Maintain Transmit

6. Each version has a unique version number Program image divided into contiguous pages, each consisting of Npackets. Page structure advantages Reduced RAM requirements for maintaining state of which packets are needed Allows for spatial multiplexing Data Representation Program Image Packets 1 2 3 4 N

7. Request Maintain Maintain Transmit • Advertise • Contains version and fraction of image complete • Nodes request pages in sequential order • Use Trickle • Duplicate suppression • Dynamically adjust advertisement rate • Transition to: • Transmit on receiving a request • Request on receiving an advertisement with newer data (i.e. from a node with a larger fraction of the complete image) • Unless a request or data packet was recently overheard

8. Request Request Maintain Transmit • Transmit a request • Using a random backoff • Suppress if any similar requests are overheard during backoff period • Not receiving a data packet for some time • Minimize senders by unicasting requests to the node that advertised • Transition to Maintain • After receiving all packets of a page • After k requests to protect against asymmetric links

9. Request Transmit Maintain Transmit • Transmit all requested packets • May receive requests when transmitting • C-SCAN schedule to provide fairness • Transition to Maintain when all requested packets are transmitted

10. Other Details • Page level CRCs • Redundant data integrity checks at packet and page level • Multiple image support • Not limited to the dissemination of a single object • Allows multiple programs to exist in the network • Great for debugging! O 1 External Flash

11. Properties • Epidemic  eventual consistency • Strictly local rules • No neighbor table management • Density-aware • Spatial multiplexing • Robust to asymmetric links • High reliability

12. Methodology • Simulation (TOSSIM) • Up to 400 nodes • Empirically derived loss rates • Very pessimistic in interference model • Highly sensitive to simulation parameters, but helps in guiding development • Real world deployment in office building (mica2dots) • Up to 77 nodes • Limited in scale • Not able to see effects shown in simulation

13. Simulation Analysis • Pipelining improves performance • Linear with size • Time increases with density

14. Simulation (10x10)

15. Simulation (20x20)

16. Hidden Terminal Problem Node(2,2) Node(5,5)

17. Slow Down Propagation • Slowing down traffic reduces contention • But also slows down overall! Half Request Rate Original Quarter Request Rate

18. Simulation Analysis • What about starting in the middle? • Only reduces time by 25% • Doesn’t take advantage of the quick edges • Investigation of ways to avoid negative density effects later this session

19. Simulation Analysis (2x76) • Pipelining improves performance • Linear with size • Time decreases with density

20. Empirical Results • 77 mica2dot nodes • ~5 hops • Linear with program size • ~ 4 minutes / 10 KB • Don’t see edge effects • An artifact of simulation? • Downloaded image correct every time

21. Where Does the Time Go? • Nodes can transmit at ~40 packets/sec • Pipelining • Broadcast nature of wireless places fundamental limit of 33% from hypothetical • Selective and delayed retransmission • Implemented in Deluge as suppression mechanisms • Required to avoid congestion collapse • How can we speed it up? • Later in this session • Future Work • Working on establishing a lower bound • Extreme Scaling NEST Demo • Long, linear structures; multiple sources

22. Deluge and Reprogramming • Deluge for propagation • Component to write boot image in correct format • Moves complexity out of bootloader • Portability • NetProg interface for network programming • command NetProg.reboot(uint8_t imgID); • Saves TOS_LOCAL_ADDRESS, TOS_GROUP_ID, imgID, etc. in internal flash Program Image 0 Program Image 1 External Flash

23. Current Status • Requirements • 159 bytes of RAM (with support for 4 images) • 3.5 KB of ROM • Currently in tinyos-1.x/beta/Deluge • Deluge operates on top of GenericComm • Just wire StdControl! • Use start and stop to control Deluge • Some issues: • NetProg.init() should be first (loads TOS_LOCAL_ADDRESS, etc.) • Periodic advertisements • Requires nodes to be always on when downloading • Can have concurrent tasks, but wireless communication performance can be significantly reduced • Integration with various small apps without problems

24. Demo Tonight! • Deluge – Bulk data dissemination • With network programming • Crickets (courtesy of Gilman Tolle) • MintRoute – Many-to-one tree building/routing • Interactive display – Showing progress of download • Drip – Reliable command dissemination • Time synchronization • Auditory feedback  All at the same time!

25. The End • Questions?

26. What We Also Tried • Suppression of control messages is crucial • Suppression of neighboring senders • Reduces contention, but also reduces coverage • More sophisticated sender selection • Did not perform significantly better than choosing node which most recently advertised • Forward error-correction • Best when link qualities are known • What we want are rateless codes