Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03

[Tengfei Chang <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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
>> [e-mail]
>> 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