Subject: [Roll] Some comments on Trickle I-D as response to Trickle LC

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 02 Aug 2010 22:58:38 +0200

Hello,

I respond to the Trickle LC.  Although I missed the LC email.  Hence I
owe you Phil comments :-)

The Trickle I-D I am looking at is
http://tools.ietf.org/html/draft-ietf-roll-trickle-02

The document is short - 11 pages long, that is excellent!

> Trickle sends all messages to the local broadcast address.

In IPv6 no broadcast... so probably a multicast address with link-local
scope would be better appropriated?  Maybe the same used by RPL?  Maybe
the all-nodes multicast address with link scope?

> 1.  When an interval begins, Trickle resets c to 0 and sets t to a
> random point in the interval

I think it would be good to refer to a randomness thought, like when
random is not as random as one would expect - if all nodes use the same
randomness algorithm there may be a risk that all nodes have same 't' at
powerup - risking all transmitters to send simultaneously at time t,
making noise.

It may not have occured in practice though.

> 3.  At time t, Trickle transmits if and only if counter c is less
> than the redundancy constant k.

Advice to set k follows, but it would have been good to see it near here
prior to its use.

> In general, it is much more desirable to set k to a high value (e.g.,
> 5 or 10) than infinity.

Hmmm... sounds as if infinity was not 'high'.

> a specification should say "the default value of Imin is 4 times the
> worst case link layer latency"

But RPL puts Imin as (2^DIOIntervalMin)ms, which is an exponential,
which may lead to very large spaces near the max.

Would the algorithm still work if DIOIntervalMin were 254 and Imin
2^254?  And Imax 2^255, or so.  Probably yes, just a comment.

These are my comments, I hope useful.

Alex

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Tue, 3 Aug 2010 00:15:54 +0300

Hi,

I'd like to support and add to Alex's note on link local broadcast (that
appears in many places in the trickle draft).

To emphasize the problem with this, in RPL trickle timer messages are sent
to All-RPL-Nodes multicast group, which is not a broadcast.

I suggest to clarify this issue.

Thanks,
Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: Monday, August 02, 2010 11:59 PM
To: ROLL WG
Subject: [Roll] Some comments on Trickle I-D as response to Trickle LC

Hello,

Alex

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Mon, 2 Aug 2010 16:01:31 -0700

> I suggest to clarify this issue.

This text came from descriptions where Trickle ran directly on top of a link layer: hence broadcast rather than multicast. 

I agree that "broadcast" is the wrong term to use. I don't think All-RPL-Nodes multicast group is the right answer, though: we don't want to bind Trickle to RPL. I can add some descriptive text on what the destination address should be. In short, it should be a suitable address for the set of link-local nodes that care about the message. This could be the All-RPL-Nodes address, the link local multicast address, a broadcast address (e.g., for IPv4), etc. Do you agree?

Phil

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Tue, 3 Aug 2010 07:26:47 +0300

Thanks Phil,

I wasn't intending to say trickle only works for All-RPL-nodes... I meant
this as an example where trickle is not used for broadcast.

I completely agree with you.

Regards,
Yoav

-----Original Message-----
From: Philip Levis [mailto:[email-masked]]
Sent: Tuesday, August 03, 2010 2:02 AM
To: Yoav Ben-Yehezkel
Cc: Alexandru Petrescu; ROLL WG
Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC

> I suggest to clarify this issue.

This text came from descriptions where Trickle ran directly on top of a
link layer: hence broadcast rather than multicast.

I agree that "broadcast" is the wrong term to use. I don't think
All-RPL-Nodes multicast group is the right answer, though: we don't want
to bind Trickle to RPL. I can add some descriptive text on what the
destination address should be. In short, it should be a suitable address
for the set of link-local nodes that care about the message. This could be
the All-RPL-Nodes address, the link local multicast address, a broadcast
address (e.g., for IPv4), etc. Do you agree?

Phil

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Tue, 3 Aug 2010 08:40:37 +0300

One more thing -

Maybe in your description you should consider also saying that trickle can
also be used by link layers when the destination is broadcast or
multicast. As you've noted trickle is a mechanism that doesn't really have
to be bound to RPL nor to IP.

What do you think?

Regards,
Yoav

-----Original Message-----
From: Yoav Ben-Yehezkel [mailto:[email-masked]]
Sent: Tuesday, August 03, 2010 7:27 AM
To: 'Philip Levis'
Cc: 'Alexandru Petrescu'; 'ROLL WG'
Subject: RE: [Roll] Some comments on Trickle I-D as response to Trickle LC

Thanks Phil,

Regards,
Yoav

-----Original Message-----
From: Philip Levis [mailto:[email-masked]]
Sent: Tuesday, August 03, 2010 2:02 AM
To: Yoav Ben-Yehezkel
Cc: Alexandru Petrescu; ROLL WG
Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Aug 2010 09:28:44 +0200

Le 03/08/2010 01:01, Philip Levis a écrit :
>> I'd like to support and add to Alex's note on link local broadcast
>>  (that appears in many places in the trickle draft).
>>
>> To emphasize the problem with this, in RPL trickle timer messages
>> are sent to All-RPL-Nodes multicast group, which is not a
>> broadcast.
>>
> This text came from descriptions where Trickle ran directly on top of
> a link layer: hence broadcast rather than multicast.
>
> All-RPL-Nodes multicast group is the right answer, though: we don't
> want to bind Trickle to RPL.

Ok, but would one want Trickle to send to all-nodes mcast address and
RPL to send to all-rpl nodes? - they're different addresses.

> I can add some descriptive text on what the destination address
> should be. In short, it should be a suitable address for the set of
> link-local nodes that care about the message.

Sounds reasonable for IPv6 - the nodes interested in the message should
join the group, and with MLD.  I hope RPL says so, otherwise I'll have
to suggest it.

(for all-nodes: the nodes join it by default because they run ND, but
they don't join by default all-rpl if no spec requires them to.)

> This could be the All-RPL-Nodes address, the link local multicast
> address, a broadcast address (e.g., for IPv4), etc. Do you agree?

I am not sure it is a good idea to talk both IPv4 and IPv6 in the same
Trickle draft.

I think it is an unnecessary problem to mention IPv4 in this context,
right now.

Alex

---

From: Philip Levis <[email-masked]>
Date: Tue, 3 Aug 2010 15:34:12 -0700

> to be bound to RPL nor to IP.

I agree 100%. The point is that it's to a set of nearby nodes: how this manifests in terms of addressing greatly depends on what the underlying technologies are. I'll work on some text to try to communicate this fact.

Phil

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 4 Aug 2010 19:08:54 +0200

Phil,

On Tue, Aug 3, 2010 at 1:01 AM, Philip Levis <[email-masked]> wrote:

> All-RPL-Nodes multicast group is the right answer, though: we don't want to
> bind Trickle to RPL. I can add some descriptive text on what the destination
> address should be. In short, it should be a suitable address for the set of
> link-local nodes that care about the message. This could be the
> All-RPL-Nodes address, the link local multicast address, a broadcast address
> (e.g., for IPv4), etc. Do you agree?
>

That sounds reasonable. Would all nodes in the network have to agree (i.e.
by preconfiguration) on the same multicast address? I guess so...

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Aug 2010 21:37:58 +0200

Le 04/08/2010 00:34, Philip Levis a écrit :
>> Maybe in your description you should consider also saying that
>> trickle can also be used by link layers when the destination is
>> broadcast or multicast. As you've noted trickle is a mechanism that
>> doesn't really have to be bound to RPL nor to IP.
>>
>> What do you think?
>
> I agree 100%. The point is that it's to a set of nearby nodes:

One would like to make sure _all_ nearby nodes that author needs to
receive the Trickle message _will_ receive, otherwise I guess Trickle
will fail to maintain consistency, no?

(draft Trickle says:
> 5.  If Trickle hears a transmission that is "inconsistent," the
> Trickle timer resets.
what if a Trickle nodes does not hear a transmission which it would
otherwise qualify as inconsistent.)

("near" is also a hard to define term when we talk IP).

Phil said:
> how this manifests in terms of addressing greatly depends on what the
> underlying technologies are. I'll work on some text to try to
> communicate this fact.

Phil - just to continue on this discussion.

Currently IPv6 isn't specified to run on anything which does not support
link layer multicast.  (exceptions are point-to-point links such as ppp
and or IP-IP or GRE or other IP tunnel interfaces, where the addressing
model is very simple: only two points are hearing each other.)

IPv6 went to a great deal of effort to specify how the link layer
addressing (MAC and such) converts to IPv6 link-local addresses: mapping
functions of rfc2464, rfc4191, and more.  These cases can be enumerated
and implemented, not left to unspecified cases.

Trickle not being a protocol, it is supposed to use one.  If that
protocol is IPv6 (e.g. ND, RPL, DHCP) then it won't work on something
not using link layer multicast.

Trickle running on something else than IP (i.e. Trickle on top of MAC
messages of IEEE.x) is yet another question.  It is possible that
Trickle-straight-over-MAC may work without link-layer multicast.  But
not using IP one may wonder about specifying Trickle StdsTrack, or at
IETF alltogether.

Trickle over the adaptation layer mentioned in 6LoWPAN is probably such
an underlying technology one thinks of running Trickle on.  802.15.4
high data rate does use link-layer multicast.

IPv4 is indeed another question.

Just some thoughts, biased of course :-)

Alex

>
> Phil _______________________________________________ Roll mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: Philip Levis <[email-masked]>
Date: Wed, 4 Aug 2010 15:20:14 -0700

> will fail to maintain consistency, no?

Sort of. You won't reach consistency in a disconnected neighbor, but the reliable delivery of individual messages is not that critical. This is an important consideration, given the lossy nature of wireless.

> Just some thoughts, biased of course :-)

Given that this is the IETF, I think the right thing is to make sure the text is in that content. E.g., link-layer broadcast isn't important to cover. What makes this wording a little complex is the All-RPL-Nodes multicast address.

Phil

---

From: Philip Levis <[email-masked]>
Date: Wed, 4 Aug 2010 17:22:05 -0700

On Aug 4, 2010, at 10:08 AM, Ulrich Herberg wrote:

> 
> That sounds reasonable. Would all nodes in the network have to agree (i.e. by preconfiguration) on the same multicast address? I guess so...

Hm -- I actually think it would be specified by the protocol using Trickle. E.g., some protocols might just use the link-local multicast address, while RPL, say, uses the All-RPL-Nodes local multicast address. It's not inconceivable that a protocol allows this address to be configured, but my feeling is that such a statement belongs outside this particular draft. Does that make sense?

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2010 11:38:40 +0200

Le 05/08/2010 00:20, Philip Levis a écrit :
>>>> broadcast or multicast. As you've noted trickle is a mechanism
>>>> that doesn't really have to be bound to RPL nor to IP.
>>>>
>>>> What do you think?
>>>
>> One would like to make sure _all_ nearby nodes that author needs
>> to receive the Trickle message _will_ receive, otherwise I guess
>> Trickle will fail to maintain consistency, no?
>
> Sort of. You won't reach consistency in a disconnected neighbor, but
>  the reliable delivery of individual messages is not that critical.
> This is an important consideration, given the lossy nature of
> wireless.
>
>
>>
>> (draft Trickle says:
>> what if a Trickle nodes does not hear a transmission which it
>> would otherwise qualify as inconsistent.)
>>
>>> how this manifests in terms of addressing greatly depends on what
>>> the underlying technologies are. I'll work on some text to try to
>>> communicate this fact.
>>
>> Currently IPv6 isn't specified to run on anything which does not
>> support link layer multicast.  (exceptions are point-to-point links
>> such as ppp and or IP-IP or GRE or other IP tunnel interfaces,
>> where the addressing model is very simple: only two points are
>> hearing each other.)
>>
>> addressing (MAC and such) converts to IPv6 link-local addresses:
>> mapping functions of rfc2464, rfc4191, and more.  These cases can
>> be enumerated and implemented, not left to unspecified cases.
>>
>> protocol is IPv6 (e.g. ND, RPL, DHCP) then it won't work on
>> something not using link layer multicast.
>>
>> Trickle running on something else than IP (i.e. Trickle on top of
>> MAC messages of IEEE.x) is yet another question.  It is possible
>> that Trickle-straight-over-MAC may work without link-layer
>> multicast.  But not using IP one may wonder about specifying
>> Trickle StdsTrack, or at IETF alltogether.
>>
>> Trickle over the adaptation layer mentioned in 6LoWPAN is probably
>>  such an underlying technology one thinks of running Trickle on.
>> 802.15.4 high data rate does use link-layer multicast.
>>
> Given that this is the IETF, I think the right thing is to make sure
>  the text is in that content. E.g., link-layer broadcast isn't
> important to cover. What makes this wording a little complex is the
> All-RPL-Nodes multicast address.

Right, how about suggesting text on the list.  I could dare to suggest:

"Trickle is an algorithm.  It is used by an IP protocol (RPL
  [], more) to exchange formatted data related to IP routing; when RPL
  uses Trickle, RPL sends data to all-rpl-routers multicast address;
  when protocolX uses Trickle, protocolX sends data to addressX; a
  protocol undefined yet, contemplating the use of Trickle, could send
  data to an address yet to be defined.".

Or something like this; it is good enough to me, although a bit long. 
Listening to what you think the text should be.

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 5 Aug 2010 13:00:03 +0200

Phil,

On Thu, Aug 5, 2010 at 2:22 AM, Philip Levis <[email-masked]> wrote:

> > That sounds reasonable. Would all nodes in the network have to agree
> (i.e. by preconfiguration) on the same multicast address? I guess so...
>
> Hm -- I actually think it would be specified by the protocol using Trickle.
> E.g., some protocols might just use the link-local multicast address, while
> RPL, say, uses the All-RPL-Nodes local multicast address. It's not
> inconceivable that a protocol allows this address to be configured, but my
> feeling is that such a statement belongs outside this particular draft. Does
> that make sense?
>

Yes, you are right, that makes sense.

Ulrich

---

From: JP Vasseur <[email-masked]>
Date: Tue, 17 Aug 2010 10:22:59 +0200

On Aug 5, 2010, at 2:22 AM, Philip Levis wrote:

>> That sounds reasonable. Would all nodes in the network have to  
>> agree (i.e. by preconfiguration) on the same multicast address? I  
>> guess so...
>
> Hm -- I actually think it would be specified by the protocol using  
> Trickle. E.g., some protocols might just use the link-local  
> multicast address, while RPL, say, uses the All-RPL-Nodes local  
> multicast address. It's not inconceivable that a protocol allows  
> this address to be configured, but my feeling is that such a  
> statement belongs outside this particular draft.

Indeed, it is out of the scope of this document (this is why we have  
it a separate document, not tied to a specific protocol).

> Does that make sense?

---

From: JP Vasseur <[email-masked]>
Date: Tue, 17 Aug 2010 10:26:43 +0200

> data to an address yet to be defined.".

I do not think that we need to say any word about addressing here. As  
you said, Trickle is an
algorithm. We just need to say that it applies to LLNs networks with a  
bit of (obvious) explanations.

>
> Or something like this; it is good enough to me, although a bit  
> long. Listening to what you think the text should be.
>
> Alex
>
>>
>> Phil
>
>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 17 Aug 2010 10:24:40 +0200