Subject: [Roll] Some results on reducing control overhead using Trickle's suppression mechanism

From: Omprakash Gnawali <[email-masked]>
Date: Thu, 29 Apr 2010 19:27:17 -0700

I did some experiments to understand how different settings for the
redundancy constant impacts control overhead of CTP. Here are my
notes:

http://stuff.stanford.edu/~om_p/ctp/beaconsuppression.html

- om_p

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 Apr 2010 14:37:20 +0200

Hi Om:

By looking at your result, a value of k=10 strikes out as being the
straight diagonal before the curve reverses.

What's so special with it? Would it be the 'right' value for some
reasons?

Does that value change with the density in your simulation?

Thanks for this great work,

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Omprakash Gnawali
> Sent: Friday, April 30, 2010 4:27 AM
> To: ROLL WG
> Subject: [Roll] Some results on reducing control overhead using
> Trickle'ssuppression mechanism
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Matteo Paris <[email-masked]>
Date: Fri, 30 Apr 2010 11:27:37 -0400

Hi Om, thanks for this work.  I have some questions.

The two graphs seem to use different data sets.  For example, looking 
at the left bar graph for motelab for k = 10, it looks like about 10% 
suppression as compared with k = infinity.  But looking at the CDF 
plot, it looks like 50% suppression for k = 10.  The tutornet data 
does not fit either, and the CDF graph does not indicate whether it 
is Motelab or Tutornet data.  The CDF graph counts "beacons 
suppressed", whereas the bar graph counts "control packets sent". 
Are there control packets that are not beacons?  I would like to see 
both graphs for the same data set.

What is the density of these networks?  Is it uniform?

To get a true picture of the impact of beacon suppression on delivery 
ratios, the experiment must be done on many different networks with 
different densities and topologies.  In particular, networks with 
nonuniform density have a higher risk that beacon suppression will 
partition them.  We can't conclude from only two data points that 
"beacon suppression can be used to reduce control overhead without 
any negative impact on routing performance".

Matteo

---

From: Philip Levis <[email-masked]>
Date: Fri, 30 Apr 2010 08:36:21 -0700

> straight diagonal before the curve reverses.

I'm confused -- it seems to me that 5 is the local minimum, and 3 goes up a bit. What do you mean by "before the curve reverses"?

> Does that value change with the density in your simulation?

These aren't simulations -- they are on two PAN testbeds that are publicly available, and which the CTP developers found especially useful after evaluating the protocol on 12 or so different ones. Tutornet on 802.15.4 channel 26 is a very stable and easy topology.  Motelab is notable because some nodes are only very weakly connected (e.g., have outages for a minute or so). It is therefore useful to evaluate how a protocol behaves when the network is not carefully deployed or engineered. Om -- you should also try tutornet channel 16, to see how a k affects a brutally challenging network.

I would caution us from taking too strong a conclusion into these results, e.g., saying "5 seems to be the magic number." They are two short (1h) experiments in two testbeds. Confounds like time of day play into results on this scale.

Correlated with Jonathan Hui's extensive results on the ARC IP stack, I think this strongly demonstrates that setting k to a small integer (< 10) does not harm datapath performance. Coming up with a strong recommendation on exactly what k should be requires more data and experimentation, though. When we roll out the next 300 powernet[1] nodes (the current 100 have been running CTP for 4 months with heavy instrumentation), maybe we can incorporate a firmware update that allows us to dynamically adjust k. We can then try week-long (or longer) trials with different values and see what happens.

Phil

[1] http://powernet.stanford.edu

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 Apr 2010 18:28:01 +0200

Hi Phil

In the image above, there's a value (close to K=10 in this case) where
the suppression is quasi linear. This looks like a local optimal so it
attracts my curiosity.

I'm wondering what the turn of concavity observed there means for the
operation in that network, and which network properties influence that
value.

Cheers,

Pascal

> From: Philip Levis [mailto:[email-masked]]

> Sent: Friday, April 30, 2010 5:36 PM

> To: Pascal Thubert (pthubert)

> Cc: Omprakash Gnawali; ROLL WG

> Subject: Re: [Roll] Some results on reducing control overhead using

> I'm confused -- it seems to me that 5 is the local minimum, and 3 goes
up a

> bit. What do you mean by "before the curve reverses"?

> These aren't simulations -- they are on two PAN testbeds that are
publicly

> available, and which the CTP developers found especially useful after

> evaluating the protocol on 12 or so different ones. Tutornet on
802.15.4

> channel 26 is a very stable and easy topology.  Motelab is notable
because

> some nodes are only very weakly connected (e.g., have outages for a
minute

> or so). It is therefore useful to evaluate how a protocol behaves when
the

> network is not carefully deployed or engineered. Om -- you should also
try

> tutornet channel 16, to see how a k affects a brutally challenging
network.

> I would caution us from taking too strong a conclusion into these
results, e.g.,

> saying "5 seems to be the magic number." They are two short (1h)

> experiments in two testbeds. Confounds like time of day play into
results on

> this scale.

> Correlated with Jonathan Hui's extensive results on the ARC IP stack,
I think

> this strongly demonstrates that setting k to a small integer (< 10)
does not

> harm datapath performance. Coming up with a strong recommendation on

> exactly what k should be requires more data and experimentation,
though.

> When we roll out the next 300 powernet[1] nodes (the current 100 have

> been running CTP for 4 months with heavy instrumentation), maybe we
can

> incorporate a firmware update that allows us to dynamically adjust k.
We can

> then try week-long (or longer) trials with different values and see
what

> happens.

> [1] http://powernet.stanford.edu <http://powernet.stanford.edu>