Subject: Re: [6tisch] 6P comments

From: Qin Wang <[email-masked]>
Date: Wed, 7 Jun 2017 20:46:51 +0000 (UTC)

Hi Jonathan,
Sorry, in previous email I missed your comment about section 4.3.5.
Your question is: if the SF manages several slotframes, when retrieving the LIST, how to differentiate them, since they appear as a tuple (slotOffset,channelOffset). My question is if it is worthy to make the differentiation when receiving all the cells. Or this will be handled by the SF? IMO an example will be good. 
According to my understanding, SF0 uses Metadate to express slotframe ID, see the description of Metadata in 6P draft. Thus, it is SF0 who handles this. For example, SF0 can define in this way: if specific slotframe ID in Metadata, then the Cells in the CellList of Response belong the specific slotframe; if setting some value like FF in Metadata to say all of slotframes, then the CellList of Response will include all of cells scheduled between the two neighbors. But, this should be defined and explained in SF0 draft. What do you think?
Thanks Qin    

 On Wednesday, June 7, 2017 3:54 PM, Qin Wang <[email-masked]> wrote:

 Hi Jonathan,
Thank you very much for your review. Please see inline.
Qin

    On Wednesday, June 7, 2017 11:21 AM, Jonathan Muñoz <[email-masked]> wrote:

 Dear 6P authors, W.G,
I read the 6top Protocol draft - v05, and I find it very clear. I have some questions and few comments. Hopefully you'll find them useful.  
Best,
Jonathan Munoz
------------------------------ ------------------------------ -------------------------->Section 4.1: "If no dedicated cells are scheduled between nodes A and B, shared   cells MAY be used. -> Is there another option? if not, shouldn't say MUST?[Qin]: I think there is another option, i.e. do nothing if no dedicated cells are scheduled between node A and node B. What do you think?
->Section 4.3.2:     "  All cells in the CellList MUST already be scheduled between the two nodes and must match the CellOptions field. If node A puts cells in its CellList that are not already scheduled between the two nodes and match the CellOptions field, node B replies with a RESET return code"
   Section 4.3.3:     "Upon receiving the request, node B's SF verifies that all the cells in the Relocation CellList are indeed scheduled with node A, and are associate the options specified in the CellOptions field. If that check fails, node B MUST send a 6P Response to node A with return code CELLLIST_ERR."
Both errors give a different response but it looks to me that they have the same source -mismatch in their schedule-. Is it ok?
[Qin] You are right. We change error code in 4.3.2 to CELLLIST_ERR.
->Section 4.3.5:      if the SF manages several slotframes, when retrieving the LIST, how to differentiate them, since they appear as a tuple (slotOffset,channelOffset). My question is if it is worthy to make the differentiation when receiving all the cells. Or this will be handled by the SF? IMO an example will be good.
->Figures: 17, -6P COUNT Response and Confirmation-                19, -6P LIST Response and Confirmation-                21, -6P CLEAR Response and Confirmation-
    Will these transaction have a confirmation message? it seems to me they are a 2-step transactions, always.
[Qin] accepted.
-> Sequence Number: will it increase +1 despite the failure of the previous transaction?
[Qin]: I think so. Is there any particular reason for not doing in this way?

------------------------------ ------------------------------ -------------------------   

-- 
Jonathan MuñozPhD student at Gridbee Communications & INRIA Paris+33 (0) 6 59 05 93 83_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

   _______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Jonathan Muñoz <[email-masked]>
Date: Thu, 8 Jun 2017 08:32:22 +0200

Hello Qin,

Thanks for your reply. Please see inline,

Regards,
JM

2017-06-07 22:46 GMT+02:00 Qin Wang <[email-masked]>:

> Your question is: if the SF manages several slotframes, when retrieving
> the LIST, how to differentiate them, since they appear as a tuple
> (slotOffset,channelOffset). My question is if it is worthy to make the
> differentiation when receiving all the cells. Or this will be handled by
> the SF? IMO an example will be good.
>
> According to my understanding, SF0 uses Metadate to express slotframe ID,
> see the description of Metadata in 6P draft. Thus, it is SF0 who handles
> this. For example, SF0 can define in this way: if specific slotframe ID in
> Metadata, then the Cells in the CellList of Response belong the specific
> slotframe; if setting some value like FF in Metadata to say all of
> slotframes, then the CellList of Response will include all of cells
> scheduled between the two neighbors. But, this should be defined and
> explained in SF0 draft. What do you think?
>

> [JM]: so this is left for the SFs to manage what information to ask for.
> Good.
>

> Thanks
> I read the 6top Protocol draft - v05, and I find it very clear. I have
> some questions and few comments. Hopefully you'll find them useful.
>
> Best,
>
> Jonathan Munoz
>
> ->Section 4.1: "If no dedicated cells are scheduled between nodes A and B,
> shared
>    cells MAY be used. -> Is there another option? if not, shouldn't say
> MUST?
> [Qin]: I think there is another option, i.e. do nothing if no dedicated
> cells are scheduled between node A and node B. What do you think?
>
[JM]: I think that if this is the description of the 6P Transactions, they
> either happen in a dedicated cell or a shared cell. IMO, doing nothing is
> always an option but it won't then classify as a 6P Transaction.
>

>
> ->Section 4.3.2:
>      "  All cells in the CellList MUST already be scheduled between the
> two nodes and must match the CellOptions field. If node A puts cells in its
> CellList that are not already scheduled between the two nodes and match the
> CellOptions field, node B replies with a RESET return code"
>
>    Section 4.3.3:
>      "Upon receiving the request, node B's SF verifies that all the cells
> in the Relocation CellList are indeed scheduled with node A, and are
> associate the options specified in the CellOptions field. If that check
> fails, node B MUST send a 6P Response to node A with return code
> CELLLIST_ERR."
>
> Both errors give a different response but it looks to me that they have
> the same source -mismatch in their schedule-. Is it ok?
>
> ->Section 4.3.5:
>      if the SF manages several slotframes, when retrieving the LIST, how
> to differentiate them, since they appear as a tuple
> (slotOffset,channelOffset). My question is if it is worthy to make the
> differentiation when receiving all the cells. Or this will be handled by
> the SF? IMO an example will be good.
>
> ->Figures: 17, -6P COUNT Response and Confirmation-
>                 19, -6P LIST Response and Confirmation-
>                 21, -6P CLEAR Response and Confirmation-
>
> [JM]: perfect, thanks for clarifying.
> Jonathan Muñoz
> PhD student at Gridbee Communications & INRIA Paris
> +33 (0) 6 59 05 93 83

-- 
Jonathan Muñoz
PhD student at Gridbee Communications & INRIA Paris
+33 (0) 6 59 05 93 83 <+33%206%2059%2005%2093%2083>