Download Gossip Scheduling - Distributed Protocols Research Group

Gossip Scheduling for Periodic
Streams in Ad-hoc WSNs
Ercan Ucan, Nathanael Thompson, Indranil Gupta
Department of Computer Science
University of Illinois at Urbana-Champaign
Distributed Protocols Research Group: http://dprg.cs.uiuc.edu
Gossip in Ad-hoc WSNs
Useful for broadcast applications:
 Broadcast of queries [TinyDB]
 Routing information spread [HHL06]
 Failure Detection, Topology Discovery and
Membership [LAHS05]
 Code propagation/Sensor reprogramming
[Trickle]
Canonical Gossip



Gossip (or epidemic) = probabilistic
forwarding of broadcasts
[BHOXBY99,DHGIL87]
In sensor networks: forward broadcast to
neighbors with a probability p [HHL06]
Compared to flooding, gossip:



Reliability is high (but probabilistic) if p > 0.7
Saves energy
Has latency that is comparable
Canonical Gossip [HHL06]
GOSSIP (per stream)
1.
p = gossip probability
2.
loop:
3.
for each new message m do
4.
r = random number between 0.0 and 1.0
5.
if (r < p) then
6.
broadcast message m
7.
sleep gossip period
Target Setting
Our target setting
 Multiple broadcast streams, each initiated by a
separate publisher node
 Each stream has a fixed stream period: source
initiates updates/broadcasts periodically
 Different streams can have different period
Canonical gossip doesn’t work!


Treats each stream individually
 Overhead grows as sum of number of streams
First-cut Idea: For periodic streams, combine gossips
Piggybacking

Combine multiple streams into one

Piggybacking: Create gossip message
containing latest updates from multiple
streams
Basically, each node gossips a
“combined” stream
 Generates fewer messages and allows
longer idle/sleep periods

Piggyback Gossip
PIGGYBACK GOSSIP
1.
p = gossip probability
2.
loop:
3.
for each constituent stream s
4.
for each new message m in s do
5.
r = random number between 0.0 and 1.0
6.
if (r < p) then
7.
add m to piggyback gossip message b
8.
broadcast message b
9.
sleep gossip period
Gossip Scheduling
 Basic piggybacking does not work if


Streams have different periods
Network packet payload size is finite
 Solution: create a gossip schedule


Determines which streams are
piggybacked/packed into which gossip messages
Runs asynchronously at each node
Static Scheduling Problem


Solved centrally, and then followed by all nodes
Given a set of periodic streams, satisfy two
requirements:
I. New piggyback message must not exceed maximum
network payload size
II. Maintain reliability, scalability and latency of canonical
gossiping on individual streams
 create groups of streams: k constraint
 for each stream group, send gossip with period =
min(all streams in that group)
 gossip contains latest updates from each stream in
group
Stream Groups: k constraint


Each stream group contains <= k streams
Due to:
1.
Limit on size of network packet payload

2.
Update message sizes from streams



For TinyOS, 28 B
Assume same for all streams
E.g., for 28 B payload and 5 B update message, k=5
k constraint specifies maximum number of
streams in one piggyback gossip
Relatedness Metric
For two streams with similar stream periods,
combining them maximizes the utilization of piggyback

Gossip message
containing Pub3 and Pub4
sent every 6 sec
(k=2)


Relatedness metric among each pair of streams i,j
with periods ti and tj:
R(i,j) = min(ti,tj)/max(ti,tj)
(note that 0 < R(i,j) <= 1.0)
Two streams are related if they have a high R value
Scheduling using Relatedness



In gossip schedule, highly related
streams should be combined
Yet satisfy k-constraint
Express relatedness between streams in
semblance graph
Semblance Graph
Example Stream Workload


Semblance Graph
Each gossip stream is a vertex in complete graph
Edge weights represent relatedness R(i,j) between
streams
Semblance Graph Sub-problem
Formally: partition semblance graph into
groups

Each Group has size no larger than k
Minimize sum of inter-group edge weights



i.e., maximize sum of intra-group edge weights
Greedy construction heuristics: based on
classical minimum spanning tree
algorithms

I.
II.
Prim-like
Kruskal-like
I. Prim-like Algorithm



Scheduled set of groups S = Φ
Initialize S with a single group consisting of
one randomly selected vertex
Iteratively:



Among all edges from S to V-S, select maximum
weight edge e
Suppose e goes from a vertex in group g (in S) to
some vertex v (in V-S)
Bring v into S



If |g| < k, then add v into group g
Otherwise, create new group g’ in S, containing single
vertex v
Time Complexity = O(V2.log(V))
II. Kruskal-like Algorithm



Each node initially in its own group (size=1)
Sort edges in decreasing order of weight
Iteratively consider edges in that order

Try to add edge




May combine two existing groups into one group
May be an edge within an existing group
If adding the edge causes a group to go beyond k,
drop edge
Time complexity: O(E.log(E) + E) = O(V2.log(V))
Comparison of Heuristics

Simulated algorithms on 5000 semblance graphs


Stream periods selected from interval within [0,1] of
size (1-homogeneity)
Kruskal-like better on majority of inputs

For any number of streams, homogeneity (and k)
Network Simulation


Canonical Gossip vs. Piggybacked Gossip
TinyOS simulator
Network size
225 nodes
Publishers
24
k constraint
7
Gossip probability
70%
Evaluation


Total messages sent will decrease
What are the effects on



Energy consumption?
Reliability?
Latency?
Energy Savings


“Flood” = Canonical Gossip
“PgFlood”= Piggybacked Gossip-Scheduled Gossip
Power consumption
based on mote
datasheet
Gossip scheduling
reduces energy
consumption by
40%
Reliability


Reliability reasonable
up to 10% failures,
and then degrades
gracefully
Slightly worse than
canonical gossip due
to update buffering at
nodes
“Flood” = Canonical Gossip
“PgFlood”= Piggybacked Gossip-Scheduled Gossip
Latency


Gossiping scheduling
delays delivery at
some nodes
But it has lower
latency for most
cases, and a lower
median and average
latency

“Flood” = Canonical Gossip
“PgFlood”= Piggybacked Gossip-Scheduled Gossip
Gossip scheduling
pushes some
updates quickly
Conclusion and Open
Directions


Canonical gossip inefficient under multiple publishers
sending out periodic broadcast streams
Use Gossip scheduling to efficiently piggyback
different streams at nodes





satisfies network packet size constraints
retains reliability (compared to canonical gossip)
improves latency
lowers energy consumption
Open directions:


Dynamic version: adding/deleting streams, varying periods
Distributed scheduling
Distributed Protocols Research Group: http://dprg.cs.uiuc.edu