Trickle: Code Propagation and Maintenance

Trickle: Code Propagation and

Maintenance

Neil PatelUC Berkeley

David CullerUC Berkeley

Scott Shenker

UC BerkeleyICSI

Philip LevisUC Berkeley

NEST Retreat, Jan 2004 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


Propagating Can Be Costly,

• Binaries: 10-60KB• Virtual programs: 20-400B• Parameters: 8-30B• To every node in a large, multihop

network…


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!


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


Relation to Deluge, SPIN, etc.

• When do you advertise code?• How do you suppress control

messages?• Not a dissemination protocol


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


Outline

• Introduction • Trickle algorithm• Maintenance• Propagation• Conclusion


Trickle Assumptions

• Wireless broadcast medium• Concise, comparable metadata

– Given A and B, know which has newer code


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


Trickle Algorithm

• Time interval of length • Redundancy constant k (e.g., 1, 2)• Pick a time t from [0, ]• 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 , pick a new t


Example Trickle Execution

time

2

3

transmission suppressed transmission reception

1

k=1c

0

0

0



t1a

time

2

3


1

k=1c

0

0

0



t1a

time

2

3


1

k=1c

0

1

0



t1a

time

t3a

2

3


1

k=1c

0

1

0



t1a

time

t3a

2

3


1

k=1c

0

2

0



t1a

time

t2a

t3a

2

3


1

k=1c

0

2

0



t1a

time

t2a

t3a

2

3


1

k=1c

0

0

0



t1a

time

t2a t2b

t3a

2

3


1

k=1c

1

0

1



t1a

time

t2a t2b

t3a t3b

2

3


1

k=1c

1

0

1



t1a t1b

time

t2a t2b

t3a t3b

2

3


1

k=1c

1

0

1


Outline

• Problem statement • Trickle algorithm• Maintenance• Propagation• Conclusion


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


Ideal Case

• k transmissions per interval• First k nodes to transmit suppress all

others• Independent of density


Loss

0

2

4

6

8

10

12

1 2 4 8 16 32 64 128 256

Motes

Tra

ns

mis

sio

ns

/In

terv

al

60%

40%

20%

0%


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


Synchronization

0

2

4

6

8

10

12

14

1 2 4 8 16 32 63 128 256

Motes

Tra

ns

mis

sio

ns/

Inte

rval

Not Synchronized

Synchronized


Short Listen Effect

• Some nodes don’t listen much (pick small t values)

• For example, B transmits three times:

ABCD

Time



Solution

• Add a listening period: pick t from [0.5, ]

Listen-only period


Effect of Listen Period

0

2

4

6

8

10

12

14

1 2 4 8 16 32 63 128 256

Motes

Tra

ns

mis

sio

ns/

Inte

rva

l

Not Synchronized

Synchronized

Listening


Multi-Cell Case

• TOSSIM simulation – No synchronization, loss from empirical

model– Nodes uniformly distributed in 50’x50’

area• Logarithmic scaling holds

0

2

4

6

8

10

12

14

16

1 2 4 8 16 32 64 128 256

Motes

Tran

smis

sio

ns/

Inte

rval

Hidden Terminal

No Hidden Terminal


Empirical Validation

Efficiency over Density

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1 2 4 8 16 32 64

Motes

Eff

icie

nc

y

Empirical

Simulated

• Redundancy:• Maté VM implementation

(transmissions + receptions)

intervals- k


Outline

• Problem statement • Trickle algorithm• Maintenance• Propagation• Conclusion


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


Speeding Propagation

• Adjust : l, h

• When expires, double up to h

• When you hear newer metadata, set to l

• When you hear newer code, set to l

• When you hear older metadata, send an update


Rate Change Illustration

h l

2l

hh

Hear Newer Metadata

2

Time


Simulated Propagation

Time

Time To Reprogram, Tau, 10 Foot Spacing (seconds)

18-20

16-18

14-16

12-14

10-12

8-10

6-8

4-6

2-4

0-2

k=1, l=1 second, h=1 minute


Empirical Propagation

• Deployed 19 nodes in office setting• Instrumented nodes for accurate time

measurements• Introduce new code, log installation

times• k=1, l=1 second, h=1 minute• 40 test runs


Network Layout


Empirical Results

Propagation Time Distribution

0.00%

5.00%

10.00%

15.00%

20.00%

25.00%

30.00%

35.00%

0 5 10 15 20 25 30 35 40 45

Time (seconds)

Mo

tes

Time to Complete Propagation

0

10

20

30

40

50

60

70

Tim

e (s

eco

nd

s)


Changing h to 20 minutes

0

10

20

30

40

50

60

70T

ime

(s

ec

on

ds

)

k=1


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 l, h and k needed


Questions

• Tech report available in back



16-18

14-16

12-14

10-12

8-10

6-8

4-6

2-4

0-2


Time


45-50

40-45

35-40

30-35

25-30

20-25

15-20

10-15

5-10

0-5


Time


56-64

48-56

40-48

32-40

24-32

16-24

8-16

0-8

Documents

Trickle: Code Propagation and Maintenance