Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

[Ulrich Herberg <[e-mail]>]

Jonathan,

thanks for addressing my comments. See below:

On Tue, Oct 30, 2012 at 9:56 AM, Jonathan Hui (johui) <[e-mail]>wrote:

>
> [...]
> >
> >   This document specifies the Multicast Protocol for Low power and
> >   Lossy Networks (MPL), which provides IPv6 multicast forwarding in
> >   constrained networks.  MPL avoids the need to construct or maintain
> >   any multicast forwarding topology, disseminating multicast messages
> >   to all MPL forwarders in an MPL domain.  By using the Trickle
> >   algorithm [RFC6206], MPL requires only small, constant state for each
> >   MPL device that initiates disseminations.  The Trickle algorithm also
> >   allows MPL to be density-aware, allowing the communication rate to
> >   scale logarithmically with density.
> >
> > UH> I am not sure I understand the last sentence. What does it mean?
> > How is that achieved?
>
> This is borrowing the wording out of RFC 6206.  I can reference the RFC
> here (again) and reference the academic papers (NSDI'04, CACM'08) that
> present this result.
>

Yes, I think that would  be a good idea.



>
> > UH> By the way, since this is a standards track document, is there any
> > deployment experience? Implementations?
>
> As Don mentioned, there are a number of implementations on different
> platforms.  Peter van der Stok has also presented his implementation to the
> WG.  Cisco also has an implementation.
>
> The use of Trickle to disseminate messages has been implemented, deployed,
> and published numerous times in the past.  These implementations include
> small message, medium message, and large message dissemination.  Including
> NSDI'04, SenSys'04, SenSys'06, CACM'08, SenSys'08, and TOSN'10.
>


Thanks!

 [...]

> >
> >   MPL multicast scope The multicast scope that MPL uses when forwarding
> >                       MPL multicast packets.  In other words, the
> >                       multicast scope of the IPv6 Destination Address
> >                       of an MPL multicast packet.
> >
> > UH> An RFC reference to "scope" could be helpful.
>
> I assume you mean RFC 4007.
>


Yes, could be helpful to cite.



> [...]
>

> >
> >
> >                       The
> >                       MPL domain MUST be composed of at least one MPL
> >                       multicast scope and MAY be composed of multiple
> >                       MPL multicast scopes.
> >
> > UH> Why is that? Anyway, I am unsure whether one can say that a
> > routing domain "consists" of multicast scopes. If I understand that
> > correctly, the multicast scope just determines how far a message
> > propagates.
>
> I think it would help to define "MPL multicast scope zone" in addition to
> "MPL multicast scope".  Then the correct wording for the text above is "MAY
> be composed of multiple MPL multicast scope zones."  Does that help?
>


I need to read the new revision to see if that is clearer.



> [...]
>
>
> >   MPL delivers IPv6 multicast packets by disseminating them to all MPL
> >   forwarders within an MPL domain.  MPL dissemination is a form of
> >   flood.  An MPL forwarder may broadcast/multicast an MPL multicast
> >   packet out of the same physical interface on which it was received.
> >   Using link-layer broadcast/multicast allows MPL to forward multicast
> >   packets without explicitly identifying next-hop destinations.  An MPL
> >   forwarder may also broadcast/multicast MPL multicast packets out
> >   other interfaces to disseminate the message across different links.
> >   MPL does not build or maintain a multicast forwarding topology to
> >   forward multicast packets.
> >
> >   Any MPL forwarder may initiate the dissemination process by serving
> >   as an MPL seed for an original multicast packet.  The MPL seed may or
> >   may not be the same device as the source of the original multicast
> >   packet.  When the original multicast packet's source is outside the
> >   LLN,
> >
> > UH> LLN or MPL domain? How can a router determine if an incoming
> > packet is inside our outside the MPL domain?
>
> MPL forwarding domain.  Generally, the packet is outside when received on
> an interface not used for MPL forwarding or when the original multicast
> packet does not contain an MPL Option.
>


I think that should be spelled out in the draft.



 [...]

> >
> > UH> I think the whole introduction is not very easy to read. There is
> > a lot of text about some details (IPv6-in-IPv6 tunnels, multiple
> > interfaces), but the essential mechanism is hard to identify from the
> > text. Also, there is nothing mentioned about what kind of state is
> > required to be stored on each router (which information sets etc).
>
> A lot of this is combined with text in Section 5.  Would you prefer to see
> that pulled up here?
>

Yes, I think so. It could help to split the introduction section in
subsections that illustrate the core mechanism (1.1), the required state
(1.2), the message exchange (1.3) etc. in different subsections each. This
would allow for easily understanding the core mechanism, before diving into
IPv6 encapsulation etc.




>
> > Hui & Kelsey             Expires April 22, 2013                 [Page 6]
> > Internet-Draft                     MPL                      October 2012
> >
> >
> > 4.  Message Formats
> >
> > 4.1.  MPL Option
> >
> >   The MPL Option is carried in an IPv6 Hop-by-Hop Options header,
> >
> > UH> I think the correct term is "IPv6 Extension Hop-by-Hop Options
> header"
>
> I was following the text of RFC 2675.
>


Okay, you may be right. According to RFC2460, it is an IPv6 Extension
header called "Hop-by-hop options header" ;-)




>
> > UH> More importantly,  RFC6564 specifies:
> >
> >      New options for the existing Hop-by-Hop Header SHOULD NOT be
> >      created or specified unless no alternative solution is feasible.
> >      Any proposal to create a new option for the existing Hop-by-Hop
> >      Header MUST include a detailed explanation of why the hop-by-hop
> >      behavior is absolutely essential in the document proposing the new
> >      option with hop-by-hop behavior.
> >
> > UH> I did not see such an explanation.
>
> How about:
>
> "The MPL option is needed because the IPv6 header does not provide unique
> identification of IPv6 packets from the source."
>

Could you reuse a similar header, e.g., from RFC6621? It seems that
multiple RFCs intend to define a header for identifying IPv6 packets with a
sequence number.
In addition, I think it could be helpful to argue why you cannot use a
Destination Options header; the keyword from RFC6564 is "detailed
explanation", so one sentence may not be enough.



>
> > [...]
> >
> > UH> 2 or 4 depending on what?
>
> Depending on the size of seed-id.
>

Maybe you can add that in this sentence to make that clearer.


> [...]
> >
> >   When receiving a new multicast packet, an MPL forwarder first
> >   utilizes proactive propagation to forward the MPL multicast packet.
> >   Proactive propagation reduces dissemination latency since it does not
> >   require discovering that neighboring devices have not yet received
> >   the MPL multicast packet.  MPL forwarders utilize proactive
> >   propagation for newly received MPL multicast packets since they can
> >   assume that some neighboring MPL forwarders have yet to receive the
> >   MPL multicast packet.  After a limited number of MPL multicast packet
> >   transmissions, the MPL forwarder may terminate proactive propagation
> >   for the MPL multicast packet.
> >
> >   An MPL forwarder may optionally use reactive propagation to continue
> >   the dissemination process with lower communication overhead.  With
> >   reactive propagation, neighboring MPL forwarders use ICMPv6 MPL
> >   messages to discover new MPL multicast messages that have not yet
> >   been received.  When discovering that a neighboring MPL forwarder has
> >   not yet received a new MPL multicast packet, the MPL forwarder
> >   enables proactive propagation again.
> >
> > UH> There is not a lot of RFC2119 language in the above. Or is that
> > defined later? Is this above section more like an introduction?
>
> This is more like an intro.  Would you prefer to see this moved to the
> overview section?
>

Yes.



> [...]
> >    Adhering to
> >   Section 5 of RFC 6206 [RFC6206], this document defines the following:
> >
> >   o  This document defines a "consistent" transmission for proactive
> >      propagation as receiving an MPL multicast packet that has the same
> >      MPL seed identifier and sequence number as a buffered MPL packet.
> >
> >   o  This document defines an "inconsistent" transmission for proactive
> >      propagation as receiving an MPL multicast packet that has the same
> >      MPL seed identifier, the M flag set, and has a sequence number
> >      less than the buffered MPL multicast packet's sequence number.
> >
> >   o  This document does not define any external "events".
> >
> >   o  This document defines both MPL multicast packets and ICMPv6 MPL
> >      multicast packets as Trickle messages.  These messages are defined
> >      in the sections below.
> >
> > UH> I don't see the term Trickle message used anywhere else.
>
> Used in RFC 6206.
>


A citation would help.



> [...]
>
> 5.5.  Transmission of ICMPv6 MPL Messages
> >
> >   The MPL forwarder generates and transmits a new ICMPv6 MPL message
> >   whenever Trickle requests a transmission.
> >
> > UH> So for each data packet there would be a new ICMPv6 message?
> > Wouldn't that create a lot of overhead?
>
> Nope.  The ICMPv6 message is a list of sliding windows.
>


Okay, I guess I am not quite clear yet on how much bandwidth the ICMPv6
messages would consume (how often they are sent etc) in relation to the
data traffic.




>
> > UH> To which address is the ICMP message sent? On which interface?
>
> Destination Address is specified in Section 4.2.  Sent on all interfaces
> that are used for forwarding MPL multicast packets.
>

Could be helpful to point to that section here.
 [...]


> >   When an MPL forwarder determines that it has at least one buffered
> >   MPL multicast packet that has not yet been received by a neighbor,
> >   the MPL forwarder resets the Trickle timer associated with reactive
> >   propagation.  Additionally, for each buffered MPL multicast packet
> >   that should be transferred, the MPL forwarder MUST reset the Trickle
> >   timer and reset e to 0 for proactive propagation.  If the Trickle
> >   timer for proactive propagation has already stopped execution,
> >
> > UH> Which timer? I thought there is one timer per packet in the
> > proactive mode?
>
> How about:
>
> "the Trickle timer(s) associated with the buffered packet(s) and reset e
> associated with the buffered packet(s) to 0 for proactive propagation".
>

Okay. That brings me to a point you mentioned above, the constant state
requirement. It seems there is a timer for each packet in proactive mode.
Wouldn't that mean the state requirement for these timers is O(n) for n
packets? Or are the timers bound by the size of the sliding window?


What is your plan regarding the security considerations section? Will that
be added in the next revision?


Best
Ulrich