1. Trickle: Code Propagation and Maintenance
Philip Levis
UC Berkeley
Neil Patel
UC Berkeley
David Culler
UC Berkeley
Scott Shenker
UC Berkeley
ICSI

2. Retasking a Sensor Net Long lifetimes require retasking
Spectrum of retasking mechanisms
Binary images (MOAP, XnP, Deluge)
High-level virtual programs (Maté, TinyDB)
Parameter setting (Attribute, Global)
Install on every node
Packet loss and transient disconnection
Periodically check that everyone has the right code (advertise)
TinyDB tuples embed query ID
NEST Retreat, Jan 2004

3. Propagating Can Be Costly,
Binaries: 10-60KB
Virtual programs: B
Parameters: 8-30B
To every node in a large, multihop network…
NEST Retreat, Jan 2004

4. Knowing When Is Costlier
Periodically checking that everyone has the right code (advertisements) can cost more than the code itself.
64KB of data: ~1 packet/minute for a day
400B of data: ~1 packet/hour for a day
20B: one packet!
NEST Retreat, Jan 2004

5. Problem Statement
The first step is to detect when nodes need updates (continuous process)
When there is no new code
Maintenance cost should approach zero
When there is new code
Propagation should be rapid
The long lifetimes of these systems mean that users need a way to reprogram them. However, motes are hard to reach, hard to find and numerous. We therefore need to be able to transmit new code into a deployment over a network. However, the lifetime requirements of these systems enforce strict energy budgets. Although we want new code to propagate rapidly into a network, the cost of maintaining a consistent code image must be very low.
The loss observed in these networks means that simply propagating code once is insufficient. Transient loss that temporarily disconnects a network should not prevent the network from reprogramming when it reconnects.
NEST Retreat, Jan 2004

6. Relation to Deluge, SPIN, etc.
When do you advertise code?
How do you suppress control messages?
Not a dissemination protocol
NEST Retreat, Jan 2004

7. Solution: Trickle Simple, “polite gossip” algorithm
“Every once in a while, broadcast what code you have, unless you’ve heard some other nodes broadcast the same thing.”
Behavior (simulation and deployment):
Scalability: thousand-fold density changes
Maintenance: a few sends per hour
Propagation: less than a minute
NEST Retreat, Jan 2004

8. Outline Introduction Trickle algorithm Maintenance Propagation
Conclusion
NEST Retreat, Jan 2004

9. Trickle Assumptions Wireless broadcast medium
Concise, comparable metadata
Given A and B, know which has newer code
NEST Retreat, Jan 2004

10. Idea: Communication
As long as each mote communicates with one other, needed updates will be detected
In a single cell, one transmission will detect all needed updates
Communication is reception or transmission
Maintain a communication rate:
(receptions + transmissions) <= k
NEST Retreat, Jan 2004

11. Trickle Algorithm Time interval of length t
Redundancy constant k (e.g., 1, 2)
Pick a time t from [0, t]
Maintain a counter c, initialized to zero
At time t, broadcast code metadata if c < k
Increment c when you hear identical metadata to your own
At end of t, pick a new t
NEST Retreat, Jan 2004

12. Example Trickle Execution1 2 3 t
time
transmission
suppressed transmission
reception
NEST Retreat, Jan 2004

13. Example Trickle Execution1
t1a 2 3 t
time
transmission
suppressed transmission
reception
NEST Retreat, Jan 2004

14. Example Trickle Execution1
t1a 2 1 3 t
time
transmission
suppressed transmission
reception
NEST Retreat, Jan 2004

15. Example Trickle Execution1
t1a 2 1 3
t3a t
time
transmission
suppressed transmission
reception
NEST Retreat, Jan 2004

16. Example Trickle Execution1
t1a 2 2 3
t3a t
time
transmission
suppressed transmission
reception
NEST Retreat, Jan 2004

17. Example Trickle Execution1
t1a 2 2
t2a 3
t3a t
time
transmission
suppressed transmission
reception
NEST Retreat, Jan 2004

18. Example Trickle Execution1
t1a 2
t2a 3
t3a t
time
transmission
suppressed transmission
reception
NEST Retreat, Jan 2004

19. Example Trickle Execution1 1
t1a 2
t2a
t2b 3 1
t3a t
time
transmission
suppressed transmission
reception
NEST Retreat, Jan 2004

20. Example Trickle Execution1 1
t1a 2
t2a
t2b 3 1
t3a
t3b t
time
transmission
suppressed transmission
reception
NEST Retreat, Jan 2004

21. Example Trickle Execution1 1
t1a
t1b 2
t2a
t2b 3 1
t3a
t3b t
time
transmission
suppressed transmission
reception
NEST Retreat, Jan 2004

22. Outline Problem statement Trickle algorithm Maintenance Propagation
Conclusion
NEST Retreat, Jan 2004

23. Maintenance
Minimize maintenance cost (transmissions) when there is no new code
Keep as close to k as possible
Start with three assumptions, relax each
Lossless network
Perfect synchronization
Single-hop
NEST Retreat, Jan 2004

24. Ideal Case k transmissions per interval
First k nodes to transmit suppress all others
Independent of density
NEST Retreat, Jan 2004

25. Loss
NEST Retreat, Jan 2004

26. Logarithmic Behavior of Loss
Transmission increase is due to the probability that one node has not heard n transmissions
Example: 10% loss
1 in 10 nodes will not hear one transmission
1 in 100 nodes will not hear two transmissions
1 in 1000 nodes will not hear three, etc.
Fundamental bound to maintaining per-interval communication
NEST Retreat, Jan 2004

27. Synchronization
NEST Retreat, Jan 2004

28. Short Listen Effect Some nodes don’t listen much (pick small t values)
For example, B transmits three times: t A B C D
Time
transmission
suppressed transmission
reception
NEST Retreat, Jan 2004

29. Solution Add a listening period: pick t from [0.5t, t]
Listen-only period
NEST Retreat, Jan 2004

30. Effect of Listen Period
NEST Retreat, Jan 2004

31. Multi-Cell Case TOSSIM simulation Logarithmic scaling holds
No synchronization, loss from empirical model
Nodes uniformly distributed in 50’x50’ area
Logarithmic scaling holds
NEST Retreat, Jan 2004

32. Empirical Validation Redundancy: Maté VM implementation
(transmissions + receptions)
Redundancy:
Maté VM implementation
- k
intervals
NEST Retreat, Jan 2004

33. Outline Problem statement Trickle algorithm Maintenance Propagation
Conclusion
NEST Retreat, Jan 2004

34. Choosing Intervals Large interval: low cost, slow to discover
Small interval: high cost, quick to discover
When there’s new gossip, talk more
When there’s nothing new, talk less
NEST Retreat, Jan 2004

35. Speeding Propagation Adjust t: tl, th
When t expires, double t up to th
When you hear newer metadata, set t to tl
When you hear newer code, set t to tl
When you hear older metadata, send an update
NEST Retreat, Jan 2004

36. Rate Change Illustration
Hear Newer
Metadata
2tl th tl th th 2
Time
NEST Retreat, Jan 2004

37. Simulated Propagation
k=1, tl=1 second, th=1 minute
NEST Retreat, Jan 2004

38. Empirical Propagation
Deployed 19 nodes in office setting
Instrumented nodes for accurate time measurements
Introduce new code, log installation times
k=1, tl=1 second, th=1 minute
40 test runs
NEST Retreat, Jan 2004

39. Network Layout
NEST Retreat, Jan 2004

40. Empirical Results
NEST Retreat, Jan 2004

41. Changing th to 20 minutes
k=1
NEST Retreat, Jan 2004

42. Conclusions Trickle efficiency scales logarithmically with density
Can obtain rapid propagation with low maintenance
At most 3 sends/hour, propagates in 30 seconds
Uses beyond code propagation
Changes to data such as routing tables
E.g., predicates can scope distance
Further examination of tl, th and k needed
NEST Retreat, Jan 2004

43. Questions
Tech report available in back
NEST Retreat, Jan 2004

44. NEST Retreat, Jan 2004

45. NEST Retreat, Jan 2004

46. NEST Retreat, Jan 2004