Subject: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Sep 2013 15:45:30 -0400

A number of issues were raised this past spring by IESG and other reviewers
on draft-ietf-roll-trickle-mcast.  You can review them using the custom query:

http://trac.tools.ietf.org/wg/roll/trac/query?status=assigned&status=closed&status=new&status=reopened&component=trickle-mcast&group=component&col=id&col=summary&col=component&col=status&col=type&col=priority&col=milestone&order=priority

The chairs, Document Shephard and Document Authors believe that current
issues are closed in the -05 revision at:
       https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/
A diff is available at:
       https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-trickle-mcast-04&difftype=--html&submit=Go%21&url2=draft-ietf-roll-trickle-mcast-05

We are starting another WG Last Call.
It will run until Friday 2013-09-13 at 9am EST.

Please read the document.  Do you concur that it is done?  
Please post any and all comments.  

If there is something you do not like, please provide a suggestion (a diff)
about what to fix.

Thank you.

Michael and JP.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 12 Sep 2013 15:39:14 +0000

I have checked the changes in the draft w.r.t. version -04, and also the open tickets.
In my view version -05 addresses all the open issues well; and I have no further comments. Thanks to the authors and all contributors for their good work!

regards,
Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Wednesday, September 04, 2013 21:46
To: [email-masked]
Subject: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05

A number of issues were raised this past spring by IESG and other reviewers on draft-ietf-roll-trickle-mcast.  You can review them using the custom query:

The chairs, Document Shephard and Document Authors believe that current issues are closed in the -05 revision at:
       https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/
A diff is available at:
       https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-trickle-mcast-04&difftype=--html&submit=Go%21&url2=draft-ietf-roll-trickle-mcast-05

If there is something you do not like, please provide a suggestion (a diff) about what to fix.

Thank you.

Michael and JP.

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Sep 2013 08:10:03 -0400

> Please post any and all comments.

The draft is looking good, but I have a few comments.

Editorial:

- In section 4.3, on Proactive Forwarding, the phrase "MPL Data Message
message"
  is redundant and should be "MPL Data Message".

- In the last paragraph of section 4.3 the phrase "a new MPL Data messages"
  should be "a new MPL Data Message".

- [I-D.droms-6man-multicast-scopes] should be moved from section 14.1 to
14.2.

Technical:

- I have argued that to increase MPL's applicability, PROACTIVE_FORWARDING
  should be a per-interface and not a per-forwarder setting.  I can
imagine, for
  example, a router that has both LLN and traditional interfaces and
proactive
  forwarding seems unnecessary for the latter.  As [RFC 4007] states: "Zone
  boundaries cut through nodes, not links."  Suggested wording in section
5.4
  could be "PROACTIVE_FORWARDING has a default value of TRUE on links
  where Realm-Local scope is defined, and FALSE otherwise."

- Section 4.1 states: "When used with MPL, Realm-Local scope is
administratively
  defined and used to define the boundaries of multicast message
dissemination
  by MPL."  This begs the question, why don't we just use scope = 0x04?  We
  probably need more discussion on if and how a scope 0x03 zone boundary
  is automatically defined (i.e. without human intervention) and how
forwarding
  works for scope 0x03.  One suggested definition is that Realm-Local
applies
  to links where a single interface may belong to multiple Link-Local
scopes.

- The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters
  described in section 5.5 will ultimately have to be expressed in units of
time
  (either in this document or elsewhere) for a given link-layer in order to
avoid
  the "Mismatched min" issues discussed in [RFC 6206, sect. 6.2].  The same
  reference states: "a protocol SHOULD set k and Imin such that Imin is at
least
  two to three times as long as it takes to transmit k packets."

Regards, -K-

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

---

From: Don Sturek <[email-masked]>
Date: Fri, 13 Sep 2013 06:21:00 -0700

I don't agree with the proposed technical changes below, specifically:
1)  "- I have argued that to increase MPL's applicability,
PROACTIVE_FORWARDING
  should be a per-interface and not a per-forwarder setting.  I can imagine,
for
  example, a router that has both LLN and traditional interfaces and
proactive
  forwarding seems unnecessary for the latter.  As [RFC 4007] states: "Zone
  boundaries cut through nodes, not links."  Suggested wording in section
5.4
  could be "PROACTIVE_FORWARDING has a default value of TRUE on links
  where Realm-Local scope is defined, and FALSE otherwise."

    Given how forwarding is defined in the draft, I don't see how the
scenario above is possible unless the links on the "traditional interfaces"
happen to be members of the same MPL Domain as the LLN

2)  "- Section 4.1 states: "When used with MPL, Realm-Local scope is
administratively
scopes."
     
      This argument was made some time ago and rejected.   The purpose in
defining and using a realm scoped address is to allow for automatic
definition.   The forwarding definition in the Trickle Multicast draft is by
MPL Domain so the definition at the end of the paragraph above is not
needed.   When using FF03::FC (defined for forwarding within a MPL Domain)
then all members of the MPL Domain are forwarded a copy of the multicast
transmission.  Section 7.2 especially makes this clear, by interface, by
defining:
   MPLInterfaceSet  - a set of MPL Interfaces that subscribe to the MPL
          Domain Address that identifies the MPL Domain.

3)  - "The DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters

     Since we are using these parameters as defined in RFC 6206 (Trickle
Algorithm) we should not attempt to redefine them here in this draft.

Don

From:  Kerry Lynn <[email-masked]>
Reply-To:  Routing Over Low power and Lossy networks <[email-masked]>
Date:  Friday, September 13, 2013 5:10 AM
To:  Routing Over Low power and Lossy networks <[email-masked]>
Subject:  Re: [Roll] WGLC - Working Group Last Call -
draft-ietf-roll-trickle-mcast-05

On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson <[email-masked]>
wrote:
> http://trac.tools.ietf.org/wg/roll/trac/query?status=assigned&status=closed&st
> atus=new&status=reopened&component=trickle-mcast&group=component&col=id&col=su
> mmary&col=component&col=status&col=type&col=priority&col=milestone&order=prior
> ity
> 
> https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-trickle-mcast-04&difftype=--
> html&submit=Go%21&url2=draft-ietf-roll-trickle-mcast-05
> 
 
Editorial:

Technical:

  should be a per-interface and not a per-forwarder setting.  I can imagine,
for

Regards, -K-

> Michael Richardson <[email-masked] <mailto:[email-masked]> >,
> Sandelman Software Works

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

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Sep 2013 09:58:37 -0400

Hi Don,

> happen to be members of the same MPL Domain as the LLN

I am looking at section 3, Applicability Statement, which says: "This
protocol
may also be used in environments where only a subset of links are considered
Low-Power and Lossy links."  The change I proposed is minimal and would
improve dynamic protocol behavior on non-LLN links.

> definition.

I think I'm just confused about the desire for automatic definition of the
Realm-Local
scope and the several statements in the draft that it's administratively
configured.
Asking as an implementer, how do I determine whether an interface is in a
Realm-
Local zone?  Is it particular to LLN links?

I'm not sure whether the draft is intending to reserve the ability to
configure which
links are in the MPLInterfaceSet.  However it seems that Realm-Local scope,
like
other multicast scopes, must have a consistent definition for any and all
protocols
that use it.

> The forwarding definition in the Trickle Multicast draft is by MPL Domain
> so the definition at the end of the paragraph above is not needed.   When
> using FF03::FC (defined for forwarding within a MPL Domain) then all
> members of the MPL Domain are forwarded a copy of the multicast
>   described in section 5.5 will ultimately have to be expressed in units
> of time
>   (either in this document or elsewhere) for a given link-layer in order
> to avoid

Do the terms "expected link-layer latency" and "worst-case link-layer
latency"
(used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN,
respectively) have commonly defined definitions, e.g. in 802.15.4?  If so,
what are they?  I couldn't seem to determine this from the 802.15.4 spec.

Thanks, -K-

>   described in section 5.5 will ultimately have to be expressed in units
> of time
>   (either in this document or elsewhere) for a given link-layer in order
> to avoid

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Sep 2013 10:03:54 -0400

Don Sturek <[email-masked]> wrote:
    > PROACTIVE_FORWARDING should be a per-interface and not a per-forwarder
    > setting.  I can imagine, for example, a router that has both LLN and

I think that the IETF *functional requirements* question is really:
  Can an implementer make it per-interface without having an impact on
  the implementation in other nodes?

If the answer is, there is no impact, then it really doesn't matter.
Other "ip-forwarding" settings have been described as per-router and
generalized into per-interface many times before.

I have added your comments to ticket #103, which I re-opened.
I will close it again today --- I would appreciate comments in the mailing
list as to whether there is anything to fix here.

    > administratively defined and used to define the boundaries of multicast
    > message dissemination by MPL."  This begs the question, why don't we
    > just use scope = 0x04?  We probably need more discussion on if and how
    > a scope 0x03 zone boundary is automatically defined (i.e. without human
    > intervention) and how forwarding works for scope 0x03.  One suggested
    > definition is that Realm-Local applies to links where a single
    > interface may belong to multiple Link-Local scopes."

I have added your text to ticket #132, and re-opened it.
I would like to close it today.

I think that we are not using scope 4 because we are able to automatically
define the edge.  Can you suggest some text would permit MPL to automatically
define the scope based upon the flood of the prefix found in the DIO PIO?
Is that what you had in mind?

    > not needed.  When using FF03::FC (defined for forwarding within a MPL
    > Domain) then all members of the MPL Domain are forwarded a copy of the
    > multicast transmission.  Section 7.2 especially makes this clear, by
    > interface, by defining:

I think that you haven't answer the question, just swapped "Real-Local scope"
for "MPL Domain"

    > of time (either in this document or elsewhere) for a given link-layer
    > in order to avoid the "Mismatched min" issues discussed in [RFC 6206,
    > sect. 6.2].  The same reference states: "a protocol SHOULD set k and
    > Imin such that Imin is at least two to three times as long as it takes
    > to transmit k packets."

I'm suffering from unclosed quotes here.
I don't see section 5.5 as redefining the parameters at all. It seems
to just re-iterate them.  What is the suggested remedy here?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Don Sturek <[email-masked]>
Date: Fri, 13 Sep 2013 07:45:25 -0700

Hi Kerry,

Two points from below:
1)  "Asking as an implementer, how do I determine whether an interface is in
a Realm-
Local zone?  Is it particular to LLN links?"

       As with other multicast addresses, an interface would register
(opt-in) to a realm.   For Trickle Multicast, it would then depend on
whether the interface has subscribed to the MPL Domain Address.  The
difference between using realm scoped (from Ralph's draft) and
administratively scoped (FF04) is the membership in the MPL Domain can be
managed automatically by actions within the device.

2)  "Do the terms "expected link-layer latency" and "worst-case link-layer
latency"
(used to define DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN,
respectively) have commonly defined definitions, e.g. in 802.15.4?  If so,
what are they?  I couldn't seem to determine this from the 802.15.4 spec."

     The simple answer to this is there is not a prescribed layer 2 latency
value for 802.15.4 other than the defined one hop ACK latency if you use MAC
Acknowledges.  Just FYI, in testing IEEE 802.15.4-2003/2006 (127 byte PDU)
with just 2 devices on a clear channel, we found a typical "one hop/one
packet " message latency to be around 4ms (without security) and around 12
ms (using SW based security).  In my experience, the "expected link layer
latency" and "worst case link layer latency" (speaking strictly about the
link layer only) are just a single aspect to setting IMIN correctly.   The
overall application message pattern plays a larger role for these settings
(for example, how frequently multicasts are generated, how many simultaneous
multicasts can be generated within a given MPL Domain in a window of time
that occurs within IMIN, etc.).  Additionally, another major driver to these
settings are the deployment characteristics of the MPL Domain member devices
(for example. how many incoming message buffers are supported in the member
devices MAC, how many outgoing message buffers, etc.).  Perhaps the names
"expected link layer latency" and "worst case link layer latency" are a bit
misleading since they sound like fixed settings that would be applicable to
all links of a given type when I think they are trying to describe the link
layer performance with a given messaging profile in operation.

Don

Date:  Friday, September 13, 2013 6:58 AM

Hi Don,

On Fri, Sep 13, 2013 at 9:21 AM, Don Sturek <[email-masked]> wrote:
>   example, a router that has both LLN and traditional interfaces and proactive
>   boundaries cut through nodes, not links."  Suggested wording in section 5.4
>     Given how forwarding is defined in the draft, I don't see how the scenario
> above is possible unless the links on the "traditional interfaces" happen to
> be members of the same MPL Domain as the LLN

>   defined and used to define the boundaries of multicast message dissemination
>   works for scope 0x03.  One suggested definition is that Realm-Local applies
>   to links where a single interface may belong to multiple Link-Local scopes."
>      

 
> The forwarding definition in the Trickle Multicast draft is by MPL Domain so
> the definition at the end of the paragraph above is not needed.   When using
> FF03::FC (defined for forwarding within a MPL Domain) then all members of the
> MPL Domain are forwarded a copy of the multicast transmission.  Section 7.2
> especially makes this clear, by interface, by defining:

Thanks, -K-
 
>> http://trac.tools.ietf.org/wg/roll/trac/query?status=assigned&status=closed&s
>> tatus=new&status=reopened&component=trickle-mcast&group=component&col=id&col=
>> summary&col=component&col=status&col=type&col=priority&col=milestone&order=pr
>> iority
>> 
>> https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-trickle-mcast-04&difftype=-
>> -html&submit=Go%21&url2=draft-ietf-roll-trickle-mcast-05
>> 
> - [I-D.droms-6man-multicast-scopes] should be moved from section 14.1 to 14.2.
> 
> 
> Technical:
> 
>   example, a router that has both LLN and traditional interfaces and proactive
>   boundaries cut through nodes, not links."  Suggested wording in section 5.4
>   defined and used to define the boundaries of multicast message dissemination
>   works for scope 0x03.  One suggested definition is that Realm-Local applies
>   to links where a single interface may belong to multiple Link-Local scopes.
> 
> [email-masked]://www.ietf.org/mailman/listinfo/roll
>

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Sep 2013 13:02:03 -0400

Hi Michael,

On Fri, Sep 13, 2013 at 10:03 AM, Michael Richardson
<[email-masked]>wrote:

> Experience shows that tuning parameters are not always exposed by a
given implementation and even when they are, they are most likely left
at their default value.

My concern is that the suggested default for this parameter may lead to
suboptimal behavior on non-LLN links (by ensuring straight flooding for
some number of intervals).

Even if there is "room for interpretation" on considering this a
per-interface
parameter, the correct default needs to be specified in this draft or else a
BCP or something will be necessary.

It would be good to hear Jonathan's opinion...

> Let me try to be more clear.  Perhaps I'm reading too literally, but there
seems
to be a conflict between the "administratively configured" language of this
draft
and the "automatically configured" language of Ralph's draft.  I'd just
like to
remove the contradiction (if indeed there is one).

A link-local zone boundary, for example, occurs at the router because of
the way
forwarding rules are defined in [RFC 4291, sect. 2.5.6]. If we have similar
clarity
around defining the boundary of a realm-local zone, then it seems to me the
"administratively defined" language can be removed from MPL as it relates to
realm-scope.

> That was Don's comment to my comment.

> I'm suffering from unclosed quotes here.

The first one is spurious.

> [RFC 6206, sect. 5] says "the default value of Imin SHOULD be specified in
terms
of the worst-case latency of a link-layer transmission."  I'm simply asking
where
one goes to find, e.g., the worst-case link-layer latency of 802.15.4.
Perhaps the
remedy is to include this value in Applicability Statements as has been
agreed for
hop limit values.  I think it's important that all forwarders in a MPL
Domain agree
on this value but I was wrong in my earlier comment about the reason.  It's
not
RFC 6206, sect. 6.2] that applies, but [RFC 6206, sect. 6.3] (since Imax is
equal
to Imin).

Regards, -K-

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Sep 2013 13:56:28 -0400

Don, thanks for your additional comments...

On Fri, Sep 13, 2013 at 10:45 AM, Don Sturek <[email-masked]> wrote:

> Hi Kerry,
>
> Two points from below:
> 1)  "Asking as an implementer, how do I determine whether an interface is
> in a Realm-
> I'm willing to accept that I may be the only one who's confused.  Let me
illustrate
with an example:

(A)-BR1---BR2-(B)

Let's say we have two LLNs, A and B, connected by BRs and a traditional link
like WiFi or ethernet.  Further, there are MPL forwarders deployed in both A
and B.  (I'd imagine that the LLN interfaces on the BRs are MPL forwarders.)
Are there two separate realm-local zones?  If that is the case then it seems
there should be some intrinsic property that allows a router to determine
if a
link is in the scope zone or not.  For example, if we were talking about
link-
local scope zones and the example about consisted of traditional links and
routers, then the scope boundaries would be defined as cutting through the
routers and would be the same for all link-local multicast protocols.  That
is,
there would be no inter-connectivity between a node in A and a node in B
that
were subscribed to the same multicast group.

I'm mainly interested in resolving the apparent contradiction between the
"administratively configured" language in the MPL draft and the
"automatically
configured" language in Ralph's draft (and in your comment).

>      The simple answer to this is there is not a prescribed layer 2
> latency value for 802.15.4 other than the defined one hop ACK latency if
> you use MAC Acknowledges.  Just FYI, in testing IEEE 802.15.4-2003/2006
> (127 byte PDU) with just 2 devices on a clear channel, we found a
> typical "one hop/one packet " message latency to be around 4ms (without
> security) and around 12 ms (using SW based security).  In my experience,
> the "expected link layer latency" and "worst case link layer latency"
> (speaking strictly about the link layer only) are just a single aspect to
> setting IMIN correctly.   The overall application message pattern plays a
> larger role for these settings (for example, how frequently multicasts are
> generated, how many simultaneous multicasts can be generated within a given
> MPL Domain in a window of time that occurs within IMIN, etc.).
>  Additionally, another major driver to these settings are the deployment
> characteristics of the MPL Domain member devices (for example. how many
> incoming message buffers are supported in the member devices MAC, how many
> outgoing message buffers, etc.).  Perhaps the names "expected link layer
> latency" and "worst case link layer latency" are a bit misleading since
> they sound like fixed settings that would be applicable to all links of a
> given type when I think they are trying to describe the link layer
> performance with a given messaging profile in operation.
>
> Do you agree that all nodes in a given LLN SHOULD agree on a common
value for Imin?  I don't have any problem with declaring it out of scope for
the present draft, but practically speaking it seems there should be a way
to
a) define a reasonable default for a given link layer, and b) distribute a
modified
value (I think Yusuke Doi is working on a DHCPv6 option for MPL parameters).

Regards, -K-

> links are in the MPLInterfaceSet.  However it seems that Realm-Local
> scope, like
>>   reference states: "a protocol SHOULD set k and Imin such that Imin is
>> at least
>> On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson <[email-masked]
>> > wrote:
>>
>>>
>>   reference states: "a protocol SHOULD set k and Imin such that Imin is
>> at least

---

From: Don Sturek <[email-masked]>
Date: Fri, 13 Sep 2013 11:58:32 -0700

HI Kerry,

So again, two points to comment onŠ..:
1)  "(A)-BR1---BR2-(B)

Let's say we have two LLNs, A and B, connected by BRs and a traditional link
like WiFi or ethernetŠŠ."

      In general it is possible to have the "traditional link" between BR1
and BR2 to support ROLL RPL and therefore include the "traditional link"
interfaces as part of the MPL Domain.   I believe this would depend on the
routing scope declared in BR1 and BR2 for those interfaces.
      Most of the deployments I have seen would have (A) and (B) in
different MPL Domain realms.  This would solely be defined in BR1 and BR2 as
to which interfaces they include to support RPL routing.

2)  "Do you agree that all nodes in a given LLN SHOULD agree on a common
value for Imin? ŠŠ  "

      I believe it is requirement that all devices in a given MPL Domain
MUST agree on a common value for IMIN, IMAX and k.  In terms of a default,
we can certainly create such values applicable to given deployment topology
and an assumed messaging profile but I really think some work should go into
an applicability statement that would provide additional guidance on how to
tune these values.  I think I mentioned this before but we did (in ZigBee
IP) create a 30 node, 3 hop network supporting a ROLL RPL instance,
instrumented all devices, created a single multicast message and measured
how many devices in the network saw at least a single copy of the
transmission using various settings for IMIN, IMAX and k.  A process similar
to this (with knowledge of the topology and messaging profile) is needed for
tuning these values in a real deployment setting.

Don

Date:  Friday, September 13, 2013 10:56 AM

On Fri, Sep 13, 2013 at 10:45 AM, Don Sturek <[email-masked]> wrote:
> Hi Kerry,
> 
> Two points from below:
> 1)  "Asking as an implementer, how do I determine whether an interface is in a
> Realm-
>        As with other multicast addresses, an interface would register (opt-in)
> to a realm.   For Trickle Multicast, it would then depend on whether the
> interface has subscribed to the MPL Domain Address.  The difference between
> using realm scoped (from Ralph's draft) and administratively scoped (FF04) is
> the membership in the MPL Domain can be managed automatically by actions
> within the device.
> 

(A)-BR1---BR2-(B)

there should be some intrinsic property that allows a router to determine if
a

> with just 2 devices on a clear channel, we found a typical "one hop/one packet
> " message latency to be around 4ms (without security) and around 12 ms (using
> SW based security).  In my experience, the "expected link layer latency" and
> "worst case link layer latency" (speaking strictly about the link layer only)
> are just a single aspect to setting IMIN correctly.   The overall application
> message pattern plays a larger role for these settings (for example, how
> frequently multicasts are generated, how many simultaneous multicasts can be
> generated within a given MPL Domain in a window of time that occurs within
> IMIN, etc.).  Additionally, another major driver to these settings are the
> deployment characteristics of the MPL Domain member devices (for example. how
> many incoming message buffers are supported in the member devices MAC, how
> many outgoing message buffers, etc.).  Perhaps the names "expected link layer
> latency" and "worst case link layer latency" are a bit misleading since they
> sound like fixed settings that would be applicable to all links of a given
> type when I think they are trying to describe the link layer performance with
> a given messaging profile in operation.
> 

Regards, -K-
 
> I am looking at section 3, Applicability Statement, which says: "This protocol
> Do the terms "expected link-layer latency" and "worst-case link-layer latency"
>>> http://trac.tools.ietf.org/wg/roll/trac/query?status=assigned&status=closed&
>>> status=new&status=reopened&component=trickle-mcast&group=component&col=id&co
>>> l=summary&col=component&col=status&col=type&col=priority&col=milestone&order
>>> =priority
>>> 
>>> https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-trickle-mcast-04&difftype=
>>> --html&submit=Go%21&url2=draft-ietf-roll-trickle-mcast-05
>>> 
>>> Michael Richardson <[email-masked] <mailto:[email-masked]>
>>> >, Sandelman Software Works

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Sep 2013 16:10:53 -0400

On Fri, Sep 13, 2013 at 2:58 PM, Don Sturek <[email-masked]> wrote:

> HI Kerry,
>
> So again, two points to comment on…..:
> 1)  "(A)-BR1---BR2-(B)
>
> like WiFi or ethernet……."
>
> different MPL Domain realms.  This would solely be defined in BR1 and BR2
> as to which interfaces they include to support RPL routing.
>
> value for Imin? ……  "
> and an assumed messaging profile but I really think some work should go
> into an applicability statement that would provide additional guidance on
> how to tune these values.  I think I mentioned this before but we did (in
> ZigBee IP) create a 30 node, 3 hop network supporting a ROLL RPL instance,
> transmission using various settings for IMIN, IMAX and k.  A process
> similar to this (with knowledge of the topology and messaging profile) is
> needed for tuning these values in a real deployment setting.
>
>
ACK.  Thanks for your explanations.

-K-

> routers and would be the same for all link-local multicast protocols.
> That is,
>>>       This argument was made some time ago and rejected.   The purpose
>>> in defining and using a realm scoped address is to allow for automatic
>>> definition.
>>>
>>
>> I think I'm just confused about the desire for automatic definition of
>> the Realm-Local
>>> The forwarding definition in the Trickle Multicast draft is by MPL
>>> Domain so the definition at the end of the paragraph above is not needed.
>>> When using FF03::FC (defined for forwarding within a MPL Domain) then all
>>> On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson <
>>> [email-masked]> wrote:
>>>
>>>>

---

From: peter van der Stok <[email-masked]>
Date: Mon, 16 Sep 2013 10:11:19 +0200

Hi all,

I should like to comment on the point below.

> 
> 2) "Do you agree that all nodes in a given LLN SHOULD agree on a
> commonvalue for Imin? …… "
> 
> MUST agree on a common value for IMIN, IMAX and k. In terms of a
> default, we can certainly create such values applicable to given
> deployment topology and an assumed messaging profile but I really
> think some work should go into an applicability statement that would
> provide additional guidance on how to tune these values. I think I
> mentioned this before but we did (in ZigBee IP) create a 30 node, 3
> hop network supporting a ROLL RPL instance, instrumented all devices,
> created a single multicast message and measured how many devices in
> the network saw at least a single copy of the transmission using
> various settings for IMIN, IMAX and k. A process similar to this (with
> knowledge of the topology and messaging profile) is needed for tuning
> these values in a real deployment setting.

After looking for an appropriate setting for Imin, Imax and k, I slowly 
learnt that these settings depend on the topology of the network, the 
load of the network, the setting of the MAC, and eventual real-time 
requirements (e.g. there is a deadline), and the value of that deadline.
The setting of k for example is related to the number of MPL repeaters 
that receive a new message and start to resend it, possibly interfering 
with each other and probably incrementing the c value of the next hop, 
where the maximum value of c is related to the Imin value.
Sending a packet takes as little as 3 ms, but when the MAC stores three 
packets and the they all back-off a maximum number of times, delays of a 
few hundred milliseconds to seconds become possible.
When there is buffer space for packets before and in the MAC, the Imin 
value can be chosen as low as 1 ms, the resend of packets is then 
completely determined by the load on the network.

And there are many more conditions and mutual dependencies.

So, I suggest to leave the default values mentioned in the draft as they 
are, and leave the tuning of the parameters to the people who deploy and 
have experience with a certain class of networks. The applicability 
statement can give configuration examples and suggest some best practice 
values.
I think an analysis of a set of configurations with temporal objectives 
and network load is too much text for the applicability statement, and 
is best referred to from the applicability statement.

Peter

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Sep 2013 10:59:14 -0400

Kerry Lynn <[email-masked]> wrote:
    don>>           I believe it is requirement that all devices in a given
    don>> MPL Domain MUST agree on a common value for IMIN, IMAX and k.  In
    don>> terms of a default, we can certainly create such values applicable
    don>> to given deployment topology and an assumed messaging profile but I
    don>> really think some work should go into an applicability statement
    don>> that would provide additional guidance on how to tune these
    don>> values.  I think I mentioned this before but we did (in ZigBee IP)
    don>> create a 30 node, 3 hop network supporting a ROLL RPL instance,
    don>> instrumented all devices, created a single multicast message and
    don>> measured how many devices in the network saw at least a single copy
    don>> of the transmission using various settings for IMIN, IMAX and k.  A
    don>> process similar to this (with knowledge of the topology and
    don>> messaging profile) is needed for tuning these values in a real
    don>> deployment setting.

    Kerry> ACK.  Thanks for your explanations.

With this, are your questions resolved, or are there further text changes
requested?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Sep 2013 11:15:48 -0400

>> these values in a real deployment setting.

    peter> After looking for an appropriate setting for Imin, Imax and k, I
    peter> slowly learnt that these settings depend on the topology of the
    peter> network, the load of the network, the setting of the MAC, and
    peter> eventual real-time requirements (e.g. there is a deadline), and
    peter> the value of that deadline.  The setting of k for example is
    peter> related to the number of MPL repeaters that receive a new message
    peter> and start to resend it, possibly interfering with each other and
    peter> probably incrementing the c value of the next hop, where the
    peter> maximum value of c is related to the Imin value.  Sending a packet
    peter> takes as little as 3 ms, but when the MAC stores three packets and
    peter> the they all back-off a maximum number of times, delays of a few
    peter> hundred milliseconds to seconds become possible.  When there is
    peter> buffer space for packets before and in the MAC, the Imin value can
    peter> be chosen as low as 1 ms, the resend of packets is then completely
    peter> determined by the load on the network.

This is an excellent template discussion... can I put it into the MPL
parameter part of the RPL applicability template?

Do you think you could rephrase this in the form of questions to be
answered?

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 16 Sep 2013 12:24:39 -0400

Hi Michael,

Do you have time for a brief chat today?
978-440-8508.

Thanks, -K-

---

From: <[email-masked]>
Date: Tue, 17 Sep 2013 01:06:12 +0000

FYI, draft-doi-roll-mpl-parameter-configuration describes an automated way to set a common value for IMIN, IMAX and k using DHCP.

Yoshihiro Ohba

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Monday, September 16, 2013 11:59 PM
To: Routing Over Low power and Lossy networks
Subject: Re: [Roll] WGLC - Working Group Last Call - draft-ietf-roll-trickle-mcast-05

With this, are your questions resolved, or are there further text changes requested?

---

From: Robert Cragie <[email-masked]>
Date: Tue, 17 Sep 2013 10:25:35 +0100

Just to weigh in with my views:

On (1):

I see no inconsistency with using scope 3 and the text written in 
draft-ietf-roll-trickle-mcast-05 and 
draft-droms-6man-multicast-scopes-02. "Automatically configured" can 
simply mean defined or implied by the network topology. Basing the MPL 
Domain multicast scope on the scope of the DAG prefix based on the 
configuration of the participating router seems like a good idea and 
example of automatically implied scope. Deployment of MPL in alternative 
network topologies can imply a similar scope. An example could be given 
in draft-ietf-roll-trickle-mcast-05 but I don't think it is necessary.

On (2):

I agree that all nodes in a MPL Domain MUST agree on a common value. I 
don't think any recommended values should be given and it depends on the 
applicability.

In a nutshell - I think draft-ietf-roll-trickle-mcast-05 is good to go.

Robert

On 13/09/2013 21:10, Kerry Lynn wrote:
> On Fri, Sep 13, 2013 at 2:58 PM, Don Sturek <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     HI Kerry,
>
>     So again, two points to comment on.....:
>     1)  "(A)-BR1---BR2-(B)
>
>     like WiFi or ethernet......."
>
>           In general it is possible to have the "traditional link"
>     between BR1 and BR2 to support ROLL RPL and therefore include the
>     "traditional link" interfaces as part of the MPL Domain.   I
>     believe this would depend on the routing scope declared in BR1 and
>     BR2 for those interfaces.
>           Most of the deployments I have seen would have (A) and (B)
>     in different MPL Domain realms.  This would solely be defined in
>     BR1 and BR2 as to which interfaces they include to support RPL
>     routing.
>
>     common
>     value for Imin? ......  "
>           I believe it is requirement that all devices in a given MPL
>     Domain MUST agree on a common value for IMIN, IMAX and k.  In
>     terms of a default, we can certainly create such values applicable
>     to given deployment topology and an assumed messaging profile but
>     I really think some work should go into an applicability statement
>     that would provide additional guidance on how to tune these
>     values.  I think I mentioned this before but we did (in ZigBee IP)
>     create a 30 node, 3 hop network supporting a ROLL RPL instance,
>     instrumented all devices, created a single multicast message and
>     measured how many devices in the network saw at least a single
>     copy of the transmission using various settings for IMIN, IMAX and
>     k.  A process similar to this (with knowledge of the topology and
>     messaging profile) is needed for tuning these values in a real
>     deployment setting.
>
>
>     From: Kerry Lynn <[email-masked] <mailto:[email-masked]>>
>     Reply-To: Routing Over Low power and Lossy networks <[email-masked]
>     <mailto:[email-masked]>>
>     To: Routing Over Low power and Lossy networks <[email-masked]
>     <mailto:[email-masked]>>
>     On Fri, Sep 13, 2013 at 10:45 AM, Don Sturek <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi Kerry,
>
>         Two points from below:
>         1)  "Asking as an implementer, how do I determine whether an
>         interface is in a Realm-
>                As with other multicast addresses, an interface would
>         register (opt-in) to a realm. For Trickle Multicast, it would
>         then depend on whether the interface has subscribed to the MPL
>         Domain Address.  The difference between using realm scoped
>         (from Ralph's draft) and administratively scoped (FF04) is the
>         membership in the MPL Domain can be managed automatically by
>         actions within the device.
>
>     I'm willing to accept that I may be the only one who's confused. 
>     Let me illustrate
>     with an example:
>
>     (A)-BR1---BR2-(B)
>
>     there should be some intrinsic property that allows a router to
>     determine if a
>     link is in the scope zone or not. For example, if we were talking
>     about link-
>     routers and would be the same for all link-local multicast
>     protocols.  That is,
>     there would be no inter-connectivity between a node in A and a
>     node in B that
>         2)  "Do the terms "expected link-layer latency" and
>         "worst-case link-layer latency"
>              The simple answer to this is there is not a prescribed
>         layer 2 latency value for 802.15.4 other than the defined one
>         hop ACK latency if you use MAC Acknowledges.  Just FYI, in
>         testing IEEE 802.15.4-2003/2006 (127 byte PDU) with just 2
>         devices on a clear channel, we found a typical "one hop/one
>         packet " message latency to be around 4ms (without security)
>         and around 12 ms (using SW based security).  In my experience,
>         the "expected link layer latency" and "worst case link layer
>         latency" (speaking strictly about the link layer only) are
>         just a single aspect to setting IMIN correctly.   The overall
>         application message pattern plays a larger role for these
>         settings (for example, how frequently multicasts are
>         generated, how many simultaneous multicasts can be generated
>         within a given MPL Domain in a window of time that occurs
>         within IMIN, etc.).  Additionally, another major driver to
>         these settings are the deployment characteristics of the MPL
>         Domain member devices (for example. how many incoming message
>         buffers are supported in the member devices MAC, how many
>         outgoing message buffers, etc.).  Perhaps the names "expected
>         link layer latency" and "worst case link layer latency" are a
>         bit misleading since they sound like fixed settings that would
>         be applicable to all links of a given type when I think they
>         are trying to describe the link layer performance with a given
>         messaging profile in operation.
>
>     the present draft, but practically speaking it seems there should
>     be a way to
>     a) define a reasonable default for a given link layer, and b)
>     distribute a modified

>     Regards, -K-
>
>         Don
>
>
>         From: Kerry Lynn <[email-masked] <mailto:[email-masked]>>
>         Reply-To: Routing Over Low power and Lossy networks
>         <[email-masked] <mailto:[email-masked]>>
>         To: Routing Over Low power and Lossy networks <[email-masked]
>         <mailto:[email-masked]>>
>         On Fri, Sep 13, 2013 at 9:21 AM, Don Sturek <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>               should be a per-interface and not a per-forwarder
>             setting.  I can imagine, for
>                 Given how forwarding is defined in the draft, I don't
>             see how the scenario above is possible unless the links on
>             the "traditional interfaces" happen to be members of the
>             same MPL Domain as the LLN
>
>
>             2)  "- Section 4.1 states: "When used with MPL,
>             Realm-Local scope is administratively
>               is automatically defined (i.e. without human
>             intervention) and how forwarding
>                   This argument was made some time ago and rejected.
>             The purpose in defining and using a realm scoped address
>             is to allow for automatic definition.
>
>
>         I think I'm just confused about the desire for automatic
>         definition of the Realm-Local
>         scope and the several statements in the draft that it's
>         administratively configured.
>         Asking as an implementer, how do I determine whether an
>         interface is in a Realm-
>         I'm not sure whether the draft is intending to reserve the
>         ability to configure which
>         links are in the MPLInterfaceSet. However it seems that
>         Realm-Local scope, like
>         other multicast scopes, must have a consistent definition for
>         any and all protocols
>         that use it.
>
>             The forwarding definition in the Trickle Multicast draft
>             is by MPL Domain so the definition at the end of the
>             paragraph above is not needed.   When using FF03::FC
>             (defined for forwarding within a MPL Domain) then all
>             members of the MPL Domain are forwarded a copy of the
>             multicast transmission.  Section 7.2 especially makes this
>             clear, by interface, by defining:
>
>             described in section 5.5 will ultimately have to be
>             expressed in units of time
>               (either in this document or elsewhere) for a given
>             link-layer in order to avoid
>               reference states: "a protocol SHOULD set k and Imin such
>             that Imin is at least
>                  Since we are using these parameters as defined in RFC
>             6206 (Trickle Algorithm) we should not attempt to redefine
>             them here in this draft.
>
>
>             From: Kerry Lynn <[email-masked] <mailto:[email-masked]>>
>             Reply-To: Routing Over Low power and Lossy networks
>             <[email-masked] <mailto:[email-masked]>>
>             <[email-masked] <mailto:[email-masked]>>
>             On Wed, Sep 4, 2013 at 3:45 PM, Michael Richardson
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>             - In section 4.3, on Proactive Forwarding, the phrase "MPL
>             Data Message message"
>               should be a per-interface and not a per-forwarder
>             setting.  I can imagine, for
>             - Section 4.1 states: "When used with MPL, Realm-Local
>             scope is administratively
>               is automatically defined (i.e. without human
>             intervention) and how forwarding
>             described in section 5.5 will ultimately have to be
>             expressed in units of time
>               (either in this document or elsewhere) for a given
>             link-layer in order to avoid
>               reference states: "a protocol SHOULD set k and Imin such
>             that Imin is at least
>                 Michael Richardson <[email-masked]
>                 <mailto:[email-masked]>>, Sandelman Software
>                 Works
>                 IETF ROLL WG co-chair.
>                 http://datatracker.ietf.org/wg/roll/charter/
>
>
>                 [email-masked] <mailto:[email-masked]>
>             _______________________________________________ Roll
>             mailing list [email-masked]
>             <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/roll
>
>             [email-masked] <mailto:[email-masked]>
>         _______________________________________________ Roll mailing
>         list [email-masked]
>         <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/roll
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: peter van der Stok <[email-masked]>
Date: Tue, 17 Sep 2013 12:21:20 +0200

Hi Michael,
corresponding questions can be:

1) What are the maximum and minimum 1-hop MPL router neighbours of all 
the MPL routers?
2) what is the arrival rate of new packets that need repetition in a MPL 
router
3) Is there a deadline associated with the packets
4) What is the shortest number of hops of the longest path between 
sources and destinations
5) What are the values of the MAC: back-off values, retries, buffer 
size.
6) What is the background load of other non MPL applications.
7) arrival probability of 1-hop packets
8) other parameters I did not stumble on.

The corresponding design space is incredibly large, and probably only a 
limited subset of the design space is viable.
I have gone through only a limited number of possibilities, and 
analysing the consequences for MPL took me quite a large amount of time.

In one of my scenarios:
1) 5 neighbours
2) once every 100 ms (rate at sources is once every 300-500 ms)
3) yes, 200 ms
4) 5 hops, with mostly 1 hop
5) no buffer, retry 1, back-off 2
6) absent
7) 100-80%

leading to k=3-5, Imin =30-70 ms, repeat = 2, Imax n/a.

It may help that operational boundary conditions together with 
appropriate MPL parameter values are published in the applicability 
statements.
All applicability statements together may give a good hint which MPL 
parameters and boundary conditions to choose.

My 5 cents,

peter

---

From: Yusuke DOI <[email-masked]>
Date: Tue, 17 Sep 2013 19:56:59 +0900

Hi Peter,

Thank you for sharing your scenario and parameters. Could you tell me how did you selected the parameters?
I have following two scenarios... and considering how MPL works on the cases.

Scenario A  (commanding)
1) maybe up to 30 neighbours
2) a few/hour
3) end-to-end 5 seconds, 500ms per hop
4) up to 10 hops
5) not sure
6) many, including multiple threads of Scenario B
7) not sure (80%?)

Scenario B (file transfer)
1) maybe up to 30 neighbors
2) 25 packets / hour
3) no deadline per packet
4) up to 10 hops
5) not sure
6) multiple threads of Scenario B and many other traffics
7) not sure (80%?)

Regards,

Yusuke

(2013-09-17 19:21), peter van der Stok wrote:
> 1) What are the maximum and minimum 1-hop MPL router neighbours of all the MPL routers?
> 2) what is the arrival rate of new packets that need repetition in a MPL router
> 4) What is the shortest number of hops of the longest path between sources and destinations
> 5) What are the values of the MAC: back-off values, retries, buffer size.
> The corresponding design space is incredibly large, and probably only a limited subset of the design space is viable.
> I have gone through only a limited number of possibilities, and analysing the consequences for MPL took me quite a large amount of time.
>
> In one of my scenarios:
> 1) 5 neighbours
> It may help that operational boundary conditions together with appropriate MPL parameter values are published in the applicability statements.
> All applicability statements together may give a good hint which MPL parameters and boundary conditions to choose.
>
> My 5 cents,
>
> peter
>
>
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Sep 2013 08:26:53 -0400

> don't think any recommended values should be given and it depends on
    > the applicability.

What is the affect on the network if there is a mis-configuration?

Can it be detected?  Does the network melt-down?

Or is it just a question of multicast not working very well (not reaching all
nodes it should)
I think that these questions will get asked by reviewers.

    > In a nutshell - I think draft-ietf-roll-trickle-mcast-05 is good to go.

Thanks.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Sep 2013 08:58:12 -0400

Peter, added your questions to:

http://www.ietf.org/rfcdiff?url1=draft-ietf-roll-applicability-template-02&difftype=--html&submit=Go%21&url2=draft-ietf-roll-applicability-template-03

---

From: peter van der Stok <[email-masked]>
Date: Tue, 17 Sep 2013 15:37:42 +0200

Hi Michael,

Some consequences:
1) Too many repeaters with too small Imin and too large repeat leads to 
network congestion (similar to having too high send frequency on several 
sources)
2) packets take too long to arrive at all destinations (assuming there 
is a deadline)
3) packets do not arrive at some destinations

This is comparable with what happens when too many nodes start sending 
unicasts on the mesh.

For me the MPL draft is also OK.

Peter

---

From: Robert Cragie <[email-masked]>
Date: Tue, 17 Sep 2013 16:03:29 +0100

+1

Robert

On 17/09/2013 14:37, peter van der Stok wrote:
> Hi Michael,
>
>
> Some consequences:
> 1) Too many repeaters with too small Imin and too large repeat leads 
> to network congestion (similar to having too high send frequency on 
> several sources)

---

From: peter van der Stok <[email-masked]>
Date: Wed, 18 Sep 2013 11:23:56 +0200

Hi Yusuke,

thanks for your interest.
I got the parameter values by doing an on-paper analysis of the 
propagation patterns and the synchrony between the copies sent by 
multiple repeaters
In combination with many simulations, I finally understood what went on 
and came up with a motivated set of parameter values.
The use cases themselves were motivated by run of the mill lighting 
office installations.

For other use cases this process will be faster though.

For your case it would take some simulation try-outs (few days) to get 
it right.
The 30 neighbours makes me think that you need a k value of 10 or 
higher, dependent how the propagation proceeds to the borders of the 
network.
25 packets /hour remove too many worries about interference.
Probably a max repeat of 2 will be sufficient. I usually make the source 
a repeater as well to make sure that one packet arrives at least at one 
destination.
Probably a short Imin value like 30-70 ms will do for you as well; and 
then you will certainly meet the deadlines.
When you have bursts of packets at a repeater, say 10 within 50 ms, 
interference becomes important, and the behaviour of the MAC comes into 
play, retarding the packets and threatening the meeting of the deadline.

But again, It would take a more thorough analysis to come up with 
numbers which can be taken seriously.

Greetings,

Peter

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 19 Sep 2013 09:07:49 -0400

Hi Peter,

> network congestion (similar to having too high send frequency on several

The Trickle Algorithm [RFC 6206] calls for exponential growth of Imax for
some number
of intervals in order to spread the offered load over time.  Thus the claim
that it can "scale
to thousand-fold variations in network density".

It is actually the combination of large load, large k, and small *Imax*
that may contribute to
congestion collapse.  When Imax is limited to Imin then your statement is
true.  [RFC 6206]
suggests Imin should be at least 2-3 times the period it takes to transmit
k packets (and
probably double that).  Knowing k, bit rate, and message size (which seemed
to be missing
from your list of variables) it should be possible to determine a
reasonable value for Imin.
For example, an average mDNS lookup may fit in 127 octets but the
worst-case may be
twice that.

2) packets take too long to arrive at all destinations (assuming there is a
> deadline)

This is probably not a "typical" case.  It may involve trained installers
to achieve this goal
for large LLNs.

> This is mitigated by larger k.

> My original comment regarding default Imin values was that they were
defined in terms
of "worst-case latency" for a given data link and I still think this is
vague (perhaps
purposely so).  I think the present draft would be improved by adding a
definition to
section 2:

Worst Case Latency - The period of time for the largest possible MPL Data
Message to
                    be received by any MPL Forwarder in the MPL Domain.

Regards, -K-

>> > In a nutshell - I think draft-ietf-roll-trickle-mcast-**05 is good to
>> go.
>>
>> Thanks.
>>
>> --
>> IETF ROLL WG co-chair.    http://datatracker.ietf.org/**wg/roll/charter/<http://datatracker.ietf.org/wg/roll/charter/>
>>
>>
>> ______________________________**_________________
>> Roll mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/roll<https://www.ietf.org/mailman/listinfo/roll>
>>
>
> ______________________________**_________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/roll<https://www.ietf.org/mailman/listinfo/roll>
>

---

From: peter van der Stok <[email-masked]>
Date: Thu, 19 Sep 2013 16:34:25 +0200

Hi Kerry,

some inline comments on your comments.
The questions was: what might go wrong when MPL values are badly chosen.
I tried to describe some most likely causes and effects. No attempt at 
completeness was intended.

Kerry Lynn schreef op 2013-09-19 15:07:
> Hi Peter,
> 
> On Tue, Sep 17, 2013 at 9:37 AM, peter van der Stok 
> <[email-masked]> wrote:
> 
> Hi Michael,
> 
> Some consequences:
> network congestion (similar to having too high send frequency on 
> several sources)
> 
> The Trickle Algorithm [RFC 6206] calls for exponential growth of Imax
> for some number of intervals in order to spread the offered load over 
> time.  Thus the
> claim that it can "scale to thousand-fold variations in network 
> density".
> 
> It is actually the combination of large load, large k, and small
> *Imax* that may contribute to
> congestion collapse.  When Imax is limited to Imin then your statement
> is true. 

I think a small Imin is sufficient in combination with many sources, 
repeaters and large repeat
Stating Imax =Imin certainly helps. I was referring to an Imin=1 ms.

[RFC 6206] suggests Imin should be at least 2-3 times the period it 
takes to
> transmit k packets (and
> probably double that).  Knowing k, bit rate, and message size (which
> seemed to be missing
> This is probably not a "typical" case.  It may involve trained
> installers to achieve this goal

For me it is typical. My deadlines are 200 ms.
I also think that conditions on the installation (density of repeaters, 
bounded network load, source and destination separated by bounded number 
of hops) will go a long way to make deadlines meet.
> This is mitigated by larger k.

So choice of k is important
> of "worst-case latency" for a given data link and I still think this
> is vague (perhaps
> purposely so).  I think the present draft would be improved by adding
> a definition to
> section 2:
> 
> Worst Case Latency - The period of time for the largest possible MPL
> Data Message to
> 

As stated earlier. I don't like the worst case latency. With a heavily 
loaded network, MAC buffers > 3, Backoff retries >2, worst case 
latencies can reach hundreds of msec and even seconds.
The transmission time of the packet 3-6 ms can be neglected under those 
circumstances. Concluding, WCL should certainly not be used to set Imin.
However the I-D talks default values and the wording is OK for me.
> Regards, -K-

Greetings
Peter
> [1]
> https://www.ietf.org/mailman/listinfo/roll [2]
> 
> https://www.ietf.org/mailman/listinfo/roll [2]
> 
> 
> 
> Links:
> ------
> [1] http://datatracker.ietf.org/wg/roll/charter/
> [2] https://www.ietf.org/mailman/listinfo/roll