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

[Don Sturek <[e-mail]>]

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


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&co
>>> l=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] <mailto:[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