Hi Atis, Thank you for reviewing and giving the comments! I will reply them below.
For your comments: *- There is still one reference left to the number 16 as the max number of channels (which 2.4 GHz frequency-band-specific). It's in the formula `channelOffset(MAC) = hash(EUI64, 16)`. This may conflict with the intention expressed previously in the text, where you say that "the coordinates are computed to distribute the cells across all channel offsets" (i.e. not exactly 16 channel offsets)* TC: Yes, we will replace the 16 by NUM_CH_OFFSET and added it to the recommended value table. *- Have you considered suggesting that the implementers to prioritize 6top packets over data packets?* TC: Sure, we may add a rule about the application packet is not allowed to send on autonomous cell, this will separate the traffic between 6P and application. Then prioritizing 6P is not necessary. *- Have you considered providing a recommended value for MAX_NUMCELLS or discussing how to select it?* TC: Maybe we will discuss it. TC: Generally, to quick react the changes of traffic, a small size of MAX_NUMCELLS is preferred, otherwise, a large value is preferred. For more details, some investigation on this is required. A recommendation value or discussion will come after that. TC: I will fixed the other comments in the next version. Tengfei On Tue, Apr 9, 2019 at 1:06 PM Atis Elsts <atis.el...@gmail.com> wrote: > Hello Tengfei and the 6tisch community, > > I'm happy to see the frame pending bit removed and other big improvements > in clarity and functionality. > > Following up on my other previous comments, > - There is still one reference left to the number 16 as the max number of > channels (which 2.4 GHz frequency-band-specific). It's in the formula > `channelOffset(MAC) = hash(EUI64, 16)`. This may conflict with the > intention expressed previously in the text, where you say that "the > coordinates are computed to distribute the cells across all channel > offsets" (i.e. not exactly 16 channel offsets) > - Have you considered suggesting that the implementers to prioritize 6top > packets over data packets? > - Have you considered providing a recommended value for MAX_NUMCELLS or > discussing how to select it? > > Minor new comments: > > - The parameter KA_PERIOD from the recommended values is not referenced in > the main text. > > - There are a number of typos in the text, for example: > Boradcast -> Broadcast > maxmium -> maximum > calcualted -> calculated > bewteen -> between > > Best regards, > Atis > > > > On Tue, Apr 9, 2019 at 7:06 AM Tengfei Chang <tengfei.ch...@gmail.com> > wrote: > >> Dear all, >> >> A new version of "draft-ietf-6tisch-msf" is just published at here: >> https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt >> >> This version mainly resolved the issues presented during IETF 104 meeting. >> I would like to mention one of the main changes in this version is we >> removed the frame pending bit feature. >> >> It's for two reasons: >> - it will influence the "adapt to traffic" strategy of MSF. >> - the "adapt to traffic" strategy has the ability to handle burst traffic >> by using a smaller MAX_NUMCELLS >> >> Now we are calling for reviews on the new version of MSF! >> Any comments and feedback are appreciated! >> >> Tengfei >> >> >> >> -- >> Chang Tengfei, >> Postdoctoral Research Engineer, Inria >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> > > -- > Dr. Atis Elsts > Researcher, Institute of Electronics and Computer Science (EDI) > Dzerbenes str. 14, Riga, LV-1006 > > -- Chang Tengfei, Postdoctoral Research Engineer, Inria
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
