Subject: [Roll] Status change on Trickle I-D (was: Draft ROLL WG minutes posted)

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Jul 2010 08:19:21 +0200

> 5) The Trickle Algorithm - draft-levis-roll-trickle-02  (Phil - 5mn)
>  [160] Quick update on the changes in -02. Currently in LC.
>
> JP> ID is a normative reference in RPL core spec (thus we have a
> downref). Discussion on ID status JP> Will come back to the list to
> consider status change (informational to standard track)

Just a quick note to consider more ways to solve this problem (RPL spec
'downref'erencing a draft it fully relies on):

-move draft-ietf-roll-trickle in the Informative References section.
 This implies making Trickle parameters less mandatory in RPL.
-change the track of the base spec to Informational (this implies
 change to communication to SDO requiring this RP, I suppose).

Also worth mentioning the use of BCP tag on the Trickle draft... Trickle
being common practice in widespread use yet not really a protocol (timer
management).

These may have already been considered,

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 Jul 2010 14:09:44 +0200

Alex:

We need to be very clear that the WG is chartered for Standard Track,
not Informational. So RPL is and will stay on that track.
Moving Trickle to standard track is a good move, highly deserved for a
method that's well understood and proven, and I support it 100%.

Safe trip back,

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Alexandru Petrescu
> Sent: Friday, July 30, 2010 8:19 AM
> To: [email-masked]
> Subject: [Roll] Status change on Trickle I-D (was: Draft ROLL WG
> minutesposted)
> 
change to
> communication to SDO requiring this RP, I suppose).
> 
> Also worth mentioning the use of BCP tag on the Trickle draft...
Trickle being
> common practice in widespread use yet not really a protocol (timer
> management).
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 30 Jul 2010 14:54:48 +0200

Hi,

> method that's well understood and proven, and I support it 100%.

I fully agree with Pascal.

Ulrich

---

From: JP Vasseur <[email-masked]>
Date: Fri, 30 Jul 2010 22:54:30 +0200

> not Informational. So RPL is and will stay on that track.

That's correct.

> method that's well understood and proven, and I support it 100%.

As a WG LC, I do favor to have the trickle ID move to Std track too.

JP.

---

From: David Culler <[email-masked]>
Date: Fri, 30 Jul 2010 16:03:24 -0700

Yes, this change to the references was considered and even discussed at the WG meeting.  

That part that was not discussed was anything about "less mandatory".  Mandatory is a binary property.  Something either IS or IS NOT.  Perhaps you mean "optional". 

There are two fundamental aspects of RPL that make it particularly suited for LLNs.  One is maintaining a small amount of diversity in routing so that transient variations in links (the lossy part) can be accommodated within the normal mode of operation.  The second is eliminating broadcast storms and ack implosion, which are particularly problematic with low bandwidth links (the low power part).  These two techniques have been very widely used in protocols that have been shown to work in practice and at scale.  So at this stage, it is not particularly attractive to start throwing out fundamental aspects of the protocol design because is provides an alternative means of cleaning up the reference section.  

You raised this issue over and over at the microphone in the WG meeting without stating what goal you were trying to achieve by the suggestion.  Are you saying that it is a problem for some reason to propose that the trickle draft be upgraded?  If so, please state what you think that problem is.

If the concern is that some people are not familiar with trickle, well that is the reason for doing the I-D.  While it is well covered in the open literature (the CACM highlight article that Phil Levis cited is an excellent reference) the aspects that you want captured in a I-D are rather more specific.  It is not a matter of the broader algorithmic analyses, it is the specifics of the realization and the trade-offs associated with different specific choices.  

Perhaps you could explain what you see is to be gained by your suggestion?

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 31 Jul 2010 17:04:17 +0200

Le 31/07/2010 01:03, David Culler a écrit :
> That part that was not discussed was anything about "less mandatory".
> Mandatory is a binary property.  Something either IS or IS NOT.
> Perhaps you mean "optional".

I agree, I mean optional.

> There are two fundamental aspects of RPL that make it particularly
> suited for LLNs.  One is maintaining a small amount of diversity in
> routing so that transient variations in links (the lossy part) can be
> accommodated within the normal mode of operation.  The second is
> eliminating broadcast storms and ack implosion, which are
> particularly problematic with low bandwidth links (the low power
> part).  These two techniques have been very widely used in protocols
>  that have been shown to work in practice and at scale.  So at this
> stage, it is not particularly attractive to start throwing out
> fundamental aspects of the protocol design because is provides an
> alternative means of cleaning up the reference section.

Well I mainly agree with the intent to keep these features.

But often broadcast storms are avoided by the link-layer, not IP.  The
multicast concepts of e.g. Ethernet, of 802.15.4, and the exclusive use
of multicast by IPv6 (no broadcast) are there precisely to avoid the
broadcast problems.

Ack implosion - I confess I do not know the problem.  I think DAO ack
messages are optional, probably less of a problem.  But I do not the ack
problem that you mention.

> You raised this issue over and over at the microphone in the WG
> meeting without stating what goal you were trying to achieve by the
> suggestion.

The goal is to identify whether Trickle is mandatory for implementation,
or not.  What would mean INFORMATIONAL, Std Track, BCP - with respect to
Trickle being mandatory to implement RPL, or not.

> Are you saying that it is a problem for some reason to propose that
> the trickle draft be upgraded?  If so, please state what you think
> that problem is.

I don't really see this as a blocking problem, let me explain.

Is Trickle a protocol (in the sense of message diagrams, message
formats)?  If not, it sounds as practice to me, which may indeed good
practice.

Could thus be Best Current Practice.  BCP1 which is RFC1818
describes "BCP" in a sense; BCPs are listed at:
            http://www.rfc-editor.org/bcp-index.html

BCP71 "TCP over 2G"  is such a BCP making me thing Trickle could be a
similar BCP.

In another context: ND, MLD and TCP RFCs there are state machines
specified in the protocol documents; but that text is explicitly saying
one is free to implement otherwise than these state machines.

> If the concern is that some people are not familiar with trickle,
> well that is the reason for doing the I-D.

I personally am familiar to Trickle to mean "Trickle Charger" or the
"Trickle Power Management" of SIRF chipsets.  Wikipedia entries and
publications exist.  These Trickle concepts are very different than the
Trickle I-D.

E.g. it is hard to say "ZigBee devices use trickle for power management
and Trickle for RPL communication protocol".

> While it is well covered in the open literature (the CACM highlight
> article that Phil Levis cited is an excellent reference) the aspects
>  that you want captured in a I-D are rather more specific.

I think "Trickle" appears in the literature also to mean the power
management thing, and is in widespread deployment too.

Alex

> It is not a matter of the broader algorithmic analyses, it is the
> specifics of the realization and the trade-offs associated with
> different specific choices.
>

I think putting Trickle as INFORMATIONAL would read more like one is
free to set the RPL's Trickle parameters otherwise than with the Trickle
I-D.  I think putting it on BCP would also leave this freedom.

I have read BCP 1 (RFC1818) about what "BCP" may mean.

My suggestion is to make clear whether or not one _has_ to implement
Trickle I-D when implementing RPL.

Alex

>>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02  (Phil -
>>> 5mn) [160] Quick update on the changes in -02. Currently in LC.
>>>
>>> JP>  ID is a normative reference in RPL core spec (thus we have
>>> a downref). Discussion on ID status JP>  Will come back to the
>>> list to consider status change (informational to standard track)
>>
>> Just a quick note to consider more ways to solve this problem (RPL
>>  spec 'downref'erencing a draft it fully relies on):
>>
>> -move draft-ietf-roll-trickle in the Informative References
>> section. This implies making Trickle parameters less mandatory in
>> RPL. -change the track of the base spec to Informational (this
>> implies change to communication to SDO requiring this RP, I
>> suppose).
>>
>> Trickle being common practice in widespread use yet not really a
>> protocol (timer management).
>>
>> Alex _______________________________________________ Roll mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 31 Jul 2010 17:05:27 +0200

Le 30/07/2010 22:54, JP Vasseur a écrit :
>> We need to be very clear that the WG is chartered for Standard
>> Track, not Informational. So RPL is and will stay on that track.
>
> That's correct.
>
>> Moving Trickle to standard track is a good move, highly deserved
>> for a method that's well understood and proven, and I support it
>> 100%.
>>
>

Would Trickle Stds Track mean it is mandatory in order to implement RPL?

Alex

>
> JP.
>
>> Safe trip back,
>>
>> Pascal
>>
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf
>> Of
>>> Alexandru Petrescu Sent: Friday, July 30, 2010 8:19 AM To:
>>> [email-masked] Subject: [Roll] Status change on Trickle I-D (was:
>>> Draft ROLL WG minutesposted)
>>>
>> spec
>>> implies
>>> common practice in widespread use yet not really a protocol
>>> (timer management).
>>>
>> _______________________________________________ Roll mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 31 Jul 2010 17:14:37 +0200

> I fully agree with Pascal.

Well yes, I agree too about the first part in Pascal's commen, because
the "ROLL routing protocol specification as PS" is in the Charter - this
makes impossible to switch RPL to INFORMATIONAL.

Yet the Charter does not seem to say something about Trickle I-D...

About the statement saying that Trickle is a method well understood and
proven - it may be so about this Trickle I-D, probably in TinyOS (or
other?); but the "trickle" term generally in LLNs means something
different to me: power management, trickle power charge, trickle
operation of GPS chipset, etc.  It may be only me.

Alex

>>>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02  (Phil
>>>> - 5mn) [160] Quick update on the changes in -02. Currently in
>>>> LC.
>>>>
>>>> JP>  ID is a normative reference in RPL core spec (thus we
>>>> have a downref). Discussion on ID status JP>  Will come back to
>>>> the list to consider status change (informational to standard
>>>> track)
>>>
>>> section. This implies making Trickle parameters less mandatory
>>> in RPL. -change the track of the base spec to Informational
>>> (this implies
>> change to
>>> Alex _______________________________________________ Roll
>>> mailing list [email-masked]

---

From: JP Vasseur <[email-masked]>
Date: Sat, 31 Jul 2010 22:40:31 +0200

> Would Trickle Stds Track mean it is mandatory in order to implement  

If you want Alex I can give you a call and explain the process next  
week.
In a nutshell, Trickle is a normative reference (answer to your  
question is of course "yes")
and RPL is std track according to our charter. Now we can either have  
the trickle ID be an
informative ref in which case we have what we call a downref or simply  
move trickle to
Std track. Feel free to to express your opinion about the trickle ID  
(informational or std track)
as part of WG LC. For the process in general, let me know if you need  
more pointers to
understand the process.

Thanks.

JP.