[Roll] Review draft-ietf-roll-trickle-mcast-01

["Dijk, Esko" <[e-mail]>]

Dear Jonathan,

we are glad to see interest and renewed activity for this draft. We would be very willing to help move it forward.
As a first step we provide below a review of the current draft to identify some issues. If needed we can later provide more constructive feedback (e.g. provide or edit text). Hopefully this helps towards an improved -02 version!

best regards,

Esko Dijk
Peter van der Stok
Armand Lelkens

Philips Group Innovation, Research
High Tech Campus 34, Eindhoven, The Netherlands
[e-mail]

--------- Review comments ---------

General
- Terms "transmit", "retransmit" and "forward" seem to be used interchangeably.
  It would be good to check for this and have uniform terms. Suggested: "retransmit" for (re)transmitting Trickle Multicast Messages, "transmit" for transmitting Trickle ICMP Messages, and "forward" use only if accompanied by one of the other terms. Such as in the sentence "nodes simply retransmit multicast messages they are trying to forward" it's clear.

Section 3
"A multicast message is
   only retransmitted upon receiving positive indication that a neighbor
   has not yet received that multicast message."
-> But it's not immediately retransmitted (as some readers may think at this point based on their background idea of 'retransmissions'). Maybe add early in the text somewhere that retransmissions only happen at the time t the Trickle algorithm transmits (and define that moment as "transmission event"). Such definition could be added to Section 2.

"The Trickle timer period doubles when the period expires and no
   "inconsistent" advertisements have been received, reducing control
   overhead when the network is in a consistent state."
-> it should be made clear if this is only about "inconsistent" advertisements, or also "inconsistent" transmissions as defined in section 6.2, which includes more than just advertisements.
The term advertisement usually means the Trickle ICMP message, but here it's not so clear.
It would be even better to unify the terminology, e.g. use only "inconsistent" transmissions and do not mention "inconsistent" advertisements here.

"Instead, nodes simply retransmit multicast messages they
   are trying to forward."
-> replace 'nodes' with 'forwarders' here. 'they are trying to forward' could be specified better here e.g. as in
 'all multicast messages they have buffered'.

Section 4

Parameters in general: should there be requirements on what parameter ranges an implementation supports?
For example, an implementation could only support k=infinity to reduce code size. Is this allowed?
Can it claim to be compliant to this protocol?

"Tactive ... Specified in units of Imax."
-> does this imply integer multiples of Imax? Or are fractions of Imax okay too.
(Same point for Tdwell)

Stating Tdwell MUST be >= Tactive would be useful here for completeness.

The conservative parameter settings example:
- Imax is 30 min, which is not an integer number of doublings of Imin as described in RFC6206. Maybe use Imax=14 (doublings) gives Imax = 27.3 (minutes) ?
- Tdwell is 6 hours in this example. Correct? It seems quite a long period to keep sliding window state.

Section 5.2

"The link-local all-nodes (FF02::1) or link-local all-routers (FF02::2) multicast address."
-> why is all-nodes allowed, if the ICMP message is only intended for routers?

Section 5.2.1

"SeedID    Copied from a recently received Trickle Multicast option."
-> better to describe what it means first, then how it was obtained. So a SeedID description to be inserted.

Section 6.1

"Every Trickle multicast forwarder MUST maintain a sliding window of
   Sequence values for each SeedID "
-> there is an exception to the MUST, if memory constraints don't allow it. Best to mention this directly in the paragraph perhaps?

"When only one entry for a sliding window remains, that entry MUST NOT
   be reclaimed until its dwell timer expires"
-> here the usage of value Tdwell should be mentioned explicitly e.g. "dwell timer > Tdwell" means it expired.
-> typo: previous paragraph mentions "dwell time" not "dwell timer"?
-> concept of dwell timer not fully explained. The use of "reclaiming entry" in the text suggests that each entry has a dwell timer, but the text in definition of Tdwell suggests that an entire sliding window has one dwell timer.
A need to formally define the dwell timer and the active timer?

In general, the situation when a new entry within a sliding window can't be created due to memory constraints is not considered. (Reclaiming entries to gain memory is considered on the other hand - so why not the reverse.)
If in the future the idea of bit masks in a sliding window would be introduced then the individual entry creation/deletion is not relevant for memory considerations probably.

Section 6.2

"A Trickle multicast forwarder maintains two Trickle timers
   parameterized on the S flag."
-> M flag

"...transmission event consists of transmitting a Trickle ICMP message.
   If an "inconsistent" advertisement was received during that period,
   multicast messages that caused the inconsistency are also
   retransmitted."
-> should the mentioned 'multicast messages' be defined as part of the transmission event for k finite? Currently the transmission event seems defined as only the ICMP message. While for k = infinite, the transmission event is defined as retransmitting all buffered multicast messages.

"When suppression is enabled (i.e. k is finite), a Trickle
   transmission event consists of transmitting a Trickle ICMP message.
   If an "inconsistent" advertisement was received during that period,
   multicast messages that caused the inconsistency are also
   retransmitted."
-> If I read correctly, "multicast messages" here includes Trickle Multicast Messages but also IP multicast datagrams. The latter is for example sent by a host and received by a Trickle Multicast Forwarder which adds the HbH option. It would be good to add a definition, and consider what to do, for IP multicast datagrams which do not (yet) have the Trickle HbH option.

-> text suggests (in its context) that retransmissions are probably a part of the "transmission event". But some may also interpret this differently, based on the prior definition; i.e. that multicast messages that caused inconsistency are retransmitted directly, regardless of whether the transmission event is suppressed or not. In this view, retransmissions are not part of the Trickle transmission event.
Improved definitions of "retransmission" and "transmission event" could solve that.

-> the order of Trickle ICMP Message / Trickle Multicast Messages is not defined. Is any order allowed? We would prefer so. E.g. first send all retransmissions and then the ICMP message can have specific latency advantages.
-> any requirements on the time between messages, if multiple messages are sent in one transmission event?

"This document defines receiving a "consistent" transmission as
   receiving a Trickle ICMP message that indicates neither the receiving
   nor transmitting node has new multicast messages to offer.
   This document defines receiving an "inconsistent" transmission as
   receiving a Trickle ICMP message that indicates either receiving or
   transmitting node has a new multicast message to offer.    An "inconsistent"
   transmission also includes receiving a new multicast message."
-> so a "transmission" consists of a single message. This makes it different from a "transmission event" which may consist of multiple messages. Just wondering if this complies with RFC 6206 which was probably written with a single message per event in mind? Any thoughts?

Section 6.3

"Upon accepting the message, the forwarder MUST enter the sequence
   value in the sliding window and decrement the IPv6 Hop Limit.  If the
   IPv6 Hop Limit is non-zero, the forwarder MUST buffer the message for
   retransmission for the duration specified by Tactive."
-> to do: specify behaviour if the buffer for the message can't be allocated?

Section 6.4
"Processing a Trickle ICMP message involves determining if either the
   receiver or transmitter has new multicast messages to offer."
-> Processing a Trickle ICMP message by a multicast forwarder involves ...
   (edited to clarify whether it is the sender or the receiver that is later in this section called "multicast forwarder")

"The transmitter has new multicast messages to offer if any (SeedID,
   Sequence) pair falls within an existing sliding window for SeedID but
   does not have an associated entry."
-> The transmitter has new multicast messages to offer if any (SeedID,
   Sequence) pair from the message falls within an existing sliding window for SeedID but
   does not have an associated entry in this sliding window.

"The transmitter has new multicast messages to offer if the (SeedID,
   Sequence) pair is great than the upper bound of an existing sliding
   window for SeedID."
-> The transmitter has new multicast messages to offer if any (SeedID,
   Sequence) pair is greater than the upper bound of an existing sliding
   window for SeedID.

"logs an inconsistent event by resetting Trickle timer T[M]"
-> logs an inconsistent event by resetting Trickle timer T[M] and setting c=0
   (addition c=0 to clarify only)
-> maybe add that reset is only when I > Imin.
   But it should be clear that the action of scheduling of "all new messages that the receiver can offer" is done always, even if I==Imin already. E.g. in situations where two ICMP messages with inconsistent info are received in rapid succession, this is relevant.
-> The above statement about the scheduling action for some readers of the draft may seem to contradict step 6 of the Trickle algorithm,
   "If I is equal to Imin when Trickle hears an "inconsistent" transmission, Trickle does nothing"
   which requires that nothing should be done.

"All new messages that the receiver can offer MUST be scheduled"
-> "All new messages that the receiver can offer to the transmitter MUST be scheduled"
   (aim to clarify. This statement is not about any messages it can offer in general, probably.)
-> What if the sending of scheduled multicast transmissions takes so long that the next Trickle "transmission event" already happens when the previous one is still ongoing (e.g. for very small I=Imin)?




-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jonathan Hui (johui)
Sent: Friday 13 July 2012 18:59
To: [e-mail] WG
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-01.txt


Activity on this draft has been dormant for far too long.  We've resubmitted the draft with no substantive changes in attempt to move this work forward.

>From my perspective, there are a number of areas to improve on this draft:

1) Format of the HBH Option.

- The HBH Option does not currently have any version field.  I know the ZigBee folks are anxious to lock the format down, yet I don't believe we are at a point where we can (given the issues below and other issues that we have yet to find).  Finding a way to version the HBH Option will give us a path forward not only as we work on the initial specification but for future specifications as well.

- The SeedID is limited to 2 or 16 bytes.  That seems a bit constrained.  First, I have seen use cases where only a single multicast seed is used within a network, and it would be beneficial to completely elide the SeedID (with an assumed value of zero).  Second, different applications have different upper bounds on the number of seeds and/or how the SeedIDs are allocated/configured, which can dictate what size  the SeedID should actually be.  One thought is to allow the SeedID to vary between 0 and 16 bytes.

- The Sequence field is 15 bits.  I would be nice to have a Sequence field that is a multiple of 8 bits to make Serial Number Arithmetic more convenient.

- I'm aware of one technical bug with the HBH Option when trying to utilize a sliding window larger than 1.  In particular, a device processing the HBH Option does not know if the Sequence value represents the largest sequence value received by the neighboring node or an older message that it happens to be retransmitting.  Ideally, a device only resets its Trickle timer when receiving indication that a neighboring device has not yet received a message yet.  I propose adding a flag to the HBH Option that indicates whether the Sequence value is the latest.

2) Format of the ICMPv6 Message

- The format of the ICMPv6 message is not as compact as it could be.  Currently it explicitly lists each sequence value within a sliding window.  An alternative is to have a field that indicates the base and length, then use a bit vector to indicate what sequence values are buffered.

3) Use of IPv6-in-IPv6 Tunneling

- This draft was written before the RPL Option and RPL Source Route Header drafts went through extensive review.  What we learned from doing the RPL Option and Source Route Header is that IPv6-in-IPv6 encapsulation is necessary whenever adding/removing fields from an IPv6 packet en-route.  It is especially necessary when adding to ensure that we don't break Path MTU discovery.  It is convenient when removing to ensure that the original packet remains unmodified.

4) In general, a lot of work needs to be done to the draft to make the forwarder behavior rules more explicit.

Thoughts?

--
Jonathan Hui


On Jul 13, 2012, at 9:55 AM, <[e-mail]>
 <[e-mail]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.
>
>       Title           : Multicast Forwarding Using Trickle
>       Author(s)       : Jonathan W. Hui
>                          Richard Kelsey
>       Filename        : draft-ietf-roll-trickle-mcast-01.txt
>       Pages           : 19
>       Date            : 2012-07-13
>
> Abstract:
>   Low power and Lossy Networks (LLNs) are typically composed of
>   resource constrained nodes communicating over links that have dynamic
>   characteristics.  Memory constraints coupled with temporal variations
>   in link connectivity makes the use of topology maintenance to support
>   IPv6 multicast challenging.  This document describes the use of
>   Trickle to efficiently forward multicast messages without the need
>   for topology maintenance.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-01
>
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-trickle-mcast-01
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll

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

________________________________
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.