Re: [6tisch] Mirja Kühlewind's No Objection on draft-ietf-6tisch-msf-12: (with COMMENT)

[Tengfei Chang <[e-mail]>]

Hello Mirija,

Thanks for the comments on the draft!
I replied inline starting with '> '

On Wed, Mar 11, 2020 at 2:19 PM Mirja Kühlewind via Datatracker <
[e-mail]> wrote:

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-6tisch-msf-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I agree with Roman's discuss that the relation to SAX-DASFAA should be
> clarified and if this is actually needed for interoperability (as stated at
> some point in the text) it seems this should be part of the body of the
> document. Or what are the requirements for interoperability? What can be
> changed in the "example" algorithm and what not?
>

> The reference for SAX has been moved into normative reference section as
suggested by Roman.
> The requirements for interoperability are the identical parameters for
the SAX algorithm
> The proposed recommend values of those parameters are presented in
the Appendix B.
> We still believe put those those info in the Appendix B is proper.
> If we put the SAX algorithm into the main content of the draft, it may
read like jumping out from the main MSF content and going to a side
knowledge of it.
> We believe it is enough to like the reader knowing it's a hashing
algorithm with node EUI64 address as input, used by MSF.

>
> Two small technical points:
> 2) Sec 9; mostly double-checking as you probably know better than me:
> "6P timeout value is calculated as
> ((2^MAXBE)-1)*MAXRETRIES*SLOTFRAME_LENGTH"
> Often you calculate such a value and then multiply by 2 (or something) to
> be on
> the safe side, as there could be e.g. processing delays in the receiving
> node.
> I assume the assumption here is that you always need to get the response
> in the
> same/after one slot (?). If that is true, I guess the calculation is fine.
> But
> wanted to check that there cannot be any additional unknown delays here.
>

> Thanks for the comments. The calculation of TIMEOUT is targeting to the
worst case, not average.
> So a multiply with 2 is not necessary.
> In most case, the 6P response is sent by through the autonomous cell,
which is the same slot, as you guessed.

>
> Further, these values come a bit out of nothing. Where are  MAXBE and
> MAXRETRIES defined? And if you have an exponential backoff that will stop
> retrying after MAXRETRIES why do you need also a timeout in addition to
> that?
>

> When Mote A sent a 6P request to Mote B, the 6P Timeout timer starts on
Mote A side.
> On Mote B side, it will try to send out the 6P response within the
MAXRETRIES.
> Mote A does not know when the maxretires reached, hence it needs the 6P
Timeout to be notified.

>
> 2) Sec 16:
> "   MSF adapts to traffics containing packets from IP layer.  It is
>    possible that the IP packet has a non-zero DSCP (Diffserv Code Point
>    [RFC2597]) value in its IPv6 header.  The decision whether to hand
>    over that packet to MAC layer to transmit or to drop that packet
>    belongs to the upper layer and is out of scope of MSF.  As long as
>    the decision is made to hand over to MAC layer to transmit, MSF will
>    take that packet into account when adapting to traffic."
> Why should a packet be dropped based on it DSCP...? Maybe be a bit more
> neutral
> here like: "   MSF adapts to traffics containing packets from IP layer.
> It is
>    possible that the IP packet has a non-zero DSCP (Diffserv Code Point
>    [RFC2597]) value in its IPv6 header.  The decision how to handle
>    belongs to the upper layer and is out of scope of MSF. As long as
>    a decision is made to hand over to MAC layer to transmit, MSF will
>    take that packet into account when adapting to traffic."
>

> For quick response, yes, I like the propose to be neutral, will update it
in the new revision.
> To answer your question why the packet is dropped based on DSCP, I image
a DoS attack make multiple of DSCP with non-zero  value occupied in the
sending queue and overwhelm the buffer.
> However, it could be handle by some mechanism to quarantine them.

>
> Some small editorial nits/comments:
> 1) Sec 1:
> - Maybe expand RPL on first occurrence.
> - s/is called as a "MSF session"/is called a "MSF session"/
>

> will integrate into next revision.

>
> 2) Sec 2
> - s/one of more slotframes/one or more slotframes/
>

> will integrate into next revision.

>
> 3) Sec 4.4
> - Please expand JRC on first occurrence. Maybe add a glossary at the
> beginning?
>

> will integrate into next revision.

>
> 4) Sec 5.1.
> "   A node implementing MSF MUST implement the behavior described in this
>    section."
> Not sure if that sentence brings any additional value because that's what
> specs
> are for. But I guess it also doesn't hurt. And respectively I find the
> statement in 5.3 rather confusing "   A node implementing MSF SHOULD
> implement
> the behavior described in
>    this section.  The "MUST" statements in this section hence only apply
>    if the node implements schedule collision handling."
> I'm not fully sure what this even means now. Can you explain? Can you maybe
> rather provide some text to explain when it could/MAY be appropriate to not
> implement it?
>

> Yes, we agree it is not clear.
> The 'SHOULD' in the text is trying to state that the handling schedule
collisions algorithm proposed in MSF draft is one of  those algorithms.
> Any implementer can choose other algorithm to handle the collision as an
alternative.
> The 'MUST' in the text is trying to state, if the implementer decides to
implement the algorithm proposed in the draft, it must follow the
description in the section.
> I agree the 'MUST' in this case sounds redundant.

The text will be replaced as following:


> 5) Sec 16:
> "The implementation at IPv6 layer
>    SHOULD ensure that this join traffic is rate-limited before it is
>    passed to 6top sublayer where MSF can observe it. "
> Maybe be less indirect here:
> "The implementation at IPv6 layer
>    SHOULD rate-limited join traffic before it is
>    passed to 6top sublayer where MSF can observe it."
>
> Also this wording is a bit unclear:
> " How this rate limit is set is out of scope of MSF."
> Maybe
> " How this rate limit is implemented is out of scope of MSF.
>
> 6) "Appendix A.  Contributors" -> Usually Contributors is an own section
> in the
> body of the document and not part of the appendix but I'm sure the RFC
> editor
> will advise you correctly.
>
>
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——————————————————————————————————————

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——————————————————————————————————————