Sorry for the previous incomplete email... On Wed, Mar 18, 2020 at 12:29 PM Tengfei Chang <tengfei.ch...@gmail.com> 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 < > nore...@ietf.org> 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 >> 6tisch@ietf.org >> 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/ ——————————————————————————————————————
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
