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

[Kerry Lynn <[e-mail]>]

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

> 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.
>
>
ACK.  Thanks for your explanations.

-K-


> Don
>
>
> From: Kerry Lynn <[e-mail]>
> Reply-To: Routing Over Low power and Lossy networks <[e-mail]>
> Date: Friday, September 13, 2013 10:56 AM
>
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Subject: Re: [Roll] WGLC - Working Group Last Call -
> draft-ietf-roll-trickle-mcast-05
>
> Don, thanks for your additional comments...
>
> On Fri, Sep 13, 2013 at 10:45 AM, Don Sturek <[e-mail]> wrote:
>
>> 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.
>>
>> 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).
>
>
> 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.
>>
>> 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-
>
>
>> Don
>>
>>
>> From: Kerry Lynn <[e-mail]>
>> Reply-To: Routing Over Low power and Lossy networks <[e-mail]>
>> Date: Friday, September 13, 2013 6:58 AM
>>
>> To: Routing Over Low power and Lossy networks <[e-mail]>
>> Subject: Re: [Roll] WGLC - Working Group Last Call -
>> draft-ietf-roll-trickle-mcast-05
>>
>> Hi Don,
>>
>> On Fri, Sep 13, 2013 at 9:21 AM, Don Sturek <[e-mail]> wrote:
>>
>>> 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
>>>
>>
>> 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.
>>
>>>
>>> 2)  "- 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."
>>>
>>>       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-
>> 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
>>> 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
>>>   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."
>>>
>>>      Since we are using these parameters as defined in RFC 6206 (Trickle
>>> Algorithm) we should not attempt to redefine them here in this draft.
>>>
>>
>> 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-
>>
>>
>>>
>>> Don
>>>
>>>
>>> From: Kerry Lynn <[e-mail]>
>>> Reply-To: Routing Over Low power and Lossy networks <[e-mail]>
>>> Date: Friday, September 13, 2013 5:10 AM
>>> To: Routing Over Low power and Lossy networks <[e-mail]>
>>> 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 <
>>> [e-mail]> wrote:
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> 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-
>>>
>>>
>>>
>>>> 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 <[e-mail]>, Sandelman Software Works
>>>> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>>>>
>>>>
>>>> _______________________________________________
>>>> Roll mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>
>>>>
>>> _______________________________________________ Roll mailing list
>>> [e-mail]://www.ietf.org/mailman/listinfo/roll
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/roll
>>>
>>> _______________________________________________ Roll mailing list
>> [e-mail]://www.ietf.org/mailman/listinfo/roll
>>
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
>>
> _______________________________________________ Roll mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>