Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

[Tengfei Chang <[e-mail]>]

Thanks a lot Yatch for reviewing the draft. I will reply inline:

On Tue, Jul 2, 2019 at 2:58 PM Yasuyuki Tanaka <[e-mail]>
wrote:

> Thank you, Tengfei and the other authors, for the update!
>
> Here are my comments:
>
> [Major] Negotiated RX cell (Section 4.6)
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.6
>
> If MSF is designed for regular upstream traffic, I don't think we need
> the negotiated RX cell that is introduced by this new version.
>
> I presume the purpose of the negotiated RX cell is, to have a
> collision-free channel directed from parent to child. The parent may
> have collisions on the autonomous TX cell to a node since children of
> the node also use the cell to transmit their frames. However, once the
> network converges, the children have negotiated TX cells to the
> node. The parent of the node will be the only one who uses the
> autonomous TX cell until a topological change happens.
>
> I would rather keep unused cells in the slotframe for negotiated TX
> cells to handle "regular upstream traffic" instead of using some of
> them for negotiated RX cells (to receive frames from the parent).
>
> I'm looking forward to seeing Tengfei's evaluation results, by the way
> :-)
>

I think the purpose is indeed trying to add support for downstream traffic.
I current doesn't have a strong option on this.


>
> [Minor] AutoTxCell usage (Section 3)
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-3
>
> Sorry for bringing this again and again, but *in general*, L2/TSCH
> layer has no idea about its upper layers. Although you can implement a
> 6TiSCH stack in which TSCH is aware of upper layer contents of a frame
> to transmit, that may not be always the case. That is, the second
> bullet point, starting with "frame is used for...", may not be able to
> be implemented.
>
> In this sense, applying "MUST" to the second bullet point seems too
> strict.
>
> draft> AutoTxCell is not permanent in the schedule but added/deleted on
> draft>    demand when there is a frame to sent.  Throughout the network
> draft>    lifetime, nodes MUST maintain the autonomous cells as follows:
> draft>
> draft>    o  Add an AutoTxCell to the layer 2 source address which is
> indicated
> draft>       in a frame when:
> draft>
> draft>       *  there is no 6P negotiated Tx cell in schedule for that
> frame to
> draft>          transmit, and
> draft>       *  the frame is used for protocol management purposes , such
> as
> draft>          Join Request/Response, 6P Request/Response and any
> link-local
> draft>          communication for RPL routing control.
>

Hmm, it only requires read access from other layers right? It could be
implemented. But I agree MUST is too strict.  I just removed the MUST from
the sentence.

>
>
> [Minor] Unprotected frames on negotiated cells? (Section 5.1)
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-5.1
>
> draft>   Both NumCellsElapsed and NumCellsUsed counters can be used to
> draft>   negotiated cells with cell option TX=1 or Rx=1.  All the frames
> used
> draft>   for increasing/decreasing the counters MUST be encrypted or
> draft>   decryptable with the key get from joining process.
>
> Will we have unprotected frames transmitted on negotiated TX/RX cells,
> which are expected to be scheduled with *joined* nodes? I'm not sure
> why the last sentence is necessary...
>
>
Yes, it's removed in the next version.


>
> [Minor] Length of CellList (Section 8)
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-8
>
> What should a node do when it receives a CellList shorter than 5?
> Return RC_ERR_CELLLIST?
>
> draft> 8.  Rules for CellList
> draft>
> draft>    MSF uses 2-step 6P Transactions exclusively.  6P Transactions are
> draft>    only initiated by a node towards its preferred parent.  As a
> result,
> draft>    the cells to put in the CellList of a 6P ADD command, and in the
> draft>    candidate CellList of a RELOCATE command, are chosen by the node
> draft>    initiating the 6P Transaction.  In both cases, the same rules
> apply:
> draft>
> draft>    o  The CellList SHOULD contain 5 or more cells.
>

 Nothing happens actually, the 6P will process with less than 5 candidate
cells.
Though the SHOULD here is a little strong, I changed the SHOULD to
RECOMMENDED, to make it less constrain.

>
>
> [Trivial] Section 3. Autonomous Cells
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-3
>
> draft>  o  The AutoRxCell MUST always remain scheduled.
>
> *Always* is ambiguous. A node cannot schedule an AutoRxCell until it's
> get synchronized, when the length of slotframe 1 is available.
>

Yes, changed to " The AutoRxCell MUST always remain scheduled after
synchronized"

>
>
> [Trivial] nits / editorial
>
> - "AutoUpCells" is still there
> - s/behvaior/behavior/
> - s/boostrap/bootstrap/
> - s/sheduling/scheduling/
> - s/negoitated/negotiated/
> - s/neogtiated/negotiated/
> - s/transcation/transaction/
> - s/calulated/calculated/
>

Thanks for the typos list! They will be fixed in the next version.

>
> That's all!
> Yatch
>
>

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria