Subject: [6tisch] 6top Interface draft - review and comments

From: Maria Rita PALATTELLA <[email-masked]>
Date: Thu, 13 Mar 2014 14:36:42 +0000

Dear Qin,

First of all thanks for the work done on this draft, together with Xavi and Thomas.
I fully support the adoption of the draft as WG document because it is really a fundamental piece of the 6TiSCH architecture.

In order to clearly define the interface between OTF and 6top, and see which commands are already available (useful for OTF) and which we may need to add, I have gone through the 6top Interface draft again, with an higher level of accuracy.
Thus, I have some comments and questions. Thank you in advance for your answer and explanations.

Minor comments:
Legend **aa** -> add *a* -> delete

-        Maybe  in Figure 1 it should be nice to add two boxes in the 6top sublayer, representing the Management and the Data Interface.

-         Typo Pag 5: 6top allows an upper layer ask a node manage a a portion of a slotframe -> 6top allows an upper layer **to** ask a node **to** manage a *a* portion of a slotframe

-         Typo Pag 7: In Figure 2, Qi represents a queue, which is either broadcast or unicast, and *is* assigned *a* priority. -> In Figure 2, Qi represents a queue, which is either broadcast or unicast, and **it has an** assigned priority

-        Typo pag 8: The *dada* model -> the **data** model

Comments/Questions:

1.  "In addition, 6top allows an upper layer to schedule a certain amount of bandwidth to a neighbor, without having to specify the exact slotOffset(s) and channelOffset(s).  Once bandwidth is reserved, 6top is in charge of ensuring that this requirement is continuously satisfied. 6top dynamically reallocates cells if needed, and overprovisions if required."

>From this statement it looks as if 6top is able to monitor the soft cells (bundles) and decide on its own WHEN to re-allocate new cells. If it is the case, then, we should specify how 6top take decision about the cells to move in the schedule.
Still according to the statement above, 6top can allocate new cells  (over-provision) IF REQUIRED, for instance after requests coming  from OTF (maybe we could refer to it as example).

2.      You talk about best-effort QoS track (0,0), but it is not clear how and when it should be used. This is important to know, in order to understand how OTF could use such track.

3.      When describing the hard cell maybe it is the case to specify (following the same structure you use for the soft cell): installed by 6top, given the specific (slotoffset, channeloffset)

4.      Because 6top allow to associate a cell with a specific track, shouldn't the TrackID also included among the parameters that uniquely identify an hard cell?

5.       When you present the 6top Data transfer Model, it is not clear to me if the same queue can be used by several tracks. If so, it should be clarified.

6.      In the YANG model of the 6top MIB, you talk about EnforcePolicy (BestEffort,Strict, Overprovision). But they have not been defined somewhere else in the draft. It is not clear what they imply (which effect they have on what?), how they are applied, etc.

7.      You define an "overprovision list". Which cells should be included in this list? The soft cells that have been reserved in a bundle on a track for a specific couple of node? And, when the cells are allocated (used for tx/rx), are they moved in the AllocatedSoft list?  If so, then it has to be explained somewhere. This info is also important for OTF.

8.      You talk about QoS and NQoS, but actually you refer to Bandwidth. Because QoS can refer to different metrics (e.g., latency, energy consumption, etc.) I would suggest that we use BDW and NBDW, instead of QoS, NQoS? What do you think?

9.      Moreover, with NQoS do you mean the cells in the bundle that are actually used? While QoS include both the ones used (where there is a transmission), and those empty but still reserved?

10.   You define some METRICS to be monitored: PDR, ETX, RSSI, LQI. Are they all monitored, or is it possible to select one or a set of them?

11.   You also define a WINDOW (i.e., time period) during which the metrics should be monitored. But what values are monitored? The instant value for each timeslot? It is important to know, because external module (e.g., OTF), may need to take decisions either on current status of the network, or on the average one, computed during a given period. If 6top provide already the average, that's good, either wise, the external module should compute it.

12.   When presenting the timesource, maybe it is good to explain how the different policies work (allparent, bestconnected, lowestjoinpriority)

13.   Do you agree that the info  related to the queue (min, max, average length) associated to a track could be useful for deciding if more BDW should be allocated on that track?

14.   Do you agree that the info related to ReTX can be useful for deciding if it is the case to re-allocate some soft cells (too many ReTX -> collision -> move cells)?

15.   And that the info related to the time spent by a pkt in the queue, can also trigger a request for more soft cells (if a pkt stays for long time in the queue, it means that more BDW is needed for dealing with the load of traffic)

16.   Related to LabelSwitchList, you talk about LoadBalancyPolicy. Maybe it is the case to spend some more words in the description.

17.   About the ChunkList, did we agree about the strategy to use for selecting the cells within a chunk (I mean by using incremental slotoffset and channeloffset)? Sorry I don't remember, and at the same time I wonder if it is the best strategy to use.

18.   About the status of the cells within a chunk, with "used", "unused", do you mean that the cells have been reserved (or not) for communication along a track between two specific nodes? Then, shouldn't we talk about schedule, unscheduled?

19.   Still about chunk, should we set a leaf for specifying it that chunk has been assigned to a specific (RPL) parent?

20.   6top Commands

a.      Create.hardcell: it seems that an hard cell does not have an associated trackID. Am I missing something?

b.      Create.softcell: again you talk about monitor and re-schedule if needed, but it is not clear how the re-schedule should be triggered (from inside 6top, from outside, e.g., OTF, etc.). Moreover it should be good to specify how this command can be used for creating BUNDLE, otherwise it is not clear that the same command works both for single soft cell, and bundles.

c.      UPDATE.cell: I guess it is a typo, and you meant soft and not hard. By definition hard cells shouldn't be moved either by 6top, or by any other entity. Thus if an hard cell is not performing well, it should be deleted, and a new one created. We shouldn't talk at all of UPDATE.cell, related to hard cell.

d.      DELETE.softcell: it is up to the two nodes to figure out which cells should be deleted. But we need to specify, at least one method/criteria that could be used, either wise, we cannot implement it.

e.      UPDATE.slotframe: it is mainly a re-size command. What about CONFIGURE.newsize.slotframe, because UPDATE.slotframe sounds too generic.

f.       DELETEslotframe: when a slotframe is deleted, also all the cells that where scheduled within that slotframe should be deleted from the TSCH schedule (that includes cells from several slotframe). Thus, we should specify that.

g.      CONFIGURE.monitoring, READ.monitoring: it is not really clear how these commands work

h.      READ.statistics: reads a metric for the specific dimension. Information is aggregated according to the parameters from CellList... what do you mean with specific dimension, and with aggregated?

Sorry Qin for my long email, and many thanks for going through all my 20 points ;
Maria Rita

---

From: Qin Wang <[email-masked]>
Date: Thu, 13 Mar 2014 12:15:47 -0700 (PDT)

Hi Maria Rita,

Thanks you very much for your comments. Please see inline.

Qin

On Thursday, March 13, 2014 10:37 PM, Maria Rita PALATTELLA <[email-masked]> wrote:

Dear Qin,

 
Minor comments:
[Qin] accepted. 

Comments/Questions:
 
1.  “In addition, 6top allows an upper layer to schedule a certain amount of bandwidth to a neighbor, without having to specify the exact slotOffset(s) and channelOffset(s).  Once bandwidth is reserved, 6top is in charge of ensuring that this requirement is continuously satisfied. 6top dynamically reallocates cells if needed, and overprovisions if required.”

[Qin]:  (1) For softcell, the function of Monitoring in 6top is responsible for re-allocating cell, i.e. associate a exiting cellID to another (slotOffset, channelOffset) while the link quality of the original (slotOffset, channelOffset) is lower than a given threshold. Like OF in RPL, 6top does not define how to make decision on re-allocation and leave it to other drafts and future.
         (2) Assume upper layer requires some add bandwidth, saying 2 slots in a specific slotframe; the average Packet Delivery Rate is 75%; then, 6top will reserve 3 slots in the slotframe to meet the bandwidth requirement. In addition, when the link quality drop to 50%, 6top will reserve total 4 slots to meet the bandwidth requirement.
 
2.      You talk about best-effort QoS track (0,0), but it is not clear how and when it should be used. This is important to know, in order to understand how OTF could use such track.
[Qin]:  A cell with TrackID=(0,0) can be used send packet with QoS=best-effort. But, what kind of data packet should be set the QoS of best-effort is out of 6top scope.

[Qin]: accepted
 
4.      Because 6top allow to associate a cell with a specific track, shouldn’t the TrackID also included among the parameters that uniquely identify an hard cell?
[Qin]: Can you explain more about the question?
 
5.       When you present the 6top Data transfer Model, it is not clear to me if the same queue can be used by several tracks. If so, it should be clarified.
[Qin]: You are right. We will start a thread to discuss the relationship between Queue and Track.
 
6.      In the YANG model of the 6top MIB, you talk about EnforcePolicy (BestEffort,Strict, Overprovision). But they have not been defined somewhere else in the draft. It is not clear what they imply (which effect they have on what?), how they are applied, etc.
[Qin]: Thanks for the comments. We will add more description.
 
7.      You define an “overprovision list”. Which cells should be included in this list? The soft cells that have been reserved in a bundle on a track for a specific couple of node? And, when the cells are allocated (used for tx/rx), are they moved in the AllocatedSoft list?  If so, then it has to be explained somewhere. This info is also important for OTF.
[Qin]: It belongs to MonitoringStatusList. One entry of the list corresponds to a bundle, showing how many hardcells, how many softcells (in which how many overprovision softcells) are included in the bundle.
 
8.      You talk about QoS and NQoS, but actually you refer to Bandwidth. Because QoS can refer to different metrics (e.g., latency, energy consumption, etc.) I would suggest that we use BDW and NBDW, instead of QoS, NQoS? What do you think?
[Qin]: I think it is good idea. What other people think?
 
9.      Moreover, with NQoS do you mean the cells in the bundle that are actually used? While QoS include both the ones used (where there is a transmission), and those empty but still reserved?
[Qin]: NQoS is just another statistics. With QoS and NQoS, upper can figure out if it need to reserve or remove some bandwidth. Thought?
 
10.   You define some METRICS to be monitored: PDR, ETX, RSSI, LQI. Are they all monitored, or is it possible to select one or a set of them?
[Qin]: Yes, it is possible to select one or more.
 
11.   You also define a WINDOW (i.e., time period) during which the metrics should be monitored. But what values are monitored? The instant value for each timeslot? It is important to know, because external module (e.g., OTF), may need to take decisions either on current status of the network, or on the average one, computed during a given period. If 6top provide already the average, that’s good, either wise, the external module should compute it.
[Qin]: The WINDOW is the given period to calculate the average of those metrics.
 
12.   When presenting the timesource, maybe it is good to explain how the different policies work (allparent, bestconnected, lowestjoinpriority)
[Qin]: We will add more description.
 
13.   Do you agree that the info  related to the queue (min, max, average length) associated to a track could be useful for deciding if more BDW should be allocated on that track?
[Qin]: Definitly it can be used to calculate BW. 
 
[Qin]: Yes, I agree.
 
[Qin]: Yes, I agree.
 
[Qin]: We will.
 
17.   About the ChunkList, did we agree about the strategy to use for selecting the cells within a chunk (I mean by using incremental slotoffset and channeloffset)? Sorry I don’t remember, and at the same time I wonder if it is the best strategy to use.
[Qin]: It is suggested by Pascal. Comparing with a long list of cells in a chunk, this scheme can reducing communication while setting a chunk into a node. Maybe there are other schemes. BTW, it is only used to construct a chunk, it does mean a parent, who own a chunk, should assign cells to its children in this way.
 
18.   About the status of the cells within a chunk, with “used”, “unused”, do you mean that the cells have been reserved (or not) for communication along a track between two specific nodes? Then, shouldn’t we talk about schedule, unscheduled?
[Qin]: Accepted
 
19.   Still about chunk, should we set a leaf for specifying it that chunk has been assigned to a specific (RPL) parent?
 [Qin] I think the address of the node, who owns the chunk, is the information you want. Right?
 
20.   6top Commands
[Qin]: Please see sublayer draft for more detail about commands. Since commands list is internal API, it is just a helper in interface draft. Your following comments will be very helpful for us to improve sublayer draft.
a.      Create.hardcell: it seems that an hard cell does not have an associated trackID. Am I missing something?
b.      Create.softcell: again you talk about monitor and re-schedule if needed, but it is not clear how the re-schedule should be triggered (from inside 6top, from outside, e.g., OTF, etc.). Moreover it should be good to specify how this command can be used for creating BUNDLE, otherwise it is not clear that the same command works both for single soft cell, and bundles.
c.      UPDATE.cell:  I guess it is a typo, and you meant soft and not hard. By definition hard cells shouldn’t be moved either by 6top, or by any other entity. Thus if an hard cell is not performing well, it should be deleted, and a new one created. We shouldn’t talk at all of UPDATE.cell, related to hard cell.
d.      DELETE.softcell: it is up to the two nodes to figure out which cells should be deleted. But we need to specify, at least one method/criteria that could be used, either wise, we cannot implement it.
e.      UPDATE.slotframe: it is mainly a re-size command. What aboutCONFIGURE.newsize.slotframe, becauseUPDATE.slotframe sounds too generic.
f.       DELETEslotframe:  when a slotframe is deleted, also all the cells that where scheduled within that slotframe should be deleted from the TSCH schedule (that includes cells from several slotframe). Thus, we should specify that.
g.      CONFIGURE.monitoring, READ.monitoring: it is not really clear how these commands work
h.      READ.statistics: reads a metric for the specific dimension. Information is aggregated according to the parameters from CellList… what do you mean with specific dimension, and with aggregated?

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

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 14 Mar 2014 07:38:04 +0000

Hello Qin, thanks for your prompt feedbacks, and clarifications.
About your questions to me. Here are the answers.

4.      Because 6top allow to associate a cell with a specific track, shouldn’t the TrackID also included among the parameters that uniquely identify an hard cell?
[Qin]: Can you explain more about the question?
[MR] I meant, isn’t an hard cell also associated to a specific track? If so, then we should list among the parameter that identify a hard cell, also the TrackID (as it is explicitly said for the soft cell)

19.   Still about chunk, should we set a leaf for specifying it that chunk has been assigned to a specific (RPL) parent?
 [Qin] I think the address of the node, who owns the chunk, is the information you want. Right?
[MR] Right, in this way it will be clear that the chunk is managed by that node identified by the given address.

20.   6top Commands
[Qin]: Please see sublayer draft for more detail about commands. Since commands list is internal API, it is just a helper in interface draft. Your following comments will be very helpful for us to improve sublayer draft.
[MR] I will go in more details also in the sublayer draft…Just proceeding step by step, and come out with my comments/questions if I have any.

Thank you!
Maria Rita

From: Qin Wang [mailto:[email-masked]]
Sent: Thursday, March 13, 2014 8:16 PM
To: Maria Rita PALATTELLA
Cc: [email-masked]
Subject: Re: [6tisch] 6top Interface draft - review and comments

Hi Maria Rita,

Qin

On Thursday, March 13, 2014 10:37 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Dear Qin,

Minor comments:

Comments/Questions:

20.   6top Commands

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

---

From: Qin Wang <[email-masked]>
Date: Fri, 14 Mar 2014 06:24:08 -0700 (PDT)

Hi Maria Rita,

You are right. TrackID is included in the parameters of hardcell commands, and also softcell commands. See the sublayer draft.

Thanks
Qin

On Friday, March 14, 2014 3:38 PM, Maria Rita PALATTELLA <[email-masked]> wrote:

 
 
20.   6top Commands
 
Thank you!
Maria Rita
 
From:Qin Wang [mailto:[email-masked]] 
Sent: Thursday, March 13, 2014 8:16 PM
To: Maria Rita PALATTELLA
Cc: [email-masked]
Subject: Re: [6tisch] 6top Interface draft - review and comments
 
Hi Maria Rita,

Qin

 
 
Minor comments:
 
Comments/Questions:

 

 

 

 

 

 

 
 
20.   6top Commands