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 Whats 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
• Dont want to touch the nodes!

4
Deluge Protocol

• Disseminate program code over a multi-hop sensor
  network
• Problems
• Constrained storage hierarchy
• Packet (32 bytes) ltlt RAM (4K) ltlt program (128K) lt
  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
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
1
2
3
4
N
7
Maintain
Request
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
Transmit
Request
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
Half Request Rate
Original

• Slowing down traffic reduces contention
• But also slows down overall!

Quarter Request Rate
18
Simulation Analysis

• What about starting in the middle?

• Only reduces time by 25
• Doesnt 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
• Dont 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