Subject: Re: [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-00

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Mon, 8 Mar 2010 15:43:08 +0200

Hi,

I have a few minor comments and clarifications WRT this draft.

1) In your abstract and also introduction you state that Trickle is designed
for wireless networks. It is in fact for any low resource networks (can also
be PLC or any other type of low speed/cost/energy network).

Can you clarify about the following two issues (that also appear in my
questions about the RPL):

1) How does Tickle take into consideration that in PLC network the scenario
in which a node can only hear a small subset of nodes that can hear it is
common (due to Tx Load allowing to hear well, but be heard badly or Rx noise
allowing to be heard well but hear badly). Stopping to transmit due to other
nodes transmissions could cause an unresolved inconsistency. I suggest that
it would be possible to disable redundancy counter, or enable to
reset/reduce it if inconsistency is still overheard (persists) even after it
reaches k.

2) How does Tickle take into consideration that an inconsistency can be
immediately detected by many nodes. Aggressive reduction of I to Imin could
cause bursty congestion, especially in PLC where the “blinking node/link”
phenomenon can be timely repetitive (due to power grid usage profile).

Best regards,

Yoav Ben-Yehezkel

Senior Communication Engineer

Yitran Communications LTD.

 [Roll] Fwd: New Version Notification for draft-levis-roll-trickle-00
 ------------------------------

   - *To*: ROLL WG <roll at ietf.org <[email-masked]>>
   - *Subject*: [Roll] Fwd: New Version Notification for
   draft-levis-roll-trickle-00
   - *From*: Philip Levis <pal at cs.stanford.edu <[email-masked]>>
   - *Date*: Thu, 25 Feb 2010 17:20:39 -0800
   - *Delivered-to*: roll at core3.amsl.com <[email-masked]>
   - *List-archive*: <http://www.ietf.org/mail-archive/web/roll>
   - *List-help*:
<mailto:[email-masked]?subject=help<[email-masked]?subject=help>
   - *List-id*: Routing Over Low power and Lossy networks <roll.ietf.org>
   - *List-post*: <mailto:[email-masked] <[email-masked]>>
   - *List-subscribe*: <https://www.ietf.org/mailman/listinfo/roll>, <
   mailto:[email-masked]?subject=subscribe<[email-masked]?subject=subscribe>
   - *List-unsubscribe*: <https://www.ietf.org/mailman/listinfo/roll>, <
   mailto:[email-masked]?subject=unsubscribe<[email-masked]?subject=unsubscribe>
   - *References*: <20100226011704.C9E4D28C140 at
core3.amsl.com<[email-masked]>

 ------------------------------

Thomas and I thought it might make sense to separate Trickle out from the
RPL specification. Here's a first version of the draft:

http://www.ietf.org/internet-drafts/draft-levis-roll-trickle-00.txt

Phil

Begin forwarded message:

 *From: *IETF I-D Submission Tool <idsubmission at
ietf.org<idsubmission%20at%20ietf.org>

*Date: *February 25, 2010 5:17:01 PM PST

*To: *pal at cs.stanford.edu <pal%20at%20cs.stanford.edu>

*Cc: *T.Clausen at computer.org <T.Clausen%20at%20computer.org>

*Subject: **New Version Notification for draft-levis-roll-trickle-00 *

A new version of I-D, draft-levis-roll-trickle-00.txt has been successfuly
submitted by P Levis and posted to the IETF repository.

Filename:            draft-levis-roll-trickle
Revision:              00
Title:                      The Trickle Algorithm
Creation_date: 2010-02-25
WG ID:                  Independent Submission
Number_of_pages: 8

Abstract:
The Trickle algorithm allows wireless nodes to exchange information
in a highly robust, energy efficient, simple, and scalable manner.
Dynamically adjusting transmission windows allows Trickle to spread
new information on the scale of link-layer transmission times while
sending only a few messages per hour when information does not
change.  A simple suppression nechanism and transmission point
selection allows Trickle's communication rate to scale
logarithmically with density.  This document describes Trickle and
considerations in its use.

The IETF Secretariat.

---

From: Phoebus Chen <[email-masked]>
Date: Tue, 09 Mar 2010 09:54:26 +0100

Hi everyone,

I said something in my clarification below that may be misleading for 
the readers of this thread.

In my example, C's rank would be the same whether C chose A or B as a 
preferred parent only if the rank increment is fixed.  If, for example, 
the rank increment depends on the quality of the link between C and its 
preferred parent, then C's rank would depend on whether it chose A or B 
as a preferred parent.

Sorry for the confusion.  I'm looking forward to hearing comments on the 
concerns raised in this thread.

-- 
Phoebus Chen
Postdoctoral Researcher
Automatic Control Lab, KTH (Royal Institute of Technology)
http://www.ee.kth.se/~phoebus

-------- Original Message --------
Subject: Re: [Roll] Fwd: New Version Notification for
draft-levis-roll-trickle-00
Date: Mon, 8 Mar 2010 23:47:31 +0100
From: Phoebus Chen <[email-masked]>
Reply-To: [email-masked] <[email-masked]>
To: Philip Levis <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>, ROLL WG
<[email-masked]>

Sorry, I just realized the last part of my example is bad... see the
correction below.

-- 
Phoebus Chen
Postdoctoral Researcher
Automatic Control Lab, KTH (Royal Institute of Technology)
http://www.ee.kth.se/~phoebus

On 3/8/10 11:27 PM, Phoebus Chen wrote:
> Phil, Omprakash, and Joakim,
>
> Did you find any resolution to Trickle's load balancing problem that
> was discussed in this previous thread?
> http://www.ietf.org/mail-archive/web/roll/current/msg02707.html
>
> This is related to the concern I raised in a previous email
> http://www.ietf.org/mail-archive/web/roll/current/msg02723.html
> regarding how Trickle affects the selection of parents (or how the
> rules on how to defer joining a DODAG may affect Trickle's
> operation, point #2 I made in the email thread).
>
> I am concerned that the redundancy suppression mechanisms in Trickle
> will suppress the DIO advertisements of some of the potential
> parents of a node, and the node will end up choosing a bad parent (or
> bad parents).
>
> Let me illustrate with an example:
> ---------------------------------- Assume that "DIOs that advertise
> the same rank" are considered redundant, as suggested by
> (draft-ietf-roll-rpl-06, pg. 38, Section 5.3.5.1.1).
>
> Nodes A, B, and C are waiting to connect to the DODAG.  Node A
> connects to the DODAG first, starts it's Trickle timer, and
> advertises its DIO, but C misses the message (maybe a fluke, because
> an 802.11 access point happened to go off nearby).  After roughly
> I_min, Node B connects to the DAG (but node A is not a parent),
> starts it's Trickle timer, and advertises the same rank as A.  Node B
> may have deferred joining the DODAG for I_min because it wanted to
> find a better parent.  Now, node B always has a shorter interval I
> than node A, so it should always advertise its DIO before node A
> (since T is always within [I/2,I]).  If the redundancy constant is
> set to 1, then B will always suppress A (until a packet is lost, but
> let's say this is uncommon).
>
> Let's say C needs to connect through the DODAG through B or A.  C
> will choose B since C never hears A's DIO advertisements, and C will
> compute it's rank based on B's rank (B is C's preferred parent).  But
> it may be that A would be a better choice for C, and should be the
> preferred parent for C.

Disregard the last two sentences.  Since A and B has the same rank, C
wouldn't have a problem with it's rank computation, just with it's
choice of parents.  That's what I was concerned with.  If we are using
metrics for consistency checks, and the metric is computed from multiple
parents (rather than the single best parent), this would also be a problem.

> ----------------------------------
>
> This may sound like a contrived example, but my point is that a
> low-chance event such as C missing A's first advertisement could
> result in C not knowing that A is present for a long time... past the
> time that C has to make a decision on how it connects to the DODAG
> (compute and advertise a rank).  I think variants of this example
> with multiple parents could occur and cause the building of very
> suboptimal DODAGs.
>
> The root of the problem is that Trickle was designed for ensuring
> consistency, but is being applied to a situation where nodes are
> actually advertising different values (their rank, their metrics).
> It's tricky to say what should be suppressed.  I'm having a hard
> time imagining using something besides rank or the Objective Function
> metric for measuring consistency.
>
> Could you guys give your thoughts on this?