Subject: [6tisch] New Version Notification for draft-wang-6tisch-6top-sublayer-03.txt

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 20 Oct 2015 05:19:32 +0200

Dear all,

we have submitted a new version of the sublayer draft.

kind regards,
Xavi

-------------
A new version of I-D, draft-wang-6tisch-6top-sublayer-03.txt
has been successfully submitted by Thomas Watteyne and posted to the
IETF repository.

Name:           draft-wang-6tisch-6top-sublayer
Revision:       03
Title:          6TiSCH Operation Sublayer (6top)
Document date:  2015-10-19
Group:          Individual Submission
Pages:          18
URL:
https://www.ietf.org/internet-drafts/draft-wang-6tisch-6top-sublayer-03.txt
Status:
https://datatracker.ietf.org/doc/draft-wang-6tisch-6top-sublayer/
Htmlized:
https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-03
Diff:
https://www.ietf.org/rfcdiff?url2=draft-wang-6tisch-6top-sublayer-03

Abstract:
   This document defines the 6TiSCH Operation Sublayer (6top), which
   offers mechanisms for distributed scheduling in 6TiSCH networks.  The
   6top sublayer is the next higher layer of the IEEE802.15.4e TSCH
   medium access control layer.  The 6top Protocol (6P) defined in this
   document allows neighbor nodes to add/delete TSCH cells to one
   another.  To be able to match different application requirements, the
   6top Scheduling Function (SF) decides when to add/delete cells.  The
   SF is left out of scope, and will be specified in one or more
   companion documents.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 26 Oct 2015 17:23:39 -0700

Hello folks,

I made a review of the draft.  Attached, please find my revision of the 
file that has a few editorial suggestions along with a rfcdiff output to 
make it easy to see what's changed.

Here are some other questions and observations...

  * There is a strong need for non-local statistics, for instance flow
    statistics
  * Do 6top commands go across at scheduled times, or on the "minimal"
    channel SFR0?
  * Local measurements are prone to oscillation.
  * Shouldn't a retry facility be standardized?  That way you can
    specify binary exponential backoff, etc.
  * Is there any movement towards use of PCE?  I was thinking about
    making a draft on that topic.
  * Is it possible to carry protocol messages carried over IP? IPv6?
  * Shouldn't IETF try to either use existing IEs, or explain the need
    for new ones?  It seems wrong to allocate new IE numbers in the IETF.
  * In section 3.1.3, why are the OpCodes prefixed with IANA?  Why not 6TOP?
  * Are 65,000 offsets really needed?  65,000 channels??  Are
    applications going to request 256 cells from neighboring devices?
  * The concept of a container needs definition.  How is the length of a
    container known?  Is there any difference between "container" and
    "SFID-specific data"?  Unless it has some intuitive value, this
    seems like a misleading bit of terminology.
  * It seems likely that on many devices, scheduling functions will not
    be callable at boot time.  Why not mandate that a scheduling
    function needs to describe some behavior when 6tisch launches?
  * Is it now the intention that a scheduling function includes
    monitoring and "actuation"?  Did the text for these sections get
    moved to a different draft?

In my attached revision, please check for instances of "CEP" for a few 
other questions.

On 10/19/2015 8:19 PM, Xavier Vilajosana wrote:
> Status: https://datatracker.ietf.org/doc/draft-wang-6tisch-6top-sublayer/
> Htmlized: https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-03
> Diff: https://www.ietf.org/rfcdiff?url2=draft-wang-6tisch-6top-sublayer-03
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org 
> <http://tools.ietf.org/>.
>
> The IETF Secretariat
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 27 Oct 2015 05:00:52 +0100

Dear Cherlie,

thanks so much for your comments. We will address them in the next revision.

regards,
Xavi

2015-10-27 1:23 GMT+01:00 Charlie Perkins <[email-masked]>:

>    - There is a strong need for non-local statistics, for instance flow
>    statistics
>    - Do 6top commands go across at scheduled times, or on the "minimal"
>    channel SFR0?
>    - Local measurements are prone to oscillation.
>    - Shouldn't a retry facility be standardized?  That way you can
>    - Is there any movement towards use of PCE?  I was thinking about
>    - Is it possible to carry protocol messages carried over IP?  IPv6?
>    - Shouldn't IETF try to either use existing IEs, or explain the need
>    - In section 3.1.3, why are the OpCodes prefixed with IANA?  Why not
>    6TOP?
>    - Are 65,000 offsets really needed?  65,000 channels??  Are
>    - The concept of a container needs definition.  How is the length of a
>    "SFID-specific data"?  Unless it has some intuitive value, this seems like
>    a misleading bit of terminology.
>    - It seems likely that on many devices, scheduling functions will not
>    be callable at boot time.  Why not mandate that a scheduling function needs
>    to describe some behavior when 6tisch launches?
>    - Is it now the intention that a scheduling function includes
>    monitoring and "actuation"?  Did the text for these sections get moved to a
>    different draft?
>
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>

---

From: Qin Wang <[email-masked]>
Date: Tue, 27 Oct 2015 15:44:06 +0000 (UTC)

Hi Charlie,
Thank you very much for your comments. We will address the comments in your attached file (Diff draft-wang-6tisch-6top-sublayer-03.txt - draft-wang-6tisch-6top-sublayer-03cep.txt.htm) in the next version. In the following, I would like to discuss with you regarding to your questions and observations.
1.There is a strong need for non-local statistics, for instance flow statisticsSince different Scheduling Function (SF) may need different non-local statistics, IMHO, the non-local statistics should be part of SF.
2. Do 6top commands go across at scheduled times, or on the "minimal" channel SFR0?I think you refer to the commands carried in 6P message (section 3.1.3). I think that the 6P message will be exchanged after bootstrap which bases on "minimal". In addition, to exchange 6P message, both slots scheduled in SFR0 and slots scheduled in SFR1 can be used.
3. Local measurements are prone to oscillation.I'm not sure I understand the question. Can you explain more?
4. Shouldn't a retry facility be standardized?  That way you can specify binary exponential backoff, etc.I think it could be better to leave the retry policy to SF to standardize, which may give SF designer more flexibility. 
5. Is there any movement towards use of PCE?  I was thinking about making a draft on that topic.This 6top-sublayer document only towards distributed scheduling, not including PCE approach.
6. Is it possible to carry protocol messages carried over IP?  IPv6?I can not see the advantage to carry 6P message in IP or IPv6, because 6P message is just for one hop communication. But if you think about PCE approach, it may be possible to carry some sort of message with 6P message format over IP or IPv6.
7. Shouldn't IETF try to either use existing IEs, or explain the need for new ones?  It seems wrong to allocate new IE numbers in the IETF.In IEEE802.15.4e, the IEs space is divided into used, unmanaged, and reserved. But, The IEs defined in IEEE802.15.4e can not express the requirement of 6top. That is why we ask IEEE to assign us new IE(s).  What do you mean "existing IEs"?
8. In section 3.1.3, why are the OpCodes prefixed with IANA?  Why not 6TOP?Thomas or Xavi, could you please answer the question?
9. Are 65,000 offsets really needed?  65,000 channels??  Are applications going to request 256 cells from neighboring devices?It inherits from IEEE802.15.4, section 5.2.4.14 to keep consistence with Link Information field.
10. The concept of a container needs definition.  How is the length of a container known?  Is there any difference between "container" and "SFID-specific data"?  Unless it has some intuitive value, this seems like a misleading bit of terminology.Container is different from SFID. Container specifies the slotframe or chunk from which the cells are selected. We will clarify it in the next version
11. It seems likely that on many devices, scheduling functions will not be callable at boot time.  Why not mandate that a scheduling function needs to describe some behavior when 6tisch launches?During the boot time, "minimal" will be used. See answer to question 2.
12. Is it now the intention that a scheduling function includes monitoring and "actuation"?  Did the text for these sections get moved to a different draft?Yes. We will clarify it in the next version.
ThanksQin

     On Monday, October 26, 2015 8:24 PM, Charlie Perkins <[email-masked]> wrote:

  Hello folks,
 
 I made a review of the draft.  Attached, please find my revision of the file that has a few editorial suggestions along with a rfcdiff output to make it easy to see what's changed.

   - There is a strong need for non-local statistics, for instance flow statistics
   - Do 6top commands go across at scheduled times, or on the "minimal" channel SFR0?   
 
   - Local measurements are prone to oscillation.
   - Shouldn't a retry facility be standardized?  That way you can specify binary exponential backoff, etc.   
 
   - Is there any movement towards use of PCE?  I was thinking about making a draft on that topic.
   - Is it possible to carry protocol messages carried over IP?  IPv6?
   - Shouldn't IETF try to either use existing IEs, or explain the need for new ones?  It seems wrong to allocate new IE numbers in the IETF.
   - In section 3.1.3, why are the OpCodes prefixed with IANA?  Why not 6TOP?
   - Are 65,000 offsets really needed?  65,000 channels??  Are applications going to request 256 cells from neighboring devices?
   - The concept of a container needs definition.  How is the length of a container known?  Is there any difference between "container" and "SFID-specific data"?  Unless it has some intuitive value, this seems like a misleading bit of terminology.   
 
   - It seems likely that on many devices, scheduling functions will not be callable at boot time.  Why not mandate that a scheduling function needs to describe some behavior when 6tisch launches?
   - Is it now the intention that a scheduling function includes monitoring and "actuation"?  Did the text for these sections get moved to a different draft?   
 
 In my attached revision, please check for instances of "CEP" for a few other questions.

 Dear all,  
  we have submitted a new version of the sublayer draft. 
  kind regards, Xavi 
  ------------- A new version of I-D, draft-wang-6tisch-6top-sublayer-03.txt
 has been successfully submitted by Thomas Watteyne and posted to the
 IETF repository.
 
 URL:            https://www.ietf.org/internet-drafts/draft-wang-6tisch-6top-sublayer-03.txt
 
 Abstract:

 The IETF Secretariat

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 27 Oct 2015 11:43:47 -0700

Hello Qin,

Thanks for your quick reply.  Follow-up below...

On 10/27/2015 8:44 AM, Qin Wang wrote:
>
>
> 1.There is a strong need for non-local statistics, for instance flow 
> statistics
> Since different Scheduling Function (SF) may need different non-local 
> statistics, IMHO, the non-local statistics should be part of SF.

Perhaps it could at least be mentioned that obtaining non-local 
statistics is a possible responsibility for certain SFs.

>
> 2. Do 6top commands go across at scheduled times, or on the "minimal" 
> channel SFR0?
> I think you refer to the commands carried in 6P message (section 
> 3.1.3). I think that the 6P message will be exchanged after bootstrap 
> which bases on "minimal". In addition, to exchange 6P message, both 
> slots scheduled in SFR0 and slots scheduled in SFR1 can be used.

Is it mandated that bootstrapping uses "minimal"?

Is it intended that control messages (in general) are to be scheduled in 
the same way that data flows are scheduled?  Or, since the current 
messages are all one-hop messages, is it envisioned that any available 
slot could be used for the purpose?

If the latter, I think there will be problems with hidden terminals, etc.

If the former, there is a danger of starvation unless there is a control 
channel.  Starvation for IoT/detnet belongs on the don't-ever-allow-it list.

>
> 3. Local measurements are prone to oscillation.
> I'm not sure I understand the question. Can you explain more?

For example, if a local measurement triggers flow reassignment to 
different cells, and another nearby node uses an unfortunate 
reassignment at the same time, then oscillation will occur.

>
> 4. Shouldn't a retry facility be standardized?  That way you can 
> I think it could be better to leave the retry policy to SF to 
> standardize, which may give SF designer more flexibility.

System-wide, sometimes such flexibility can be dangerous.  For example, 
if too many SFs use a linear backoff (or, no backoff!) there will be 
problems.

>
> 6. Is it possible to carry protocol messages carried over IP?  IPv6?
> I can not see the advantage to carry 6P message in IP or IPv6, because 
> 6P message is just for one hop communication. But if you think about 
> PCE approach, it may be possible to carry some sort of message with 6P 
> message format over IP or IPv6.

Well, there is compression.  And, the IETF usually does things at the 
network layer and above.

>
> 7. Shouldn't IETF try to either use existing IEs, or explain the need 
> In IEEE802.15.4e, the IEs space is divided into used, unmanaged, and 
> reserved. But, The IEs defined in IEEE802.15.4e can not express the 
> requirement of 6top. That is why we ask IEEE to assign us new IE(s). 
>  What do you mean "existing IEs"?

Yes, this is exactly my point.  In the IEEE, we *do* want to satisfy the 
requirements for 6top.  I am involved with 802.15.LLC which has as its 
basic purpose to satisfy such requirements as may be determined by 6tisch.

>
> 9. Are 65,000 offsets really needed?  65,000 channels??  Are 
> It inherits from IEEE802.15.4, section 5.2.4.14 to keep consistence 
> with Link Information field.

Thanks.  I'll have to go express my amazement there :-)

>
> 10. The concept of a container needs definition.  How is the length of 
> a container known?  Is there any difference between "container" and 
> "SFID-specific data"?  Unless it has some intuitive value, this seems 
> like a misleading bit of terminology.
> Container is different from SFID. Container specifies the slotframe or 
> chunk from which the cells are selected. We will clarify it in the 
> next version.

Could you provide some intuition that favors the use of the word 
"container"?  If it's a data structure containing slotframe information, 
that could be given a much more relevant name.  I could make some 
suggestions for that.

>
> 11. It seems likely that on many devices, scheduling functions will 
> not be callable at boot time.  Why not mandate that a scheduling 
> During the boot time, "minimal" will be used. See answer to question 2.

What if there are devices that do a lot of stuff and only launch 6tisch 
when data communications are needed?  Would they all be non-conformant?

Regards,
Charlie P.

> I made a review of the draft.  Attached, please find my revision of 
> the file that has a few editorial suggestions along with a rfcdiff 
> output to make it easy to see what's changed.
>
>   * The concept of a container needs definition. How is the length of
>     a container known?  Is there any difference between "container"
>     and "SFID-specific data"?  Unless it has some intuitive value,
>     this seems like a misleading bit of terminology.
>   * It seems likely that on many devices, scheduling functions will
>     not be callable at boot time.  Why not mandate that a scheduling
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Qin Wang <[email-masked]>
Date: Wed, 28 Oct 2015 14:43:42 +0000 (UTC)

HI Charlie,
See the inline. I marked with names for others to read.
Hello Qin,

1.There is a strong need for non-local statistics, for instance flow statistics[Qin] Since different Scheduling Function (SF) may need different non-local statistics, IMHO, the non-local statistics should be part of SF.
[Charlie] Perhaps it could at least be mentioned that obtaining non-local statistics is a possible responsibility for certain SFs.
[Qin] Agree

2. Do 6top commands go across at scheduled times, or on the "minimal" channel SFR0?[Qin] I think you refer to the commands carried in 6P message (section 3.1.3). I think that the 6P message will be exchanged after bootstrap which bases on "minimal". In addition, to exchange 6P message, both slots scheduled in SFR0 and slots scheduled in SFR1 can be used.
[Charlie]
Is it mandated that bootstrapping uses "minimal"?

Is it intended that control messages (in general) are to be scheduled in the same way that data flows are scheduled?  Or, since the current messages are all one-hop messages, is it envisioned that any available slot could be used for the purpose?

If the former, there is a danger of starvation unless there is a control channel.  Starvation for IoT/detnet belongs on the don't-ever-allow-it list.

[Qin] According to my understanding, "minimal" is mandatory for bootstrapping. In the current design, the scheduling processes for control message and data flow are same. In another word, the 6P based negotiation is triggered by SF to conduct ADD/DELETE cells process, regardless the cells will be used for data flow or control message. The hidden terminal problem is expected to be solved by monitoring function of SF. 

3. Local measurements are prone to oscillation.[Qin] I'm not sure I understand the question. Can you explain more?

[Charlie] For example, if a local measurement triggers flow reassignment to different cells, and another nearby node uses an unfortunate reassignment at the same time, then oscillation will occur.

[Qin] Yes, it may happen. I think the backoff policy of SF should take it into consideration.

4. Shouldn't a retry facility be standardized?  That way you can specify binary exponential backoff, etc.[Qin] I think it could be better to leave the retry policy to SF to standardize, which may give SF designer more flexibility.

[Charlie] System-wide, sometimes such flexibility can be dangerous.  For example, if too many SFs use a linear backoff (or, no backoff!) there will be problems.
[Qin] Agree. Maybe we need to give some recommendation in the draft. What other people think?

6. Is it possible to carry protocol messages carried over IP?  IPv6?[Qin] I can not see the advantage to carry 6P message in IP or IPv6, because 6P message is just for one hop communication. But if you think about PCE approach, it may be possible to carry some sort of message with 6P message format over IP or IPv6.

[Charlie] Well, there is compression.  And, the IETF usually does things at the network layer and above.

[Qin] But 6top is under IP layer and is going to fit the gap between MAC and network layer.

7. Shouldn't IETF try to either use existing IEs, or explain the need for new ones?  It seems wrong to allocate new IE numbers in the IETF.[Qin] In IEEE802.15.4e, the IEs space is divided into used, unmanaged, and reserved. But, The IEs defined in IEEE802.15.4e can not express the requirement of 6top. That is why we ask IEEE to assign us new IE(s).  What do you mean "existing IEs"?

[Charlie] Yes, this is exactly my point.  In the IEEE, we *do* want to satisfy the requirements for 6top.  I am involved with 802.15.LLC which has as its basic purpose to satisfy such requirements as may be determined by 6tisch.

[Qin] I think we can start a discussion specifically about the interface between IEEE and 6top. Basically it is important for us to move forward instead of waiting the development of other standards. Make sense?

10. The concept of a container needs definition.  How is the length of a container known?  Is there any difference between "container" and "SFID-specific data"?  Unless it has some intuitive value, this seems like a misleading bit of terminology.[Qin] Container is different from SFID. Container specifies the slotframe or chunk from which the cells are selected. We will clarify it in the next version.

[Charlie] Could you provide some intuition that favors the use of the word "container"?  If it's a data structure containing slotframe information, that could be given a much more relevant name.  I could make some suggestions for that.
[Qin] Container should be a ID, such as slotframe ID or chunk ID, to specify where the cells are selected from. 

11. It seems likely that on many devices, scheduling functions will not be callable at boot time.  Why not mandate that a scheduling function needs to describe some behavior when 6tisch launches?[Qin] During the boot time, "minimal" will be used. See answer to question 2.

[Charlie] What if there are devices that do a lot of stuff and only launch 6tisch when data communications are needed?  Would they all be non-conformant?
[Qin] Do those devices use TSCH as MAC? If yes, 6tisch is necessary for all time, I believe.

ThanksQin

     On Tuesday, October 27, 2015 2:44 PM, Charlie Perkins <[email-masked]> wrote:

  Hello Qin,

 
  1.There is a strong need for non-local statistics, for instance flow statistics Since different Scheduling Function (SF) may need different non-local statistics, IMHO, the non-local statistics should be part of SF.  
 Perhaps it could at least be mentioned that obtaining non-local statistics is a possible responsibility for certain SFs.

  2. Do 6top commands go across at scheduled times, or on the "minimal" channel SFR0? I think you refer to the commands carried in 6P message (section 3.1.3). I think that the 6P message will be exchanged after bootstrap which bases on "minimal". In addition, to exchange 6P message, both slots scheduled in SFR0 and slots scheduled in SFR1 can be used.  

 Is it intended that control messages (in general) are to be scheduled in the same way that data flows are scheduled?  Or, since the current messages are all one-hop messages, is it envisioned that any available slot could be used for the purpose?

 If the former, there is a danger of starvation unless there is a control channel.  Starvation for IoT/detnet belongs on the don't-ever-allow-it list.

  
  3. Local measurements are prone to oscillation. I'm not sure I understand the question. Can you explain more?  

 For example, if a local measurement triggers flow reassignment to different cells, and another nearby node uses an unfortunate reassignment at the same time, then oscillation will occur.

  4. Shouldn't a retry facility be standardized?  That way you can specify binary exponential backoff, etc. I think it could be better to leave the retry policy to SF to standardize, which may give SF designer more flexibility.  
 
 System-wide, sometimes such flexibility can be dangerous.  For example, if too many SFs use a linear backoff (or, no backoff!) there will be problems.

 6. Is it possible to carry protocol messages carried over IP?  IPv6? I can not see the advantage to carry 6P message in IP or IPv6, because 6P message is just for one hop communication. But if you think about PCE approach, it may be possible to carry some sort of message with 6P message format over IP or IPv6.  
 
 Well, there is compression.  And, the IETF usually does things at the network layer and above.

  7. Shouldn't IETF try to either use existing IEs, or explain the need for new ones?  It seems wrong to allocate new IE numbers in the IETF. In IEEE802.15.4e, the IEs space is divided into used, unmanaged, and reserved. But, The IEs defined in IEEE802.15.4e can not express the requirement of 6top. That is why we ask IEEE to assign us new IE(s).  What do you mean "existing IEs"?  
 
 Yes, this is exactly my point.  In the IEEE, we *do* want to satisfy the requirements for 6top.  I am involved with 802.15.LLC which has as its basic purpose to satisfy such requirements as may be determined by 6tisch.

 9. Are 65,000 offsets really needed?  65,000 channels??  Are applications going to request 256 cells from neighboring devices? It inherits from IEEE802.15.4, section 5.2.4.14 to keep consistence with Link Information field.  

  
  10. The concept of a container needs definition.  How is the length of a container known?  Is there any difference between "container" and "SFID-specific data"?  Unless it has some intuitive value, this seems like a misleading bit of terminology. Container is different from SFID. Container specifies the slotframe or chunk from which the cells are selected. We will clarify it in the next version.  
 
 Could you provide some intuition that favors the use of the word "container"?  If it's a data structure containing slotframe information, that could be given a much more relevant name.  I could make some suggestions for that.

  
  11. It seems likely that on many devices, scheduling functions will not be callable at boot time.  Why not mandate that a scheduling function needs to describe some behavior when 6tisch launches? During the boot time, "minimal" will be used. See answer to question 2.  
 
 What if there are devices that do a lot of stuff and only launch 6tisch when data communications are needed?  Would they all be non-conformant?
 
 Regards,
 Charlie P.

    Hello folks,

    

 

      Dear all,  

 Abstract:

 The IETF Secretariat