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

2. 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. 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. 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. 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 Maintain Request Transmit

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

7. 7 Maintain 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 Request Transmit Maintain

8. 8 Request 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 Maintain Transmit Request

9. 9 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 Maintain Request Transmit

10. 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. 11 Properties Epidemic  eventual consistency Strictly local rules No neighbor table management Density-aware Spatial multiplexing Robust to asymmetric links High reliability

12. 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. 13 Simulation Analysis Pipelining improves performance Linear with size Time increases with density

14. 14 Simulation (10x10)

15. 15 Simulation (20x20)

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

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

18. 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. 19 Simulation Analysis (2x76) Pipelining improves performance Linear with size Time decreases with density

20. 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. 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. 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 External Flash Program Image 1

23. 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. 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. 25 The End Questions?

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