Subject: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Fri, 15 Mar 2013 11:34:54 +0000

Dear all,

All issues raised during the previous WG LC have been successfully addressed in draft-ietf-roll-trickle-mcast-04.
That said, since we made several changes, this starts a 2-week WG LC that will end on March 29 at noon ET.
Thanks.

JP.

On Oct 25, 2012, at 8:55 AM, JP Vasseur (jvasseur) wrote:

Dear all,

draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing list and during WG meeting a number of time; the document is stable and
has been implemented. Thus this starts a 2-week WG Last call ending on Nov 9 at noon ET. Please send your comments to the authors
and copy the mailing list and the co-chairs.

Thanks.

JP.

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

---

From: peter van der Stok <[email-masked]>
Date: Fri, 15 Mar 2013 15:16:00 +0100

Hi Jonathan,

I have a few editing remarks for mpl-4 document:

  end of page 8, end of Reactive forwarding paragraph. I suggest to 
replace <..... using the Trickle algorithm> by
<.....using proactive forwarding>.

page 11, default value of DATA_MESSAGE_IMIN "10 times the worst-case 
link-layer latency"
given the medium sensing and back-off in the MAC, the worst case 
link-layer latency becomes easily 100 ms, giving a default value of 1 
second or more.
May be you mean the transmission time which has a value of 3 ms ?

page 11, default value of DATA_MESSAGE_K has value of 5, before the 
value of 1 was encouraged. Personally for me, the value 1 seems adquate.

page 15 MPL Seed Info [0..n], page 14 MPL Seed Info [1..n], Given the 
other text with bit i=0 meaning the message with seq nr min-seqno, I 
would suggest MPL Seed Info [0..n-1]

Many thanks for your work,

Peter

JP Vasseur (jvasseur) schreef op 2013-03-15 12:34:
> Dear all,
> 
> All issues raised during the previous WG LC have been successfully
> addressed in draft-ietf-roll-trickle-mcast-04.
> 
>> draft-ietf-roll-trickle-mcast-02 has been discussed on the mailing 
>> list and during WG meeting a number of time; the document is stable 
>> and
>> has been implemented. Thus this starts a 2-week WG Last call ending 
>> on Nov 9 at noon ET. Please send your comments to the authors
>> [email-masked]
> [email-masked]

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 29 Mar 2013 10:20:29 -0400

Greetings,

Apart from the fact that this draft is introduced in ROLL to address a problem
inherent in multi-link subnets, I see nothing in the proposal that
limits it to such
networks.  It seems to me that trickle multicast could be considered in other
applications, e.g. homenet, if it compares favorably with PIM-xM in complexity.

In reading trickle multicast in this more general way, I'd like to see
additional
clarification regarding the use of Proactive Forwarding.  Section 4.2 reads:

   Proactive Forwarding  - With proactive forwarding, an MPL Forwarder
      schedules transmissions of MPL Data Messages using the Trickle
      algorithm, without any prior indication that neighboring nodes
      have yet to receive the message.  After transmitting the MPL Data
      Message a limited number of times, the MPL Forwarder may terminate
      proactive forwarding for the MPL Data Message message.

I think the final sentence should read:

     After transmitting the MPL Data Message a limited number of times, the
     MPL Forwarder MUST terminate forwarding of the MPL Data Message.

This eliminates the possible interpretation that both Proactive and Reactive
Forwarding may be used by the same MPL Forwarder for the same MPL
Data Message within the same MPL Domain.  I believe the intent is that
Proactive and Reactive Forwarding should be mutually exclusive within
the same MPL Domain?

In section 5.4, PROACTIVE_FORWARDING is listed as a "MPL Forwarder
Parameter".  I believe this should be set (or not) on a MPL Domain basis
(and therefore as an attribute of the Local Interface).  Again, it should be
made clear that Proactive and Reactive Forwarding are mutually exclusive,
e.g. by adding a sentence to the end of the first paragraph in section 5.4:

     If PROACTIVE_FORWARDING is FALSE, then Reactive Forwarding
     is in use.

This ties it to section 5.1, which mandates MPL Control Messages on an
interface where Reactive Forwarding is in use.

I believe that section 5.5 should also be clarified with respect to the meaning
of DATA_MESSAGE_TIMER_EXPIRATIONS.  The second paragraph should
read:

   This specification defines a fourth Trickle configuration parameter,
   TimerExpirations, which indicates the number of Trickle timer
   expiration events that occur before terminating the forwarding of a
   given MPL Data Message.

This then ties DATA_MESSAGE_TIMER_EXPIRATIONS back to the "limited
number of times" statement in section 4.2.  Similarly, the definition of
DATA_MESSAGE_TIMER_EXPIRATIONS should read:

   DATA_MESSAGE_TIMER_EXPIRATIONS  The number of Trickle timer
      expirations that occur before terminating the Trickle algorithm's
      re-transmission of a given MPL Data Message.
      DATA_MESSAGE_TIMER_EXPIRATIONS has a default value of 3.

This eliminates the possible interpretation that the Trickle algorithm may
not be used for subsequent MPL Data Messages.

Regarding the definition of DATA_MESSAGE_IMAX, RFC 6206 seems
to suggest that this parameter should be described as the number of
doublings of Imin: "For example, a protocol might define Imax as 16."
If this interpretation is correct, then DATA_MESSAGE_IMAX should be
set to 0 in order to limit Imax to Imin.

Similarly, CONTROL_MESSAGE_IMAX should be set to an integer
number of doublings, or at least specified in terms of worst-case link-
layer latency if my interpretation of RFC 6202 is incorrect.

The implication of specifying Imax = Imin seems to be that the dithering
interval for MPL Data Message re-transmission will *always* be [Imin/2,
Imin) == DATA_MESSAGE_K (since DATA_MESSAGE_IMIN is specified
as 2*DATA_MESSAGE_K).  This has the effect of setting k == infinity,
which is presumably the point for specifying the default values as they are.

Regarding the definition of MPL Domains, section 8 states:

   By default, an MPL Forwarder SHOULD participate in an MPL Domain
   identified by the ALL_MPL_FORWARDERS multicast address with a scope
   value of 3 (subnet-local).

As Ralph Droms indicated in
http://www.ietf.org/mail-archive/web/roll/current/msg07829.html, "something
has to be done to allow MPL to use scope 0x03."  In the most expedient
scenario, 0x03 is re-defined from "reserved" to "undefined" and the proposal
then gets to define how 0x03 is used by trickle multicast.

Assuming the desired use of 0x03 multicast scope is to indicate
ALL_MPL_FORWARDERS within a given prefix, the question is how to
indicate the prefix in question?  RFC 6282 allows for the stateful compression
of RFC 3306 (prefix-based) multicast addresses.  RFC 3307, section 4.2
allows for the assignment of "Permanent IPv6 Multicast Group Identifiers"
for use with RFC 3306 multicast addresses.  Therefore it seems prudent to
also request from IANA a Permanent IPv6 Multicast Group Identifier
http://www.iana.org/assignments/perm-mcast-groupids/perm-mcast-groupids.xml
to allow for the possibility of specifying the desired prefix in the MPL Domain
Address.

Lastly, to improve the clarity of section 11.2, the first bullet should read:

   o  This document defines a "consistent" transmission as receiving an
      MPL Control Message that results in a determination that neither the
      receiving nor transmitting node has any new MPL Data Messages to offer.

(The transmission indicates nothing about state at the receiver.)  Similarly,
the second bullet should read:

   o  This document defines an "inconsistent" transmission as receiving
      an MPL Control Message that results in a determination that either the
      receiving or transmitting node has at least one new MPL Data Message
      to offer.

It might be helpful to add a penultimate sentence to section 11.2:

      The Trickle timer is reset in response to external "events".

Regards, -K-

---

From: Don Sturek <[email-masked]>
Date: Fri, 29 Mar 2013 07:37:34 -0700

Hi Kerry,

The problem that  draft-ietf-roll-trickle-mcast-04 addresses really only
occurs in route-over mesh routing.  I don't believe Homenet has such
routing solutions in their charter.  It is possible to see how a group
like Manet might use the draft but the only concrete forwarding solution
proposed is over ROLL RPL instances (certainly, provision was left in for
other multicast address usage and attendant forwarding rules but those
were out of scope for this draft).

I would propose that we move forward with the draft, within ROLL, and not
wait for input from other groups since the scope of the initial draft
(absent extensions that other groups could propose in the future) is
focused on ROLL RPL.

Don

On 3/29/13 7:20 AM, "Kerry Lynn" <[email-masked]> wrote:

>>list and during WG meeting a number of time; the document is stable and
>> has been implemented. Thus this starts a 2-week WG Last call ending on
>>Nov 9 at noon ET. Please send your comments to the authors

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 29 Mar 2013 11:08:07 -0400

> were out of scope for this draft).
I don't think this opinion reflects on the validity of my comments for even
the restricted ROLL use and I'd be interested in feedback from the authors.

In addition to the comments I made previously, I am concerned that the
default for Imax (== Imin) prevents the Trickle timer interval I from ever
doubling.  Combined with a high k, this leads to aggressive Trickle forwarding
in dense parts of the mesh that may inhibit (by interfering with) unicast
responses in transit to the original sender.  Is there a reason for not
relaxing DATA_MESSAGE_IMAX to e.g.
DATA_MESSAGE_TIMER_EXPIRATIONS?

-K-

---

From: David Culler <[email-masked]>
Date: Fri, 29 Mar 2013 08:24:13 -0700

Hi Don,
   It is pretty hard to see how you come to the sweeping statement, "The problem that  draft-ietf-roll-trickle-mcast-04 addresses really only occurs in route-over mesh routing [sic]."  That is the purview of the draft and sufficient for it to address that domain, but your statement is quite another thing.  

David

---

From: Don Sturek <[email-masked]>
Date: Fri, 29 Mar 2013 08:28:18 -0700

Hi Kerry,

Do you have actual test results to back up the claims below?   We (the
ZigBee IP team) tested these parameters among 7 solution providers and did
not see what you are reporting.

Interested in seeing your results.....

Don

---

From: Don Sturek <[email-masked]>
Date: Fri, 29 Mar 2013 08:31:18 -0700

Hi David,

Yes, fair enough.   It is possible that Trickle Multicast is used in areas
outside of route over mesh, however, as you note, the purview of the draft
is really just that.

Don

On 3/29/13 8:24 AM, "David Culler" <[email-masked]> wrote:

>Hi Don,
>   It is pretty hard to see how you come to the sweeping statement, "The
>problem that  draft-ietf-roll-trickle-mcast-04 addresses really only
>occurs in route-over mesh routing [sic]."  That is the purview of the
>draft and sufficient for it to address that domain, but your statement is
>quite another thing.
>
>David
>
>
>>> (and therefore as an attribute of the Local Interface).  Again, it
>>>should
>>> be
>>>http://www.iana.org/assignments/perm-mcast-groupids/perm-mcast-groupids.
>>>xm
>>> l
>>> to allow for the possibility of specifying the desired prefix in the
>>>MPL
>>> Domain
>>> Address.
>>> 
>>>

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Fri, 29 Mar 2013 19:09:07 +0000

This terminates the WG LC; authors please make sure the address the few concerns that were raised during WG LC,
I am specifically referring to the editorial comments raised by Kerry.

Thanks.

JP.

On Mar 15, 2013, at 12:34 PM, JP Vasseur (jvasseur) wrote:

Dear all,

JP.

Dear all,

Thanks.

JP.

---

From: peter van der Stok <[email-masked]>
Date: Sat, 30 Mar 2013 13:24:17 +0100

Hi Don, Kerry,

As I tried to express earlier, I am not too happy with the suggested 
default values for the mpl parameters.
Their recommended values very much depend on the timing characteristics 
of the application and the topology of the network.
I think it is more appropriate to have these values cited in the 
applicability statements (if they are focused enough).

Coming back to simulation c.q. operation results:
I can well imagine that with a network that is loaded for a few percent 
of the time with mpl messages the value of k is not that important.
I can also imagine that at the edge of networks with a strongly varying 
density of repeaters, it is possible that some nodes at the edge only 
receive messages with a given regularity when k is infinity.
In the applications that I consider the density of repeaters is quite 
homogeneous, the end to end delays are expressed in hundreds of 
milliseconds and multiple seeds generate messages on a (tens of) seconds 
scale. In that case k=1 is often excellent and a higher k is not 
recommended.

hope this helps,

peter

Don Sturek schreef op 2013-03-29 16:28:
>>> proposed is over ROLL RPL instances (certainly, provision was left 
>>> in
>>> for
>> I don't think this opinion reflects on the validity of my comments 
>> for
>> even
>>> I would propose that we move forward with the draft, within ROLL, 
>>> and
>>> not

---

From: Don Sturek <[email-masked]>
Date: Sat, 30 Mar 2013 06:11:17 -0700

Hi Peter,

What you wrote below sounds quite correct.   Given our testing, your
statement that that recommend default paramters depend on the timing
characteristics of the application and topology of the network aligns very
well with the test results we gathered.

Our test used our assumed topology (30 node network with 3 hops).   We
created the network using IEEE 802.15.4 devices connected via wires on SMA
connectors (with attenuators to reflect distance between the devices).
Our test set up was to create a multicast message targeting from 1 to 8
devices in the network where each of the targeted devices was to create a
multicast message in response (we were testing how mDNS would work using
Trickle Multicast in our network).   Our success criteria was to see that
every node in the network (100% coverage on the requst) saw the original
multicast request and that the requestor would see all of the responses
(100% coverage on the responses received).   We ran quite a few tests with
varying numbers for Imin, Imax, tdell, k, etc.   Intiially, we wanted the
window to be small thinking that would best service the requests/responses
but could only get to around 60% of requests seen and responses received.
Finally, we had to set Imax out to 512ms to achieve our goal.   One clear
observation is that these settings were definitely tied to the number of
devices in the network and topology.

I know for lighting applications that multicasts must be received within
250ms.   That was not our use case so we did not impose this restriction.
It would have been interesting to see if we could have achieved both
goals:   all devices seeing the request AND the multicast request
delivered within 250ms.

Don

---

From: peter van der Stok <[email-masked]>
Date: Sun, 31 Mar 2013 14:16:39 +0200

Hi Don,

Nice to read that some of my conclusions are confirmed by real 
experience.
The behavior you sketch is also recognized by me.

Currently, I try to analyze timing behavior for 1 to 2 hop networks 
including a 10% loss on a link between seed and a destination.
I am not interested in responses (for the moment).
But your aim to have a 100% reception probablity is certainly shared.

Let's compare results when my understanding of this simple network 
topology has increased.

Greetings,

peter

Don Sturek schreef op 2013-03-30 14:11:
>>> ZigBee IP team) tested these parameters among 7 solution providers 
>>> and
>>> did
>>>>> The problem that  draft-ietf-roll-trickle-mcast-04 addresses 
>>>>> really
>>>>> only
>>>> default for Imax (== Imin) prevents the Trickle timer interval I 
>>>> from
>>>> ever

---

From: Don Sturek <[email-masked]>
Date: Sun, 31 Mar 2013 11:01:57 -0700

Hi Peter,

One thing I forgot to mention.  For the 30 nodes/3 hops, we isolated two
parts of the network such that 15 devices on each half had upward paths to
the DAG root.   This allowed us to model the network as if the DAG root
were in the center of two 15 node network segments of hop count 3 from the
root.   This forced the multicast distribution to transmit all of the way
up to the DAG root and back down to service devices on the other half of
the network segment.

Don