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

[Tengfei Chang <[e-mail]>]

After talking with Yatch, I realize I misunderstand the first comments:
(Yatch, please correct me if I said something wrong.)

For the join request/response, they are only sent on autonomous cell at the
first hop, after that, they are OK to sent on managed cell since the node
will only recognize the packet as IPv6.
For the 6P request/response,

There are two aspects we are concerning:

1. standard-complaint : now I am concerning it may be not
standard-complaint with IEEE802.15.4. The TSCH MAC layer shouldn't be able
to aware whether it's 6P or not and what is the type of it.
2. performance: we agreed that either allowing send 6P on managed cell or
not will work. Put the standard-complaint issue on the side, it's only
performance concern.

What I consider is if a 6P cell inconsistency happens, sending 6P on
managed cell may consume the number of re-transmission chance.

For example, node A has a Tx cell to node B, but node B doesn't have a Rx
cell to node A.
If node A wants to add another cell to node B by issuing a 6P ADD request,
the 6P ADD request
If 6P ADD request send on autoUpCell successfully, then there is no problem.
If not,  the ADD request will be sent later on the Tx cell but will be
failed because of inconsistent.
If there is other managed Tx Cell, the performance will be better.
If not, the ADD request will try to send on autoUpCell again but because of
backoof algorithm, it will skip it and try to send on the inconsistent Tx
cell again.
The number of re-transmission will be consumed on the Tx cell and probably
failed finally.

As a conclusion, making sure only regulating the traffic on autonomous cell
is standard complaint or not is primary.
I want to have more comments on this.
@Tero, @Pat, @pascal any comment on this?

Tengfei


On Wed, Apr 17, 2019 at 4:58 PM Tengfei Chang <[e-mail]>
wrote:

> Hi Yatch,
>
> Thanks for the reviewing! I will reply your comments inline.
>
> On Tue, Apr 9, 2019 at 2:03 PM Yasuyuki Tanaka <[e-mail]>
> wrote:
>
>> Thank you, the authors!
>>
>> I confirmed most of my comments to the previous version have been
>> addressed. It reads better :-)
>>
>> Here are my comments: two comments are major, the rest are minor.
>>
>>
>> [major: usage of the autonomous cell and the managed cell]
>>
>> The draft specifies rules what type of frames MUST be sent over the
>> autonomous cell. How can we implement the rules on top of TSCH MAC
>> defined by IEEE802.15.4?
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
>> draft-03>  The traffic on the autonomous cells are scheduled as:
>> draft-03>
>> draft-03>  o  Join Request packets and 6P ADD/DELETE Request frames to the
>> draft-03>     node's Join Proxy or its RPL routing parent MUST be sent on
>> draft-03>     AutoUpCell.
>> draft-03>  o  Join Response packets and 6P ADD/DELETE Response frames to
>> the
>> draft-03>     pledge or its RPL routing child MUST be sent on
>> AutoDownCell.
>> draft-03>  o  6P RELOCATE Request frames to the node's RPL routing child
>> MUST be
>> draft-03>     sent on AutoDownCell.
>> draft-03>  o  6P RELOCATE Response frames to its RPL routing parent MUST
>> be sent
>> draft-03>     on AutoUpCell.
>>
>
> TC: For implementing, it requires some flag for the frame to mark as what
> type of 6P frames.
> TC: I agree that there are other frames that should be able to send on the
> autonomous cell according to IEEE802.15.4 standards.
> TC: Here is to limit the type frames on one cell but it doesn't break what
> defined in IEEE802.15.4 standards, IMO.
>
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
>> draft-03>   Adding/removing/relocating cells involves exchanging frames
>> that
>> draft-03>   contain 6P commands.  All 6P Request frames to its parent
>> MUST be
>> draft-03>   sent on the AutoUpCell All 6P Response frames to non-parent
>> neighbor
>> draft-03>   MUST be sent on AutoDownCell.
>>
>> At draft-ietf-6tisch-msf-02, the autonomous cell and the managed cell
>> to the same neighbor are used without distinction. This is totally
>> fine and straightforward. Why do we need the change to this part?
>>
>
> TC: this is to avoid the failure of 6P frames on inconsistent managed
> cell, for example, the node has a Tx cell to parent but the parent doesn't
> have the RX cell.
> TC: Though, it will be resolved at next 6P transaction (two transactions
> actually), it will be underperformance.
>
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5.1
>> draft-02>   Autonomous cells are used indistinguishably
>> draft-02>   together with dedicated cells, for broadcast or unicast
>> traffic with
>> draft-02>   the target neighbor.  The procedure to remove autonomous
>> cells is
>> draft-02>   described in Section 3.
>>
>> To my understandings, TSCH MAC selects a cell (link) to transmit a
>> frame seeing macTxType, macLinkType, and macNodeAddress of the cell,
>> which are defined in section 8.4.2.2.2 of IEEE802.15.4-2015. TSCH MAC
>> cares only the destination MAC address and the frame type of a TX
>> frame, doesn't it?
>>
>> TC: It does in IEEE802.15.4 standard.
> TC: I am just not considering instead of caring only the destination MAC
> address and frame type, caring about more parameters is not a violation of
> standard.
> TC: Though, just in my opinion.
>
>>
>> [major: some confusions in Section 5]
>>
>> We don't need to maintain NumCellsElapsed and NumCellsUsed for RX
>> cells because managed cells have always only TX=1.
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
>> draft-03>   NumCellsElapsed :  Counts the number of managed cells that
>> have
>> draft-03>       elapsed since the counter was initialized.  This counter
>> is
>> draft-03>       initialized at 0.  Each time the TSCH state machine
>> indicates
>> draft-03>       that the current cell is a managed cell to the preferred
>> parent,
>> draft-03>       NumCellsElapsed is incremented by exactly 1, regardless of
>> draft-03>       whether the cell is used to transmit/receive a frame.
>>
>> "to transmit/receive a frame" in the last sentence should be replaced
>> with "to transmit a frame", and
>>
>> draft-03>   Both NumCellsElapsed and NumCellsUsed counters can be used to
>> cell
>> draft-03>   with cell option TX=1 or RX=1.
>>
>> "with cell option TX=1 or RX=1" should be replaced with "with cell
>> option TX=1"?
>>
>> Another thing is related to what Fabrice pointed out. There is
>> something wrong in text about the RELOCATE operation. Since NumTx and
>> NumTxAck are the key counters for the RELOCATE operation, a RELOCATE
>> request is never issued for an RX cell. Then, the direction in the
>> following text is opposite...
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
>> draft-03>  o  6P RELOCATE Request frames to the node's RPL routing child
>> MUST be
>> draft-03>     sent on AutoDownCell.
>> draft-03>  o  6P RELOCATE Response frames to its RPL routing parent MUST
>> be sent
>> draft-03>     on AutoUpCell.
>>
>
> TC: yes, accepted this comment.
> TC: As replied to Fabrice, I will remove the RX=1 cell case for the
> adapting traffic strategy in next version..
>
>>
>> One more thing:
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.3
>> draft-03>  4.  For any other cell, it compares its PDR against that of
>> the cell
>> draft-03>      with the highest PDR.  If the different is less than
>> draft-03>      RELOCATE_PDRTHRES, it triggers the relocation of that cell
>> using
>> draft-03>      a 6P RELOCATE command.
>>
>> - s/different/difference/
>> - s/less than/larger than/ ??
>>
>> Can you check the entire text in Section 5?
>>
>
> TC: sure. Sorry for the confusing! Will be clarified in next version.
>
>>
>>
>> [minor comment #1]
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-2
>> draft-03>   For example, a Trickle Timer defined in [RFC6550] MAY be
>> draft-03>   applied on DIOs.
>>
>> Do we need "MAY" here? If you implement RFC6550, DIO is automatically
>> controlled by Trickle Timer.
>>
>> TC: yes, it's a requirement.
>
>>
>> [minor comment #2]
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
>> draft-03>   MUST use the hash function SAX [SAX-DASFAA].  The coordinates
>> are
>> draft-03>   computed to distribute the cells across all channel offsets,
>> and all
>> draft-03>   but the first time offsets of Slotframe 1.  The first time
>> offset is
>> draft-03>   skipped to avoid colliding with the minimal cell in Slotframe
>> 0.
>>
>> s/time offset/slot offset/
>>
>> TC: Thanks! I will go over the draft to make sure this is consistent.
>
>>
>> [minor comment #3]
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
>> draft-03>    o  slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - 1)
>> draft-03>    o  channelOffset(MAC) = hash(EUI64, 16)
>> draft-03>
>> draft-03>    The second input parameter defines the maxmium return value
>> of the
>> draft-03>    hash function.
>>
>> The second input should be "the maximum return value plus 1", which
>> is the parameter 'T' of SAX.
>>
>
> TC: That's correct! Will be fixed.
>
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#appendix-B
>> draft-03>   In MSF, the T is replaced by the length slotframe 1.  String
>> s is
>> draft-03>   replaced by the mote EUI64 address.  The characters of the
>> string c0,
>> draft-03>   c1, ..., c7 are the 8 bytes of EUI64 address.
>>
>> This may be misleading. The first sentence could be...
>>
>>   For slotOffset(), T is the length of the slotframe 1. For
>>   channelOffset(), T is the number of available channels.
>>
>> TC: Will be applied in next verison. Thanks!
>
>>
>> [minor comment #4]
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
>> draft-03>   The second input parameter defines the maxmium return value
>> of the
>> draft-03>   hash function.  There are other optional parameters defined
>> in SAX
>> draft-03>   determines the performance of SAX hash function.  Those
>> parameters
>> draft-03>   could be broadcasted in EB frame or pre-configured.
>>
>> What parameters...? The parameters to configure are be h0, l_bit,
>> and r_bit, I believe.
>>
>
> TC: yes, I didn't say that but presented in the example section. Maybe I
> should mention there though.
>
>>
>> By the way, s/maxmium/maximum/
>>
>
> TC: will be fixed! Thanks!
>
>>
>>
>> [minor comment #5]
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
>> draft-03>   Implementors MAY choose to create the same counters for each
>> draft-03>   neighbor, and add them as additional statistics in the
>> neighbor
>> draft-03>   table.
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.3
>> draft-03>   Implementors MAY choose to maintain the same counters for each
>> draft-03>   managed cell in the schedule.
>>
>> For what purposes? Do we need these sentences?
>>
>
> TC: For parent selection. In case parent switching happens, those counters
> can record the link quality of previous parent for future parent selection.
>
>>
>>
>> [minor comment #6]
>> Want to have test vectors of SAX! :-)
>>
>> TC: like givem a node EUI64 address, to have the slotoffset and choffset?
> we could.
>
>>
>> [minor comment #7]
>>
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
>> draft-03>       *  If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to
>> add a
>> draft-03>          single cell to the preferred parent
>> draft-03>       *  If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to
>> remove a
>> draft-03>          single cell to the preferred parent
>>
>> It would be better to put "managed" there:
>>
>> proposed>       *  If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to
>> add a
>> proposed>          single managed cell to the preferred parent
>> proposed>       *  If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to
>> remove a
>> proposed>          single managed cell to the preferred parent
>>
>
> TC: will put in next version!
>
>>
>>
>> [minor comment #8]
>>
>> s/Tx Cell/TX cell/
>> s/Tx cell/TX cell/
>>
>
> TC: Will go through the text in the next version about the consistency!
> Thanks!
>
>>
>> Best,
>> Yatch
>>
>> _______________________________________________
>> 6tisch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
>
> --
> Chang Tengfei,
> Postdoctoral Research Engineer, Inria
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria