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

[Tengfei Chang <[e-mail]>]

Sorry for the previous incomplete email...

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

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


>
> *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:
>> "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."
>>
>
> will update it in next revision. Thanks!

>
>> 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.
>>
>
 > Thanks for pointing out. This will be updated in the next revision.

>
>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
>
> --
> ——————————————————————————————————————
>
> Dr. Tengfei, Chang
> Postdoctoral Research Engineer, Inria
>
> www.tchang.org/
> ——————————————————————————————————————
>


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

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

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