Hi Yatch, Thanks for the reviewing! I will reply your comments inline.
On Tue, Apr 9, 2019 at 2:03 PM Yasuyuki Tanaka <yasuyuki.tan...@inria.fr> 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 > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- Chang Tengfei, Postdoctoral Research Engineer, Inria
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
