Subject: [6tisch] 6top sublayer draft review/comments

From: Maria Rita PALATTELLA <[email-masked]>
Date: Thu, 20 Mar 2014 12:23:00 +0000

Dear Qin, Xavi
Please find below some comments and minor details to be fixed, as result of my review of the 6top sublayer draft.
Thank you in advance for going through all of them :)
Best regards,
Maria Rita

1.  In the 6top draft you state that implementations can use this set of commands (i.e., those offered by 6top), or any equivalent alternative.
I was wondering if these can create interoperability problems. Because it could happen that two nodes do not speak the same language, unless, we assume that all the nodes in the network will be using the same set of commands (either the 6top ones, or another proprietary set).

2.      6top can be configured to monitor the cells it has scheduled in order to detect cells with poor performance. It can automatically re-allocate those cells inside the TSCH schedule.

While  reading this, I was afraid that such monitoring mechanism could conflict with OTF, but actually it should provide to OTF the info needed for estimating the needed BDW.  Unlike 6top, OTF does not operate any cell re-allocation.  Such re-allocation, unlike the monitoring function,  may interference with OTF somehow, because while OTF is estimating the BDW and thus asking for adding/deleting soft cells, 6top in the meantime, may have planned to re-allocate some cells.

We will need to think about this and discuss if we should assign priority to different actions,   something like this: 6top first checks if there are requests from OTF, if not, then, 6top can re-allocate/move the soft cells.

3.  Pag. 8: Data Transfer Model. The TSCH MAC layer is decoupled from the upper layer; the interaction between the upper layer and TSCH is asynchronous.  This means that the MAC layer executes a schedule and checks at each timeslot according to the type of cell, whether there is something...
   It is not clear to me what you mean with according to the type of cell. It should be clarified.

4.      The QoS policy enforced by 6top is out of scope.  As an example,   packets in higher priority queues could be transmitted before the  packets in lower priority queue.  As a result, when there is an   available broadcast/unicast cell, 6top checks the broadcast/unicast  queue with higher priority first. 6top continues this search until it  finds a broadcast/unicast packet, or finds that all of broadcast/ unicast queues are empty.
        It has to be specified the relationship between TRACKs and QUEUEs that is missing in the current version of the draft.

5.  6top deals with the allocation process by negotiation with the target node.  The command returns the list of created cells defined by (slotframe ID, slotOffset, channelOffset).  It fails if the required number of cells is higher than the available number of cells in the schedule. It fails if the negotiation with the target node fails. It fails if the LinkOption bitmap indicates that the cell(s) MUST be Hard.
As I have already stated in a previous email, it should be better to define what happen when the negotiation fails. It is important for implementation purpose. Moreover, I think that in some cases, if the requested number of soft cells N is not available, it could be better to allocate the few available (N-x) instead  of not allocating anything, and declare a failure... what do you think?

6.      For the REALLOCATE.softcell command, the upper layer specifies the slotframe ID, slotoffset, and channeloffset.
Why, the slotframe ID should be specified if (as the TrackID) is still the same, while moving the cell from a (timeoffset, channeloffset) to another one?

7.      6top Bandwidth IE

NumCell shall be set to the number of cells.  When BwIE is combined with the OpecodeID of Reserve Soft Cell Request, NumCell presents how many cells are required to reserve; and when BwIE is combined with the OpecodeID of Reserve Soft Cell Response, NumCell presents how many cells are reserved successfully.
It is not clear to me while the number of cells in the request msg should be different from the num of cells in the response msg. If the negotiation fails if the number of requested cells is not available, then, it means that the two numbers should be the same. Am I missing something?

8.      Sec, 4.1.1.8 6top Generic Schedule IE
   F=1 means the specified cells equals to what are listed in CellObjects, and F=0 means the specified cells equals to what are not listed in CellObjects.
Do you mean all the others in the schedule?

9.      Sec. 6.2 Actuation
The policy to generate the soft cell Maintenance command and the policy to generate Create/Delete soft cell commands is out of scope.

Do you agree that OTF can provide a policy AT LEAST for generating Create/Delete soft cell commands? Not sure, if it can provide support also to the Maintenance command. What do you think?

10.   Minor Comments

-        In the abstract, add support of hybrid scheduling (as clearly said in the rest of the draft)

-         Pag. 4 Intro. In a TSCH network, the MAC layer is not in charge of setting up the schedule that controls the connectivity graph of the network and the resources allocated to each cell in that topology.  This responsibility is left to the next-higher layer, defined in this document, called "6top". I guess you meant node, and NOT cell.

-         Pag 6, 2nd paragraph: They form a conceptual interface an upper layer can used -> use

-        Pag. 9 Figure Figure 2 -> and extra Figure (to be deleted)

-         Pag. 15 " For example, after neigotiation, node A and node B find a specifical cell" ->  negotiation, specific

-        Pag 17: indexd -> indexed; LikType as defined in in section -> an extra in

-        Pag. 19: why don't talking of slotframe size when talking of number of timeslots within a slotframe?

-         Pag. 40: sec. 4.1.1.6 Bandwidth IE (BwIE) defines the number of cells to be reserved or actually be reserved. -> actually been reserved.

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 20 Mar 2014 17:54:43 -0700

Quick suggestion: maybe the 6top sublayer authors could capture those
points in the tracker of the 6top-sublatyer repo?

On Thu, Mar 20, 2014 at 5:23 AM, Maria Rita PALATTELLA <
[email-masked]> wrote:

> Thank you in advance for going through all of them J
>
> Best regards,
>
> Maria Rita
>
>
>
> 1.  In the 6top draft you state that implementations can use this set of
> commands (i.e., those offered by 6top), or any equivalent alternative.
>
> I was wondering if these can create interoperability problems. Because it
> could happen that two nodes do not speak the same language, unless, we
> assume that all the nodes in the network will be using the same set of
> commands (either the 6top ones, or another proprietary set).
>
>
>
> 3.  Pag. 8: Data Transfer Model. The TSCH MAC layer is decoupled from the
> upper layer; the interaction between the upper layer and TSCH is
> asynchronous.  This means that the MAC layer executes a schedule and checks
> at each timeslot *according to the type of cell*, whether there is
> something...
>
> 4.      The QoS policy enforced by 6top is out of scope.  As an example,
>   packets in higher priority queues could be transmitted before the
>  packets in lower priority queue.  As a result, when there is an
>   available broadcast/unicast cell, 6top checks the broadcast/unicast
>  queue with higher priority first. 6top continues this search until it
>  finds a broadcast/unicast packet, or finds that all of broadcast/ unicast
> queues are empty.
>
>         It has to be specified the relationship between TRACKs and QUEUEs
> that is missing in the current version of the draft.
>
>
>
> 5.  6top deals with the allocation process by negotiation with the target
> node.  The command returns the list of created cells defined by (slotframe
> ID, slotOffset, channelOffset).  It fails if the required number of cells
> is higher than the available number of cells in the schedule. It fails if
> the negotiation with the target node fails. It fails if the LinkOption
> bitmap indicates that the cell(s) MUST be Hard.
>
> As I have already stated in a previous email, it should be better to
> define what happen when the negotiation fails. It is important for
> implementation purpose. Moreover, I think that in some cases, if the
> requested number of soft cells N is not available, it could be better to
> allocate the few available (N-x) instead  of not allocating anything, and
> declare a failure... what do you think?
>
>
>
> 6.      For the REALLOCATE.softcell command, the upper layer specifies
> the slotframe ID, slotoffset, and channeloffset.
>
> Why, the slotframe ID should be specified if (as the TrackID) is still the
> same, while moving the cell from a (timeoffset, channeloffset) to another
> one?
>
>
>
> 7.      6top Bandwidth IE
>
> NumCell shall be set to the number of cells.  When BwIE is combined with
> the OpecodeID of Reserve Soft Cell Request, NumCell presents how many cells
> are required to reserve; and when BwIE is combined with the OpecodeID of
> Reserve Soft Cell Response, NumCell presents how many cells are reserved
> successfully.
>
> It is not clear to me while the number of cells in the request msg should
> be different from the num of cells in the response msg. If the negotiation
> fails if the number of requested cells is not available, then, it means
> that the two numbers should be the same. Am I missing something?
>
>
>
>    F=1 means the specified cells equals to what are listed in
> CellObjects, and F=0 means the specified cells equals *to what are not
> listed in CellObjects.*
>
> The policy to generate the soft cell Maintenance command and the policy to
> generate Create/Delete soft cell commands is out of scope.
>
> Do you agree that OTF can provide a policy AT LEAST for generating
> Create/Delete soft cell commands? Not sure, if it can provide support also
> to the Maintenance command. What do you think?
>
>
>
>
>
> *10.   **Minor Comments*
>
> -         Pag. 4 Intro. In a TSCH network, the MAC layer is not in charge of setting up the schedule that controls the connectivity graph of the network and the resources allocated to each cell in that topology.  This responsibility is left to the next-higher layer, defined in this document, called "6top". I guess you meant *node*, and *NOT cell*.
>
> -         Pag 6, 2nd paragraph: They form a conceptual interface an upper layer can *used -> use*
>
> -         Pag. 15 " For example, after *neigotiation*, node A and node B
> find a *specifical* cell" ->  *negotiation, specific*
>
> -        Pag 17: indexd -> indexed; LikType as defined *in in * section
> -> an extra in
>
> -         Pag. 40: sec. 4.1.1.6 Bandwidth IE (BwIE) defines the number of cells to be reserved or *actually be reserved. -> actually been reserved.*
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Qin Wang <[email-masked]>
Date: Tue, 25 Mar 2014 10:14:11 -0700 (PDT)

Hi Maria Rita,

Please see the inline.

Thank you very much!
Qin

On Thursday, March 20, 2014 8:23 PM, Maria Rita PALATTELLA <[email-masked]> wrote:

Dear Qin, Xavi
 
1.  In the 6top draft you state thatimplementations can use this set of commands (i.e., those offered by 6top),or any equivalent alternative.
I was wondering if these can create interoperability problems. Because it could happen that two nodes do not speak the same language, unless, we assume that all the nodes in the network will be using the same set of commands (either the 6top ones, or another proprietary set).
[Qin] Since commands is the internal interface of in a node, between 6top and upper layer, instead of the interface on air, using different command set or equivalent alternative should not cause interoperability problem. Thought?
 
2.      6top can be configured to monitor the cells it has scheduled in order to detect cells with poor performance. It can automatically re-allocate those cells inside the TSCH schedule.
While  reading this, I was afraid that such monitoring mechanism could conflict with OTF, but actually it should provide to OTF the info needed for estimating the needed BDW.  Unlike 6top, OTF does not operate any cell re-allocation.  Such re-allocation, unlike the monitoring function,  may interference with OTF somehow, because while OTF is estimating the BDW and thus asking for adding/deleting soft cells, 6top in the meantime, may have planned to re-allocate some cells.
We will need to think about this and discuss if we should assign priority to different actions,   something like this: 6top first checks if there are requests from OTF, if not, then, 6top can re-allocate/move the soft cells.
[Qin]: The monitoring function is used to guarantee the BW required by upper layer, e.g. OTF. Thus, I think OTF works on different layer from the monitoring function of 6top. They should not conflict with each other. Thought? 
 
3.  Pag. 8: Data Transfer Model. The TSCH MAC layer is decoupled from the upper layer; the interaction between the upper layer and TSCH is asynchronous.  This means that the MAC layer executes a schedule and checks at each timeslot according to the type of cell, whether there is something…
    It is not clear to me what you mean with according to the type of cell. It should be clarified.
  [Qin] We will do it.
 
4.      The QoS policy enforced by 6top is out of scope.  As an example,   packets in higher priority queues could be transmitted before the  packets in lower priority queue.  As a result, when there is an   available broadcast/unicast cell, 6top checks the broadcast/unicast  queue with higher priority first. 6top continues this search until it  finds a broadcast/unicast packet, or finds that all of broadcast/ unicast queues are empty.
        It has to be specified the relationship between TRACKs and QUEUEs that is missing in the current version of the draft.
[Qin] We will add the description about the relationship between Tracks and queues.
 
5.  6top deals with the allocation process by negotiation with the target node.  The command returns the list of created cells defined by (slotframe ID, slotOffset, channelOffset).  It fails if the required number of cells is higher than the available number of cells in the schedule. It fails if the negotiation with the target node fails. It fails if the LinkOption bitmap indicates that the cell(s) MUST be Hard.
As I have already stated in a previous email, it should be better to define what happen when the negotiation fails. It is important for implementation purpose. Moreover, I think that in some cases, if the requested number of soft cells N is not available, it could be better to allocate the few available (N-x) instead  of not allocating anything, and declare a failure… what do you think?
[Qin] We will add example to describe what may happen when negotiation fails.
 
6.      For the REALLOCATE.softcell command, the upper layer specifies the slotframe ID, slotoffset, and channeloffset.
Why, the slotframe ID should be specified if (as the TrackID) is still the same, while moving the cell from a (timeoffset, channeloffset) to another one?
[Qin] It is because a cell can be identified by ( slotframe ID, slotoffset, channeloffset). TrackID is a feature of a cell, instead of part of identifier of a cell.
 
7.      6top Bandwidth IE
NumCell shall be set to the number of cells.  When BwIE is combined with the OpecodeID of Reserve Soft Cell Request, NumCell presents how many cells are required to reserve; and when BwIE is combined with the OpecodeID of Reserve Soft Cell Response, NumCell presents how many cells are reserved successfully.
It is not clear to me while the number of cells in the request msg should be different from the num of cells in the response msg. If the negotiation fails if the number of requested cells is not available, then, it means that the two numbers should be the same. Am I missing something?
[Qin] For example, nodeA wants to reserve 3 cells with nodeB, is BwIE in the response message equals to 2, means nodeB only has 2 cells available for nodeA. nodeA will determine how to handle the situation. Make sense?
 
[Qin]: Yes.
 
9.      Sec. 6.2 Actuation
The policy to generate the soft cell Maintenance command and the policy to generate Create/Delete soft cell commands is out of scope.
Do you agree that OTF can provide a policy AT LEAST for generating Create/Delete soft cell commands? Not sure, if it can provide support also to the Maintenance command. What do you think?
[Qin] I think it depends on implementation of 6top. A implementation may choose the BW computation algorithm of OTF to implement its Actuator. What do you think?

10.   Minor Comments
-        In the abstract, add support of hybrid scheduling (as clearly said in the rest of the draft)
-         Pag. 4 Intro. In a TSCH network, the MAC layer is not in charge of setting up the schedule that controls the connectivity graph of the network and the resources allocated to each cell in that topology.  This responsibility is left to the next-higher layer, defined in this document, called "6top". I guess you meant node, and NOT cell.
-         Pag 6, 2nd paragraph:They form a conceptual interface an upper layer can used -> use
-        Pag. 9 Figure Figure 2 -> and extra Figure (to be deleted)
-         Pag. 15 “ For example, after neigotiation, node A and node B find a specifical cell” ->  negotiation, specific
-        Pag 17: indexd -> indexed; LikType as defined in in  section -> an extra in
-        Pag. 19: why don’t talking of slotframe size when talking of number of timeslots within a slotframe?
-         Pag. 40: sec. 4.1.1.6 Bandwidth IE (BwIE) defines the number of cells to be reserved or actually be reserved. -> actually been reserved.
[Qin] Accepted

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Wed, 26 Mar 2014 12:43:56 +0000

Hi Qin,
Thanks for your answer. We are aligned.
Maria Rita

From: Qin Wang [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 6:14 PM
To: Maria Rita PALATTELLA; Xavi Vilajosana Guillén ([email-masked])
Cc: [email-masked]
Subject: Re: [6tisch] 6top sublayer draft review/comments

Hi Maria Rita,

Please see the inline.

Thank you very much!
Qin

On Thursday, March 20, 2014 8:23 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Dear Qin, Xavi
Please find below some comments and minor details to be fixed, as result of my review of the 6top sublayer draft.
Thank you in advance for going through all of them ☺
Best regards,
Maria Rita

7.      6top Bandwidth IE

9.      Sec. 6.2 Actuation

10.   Minor Comments

[Qin] Accepted

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