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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Wed, 11 Mar 2020 06:19:21 -0700

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?

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.

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?

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

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"/

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

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

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?

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.

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 18 Mar 2020 12:29:51 +0100

Hello Mirija,

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

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

> "6P timeout value is calculated as
> ((2^MAXBE)-1)*MAXRETRIES*SLOTFRAME_LENGTH"

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

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

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

> will integrate into next revision.

> will integrate into next revision.

> will integrate into next revision.

> 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:

> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

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

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

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

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 18 Mar 2020 12:38:51 +0100

Sorry for the previous incomplete email...

On Wed, Mar 18, 2020 at 12:29 PM Tengfei Chang <[email-masked]>
wrote:

> > For quick response, yes, I like the propose to be neutral, will update
> it in the new revision.
> > will expand into next revision.
>
>>
>> 4) Sec 5.1.

>
> *A node implementing MSF SHOULD implement the behavior described in this
> section.Other schedule collisions handling algorithm can be an alternative
> of the algorithm proposed in this section.*
>
>>
>> 5) Sec 16:
> will update it in next revision. Thanks!

 > Thanks for pointing out. This will be updated in the next revision.

Dr. Tengfei, Chang

www.tchang.org/