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

[Don Sturek <[e-mail]>]

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


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&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
>> 
>> 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] https://www.ietf.org/mailman/listinfo/roll