HI Charlie,
See the inline. I marked with names for others to read.
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[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 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.
[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?
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.
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.[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
<charles.perk...@earthlink.net> wrote:
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 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.
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 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.
On Monday, October 26, 2015 8:24 PM, Charlie Perkins
<charles.perk...@earthlink.net> 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.
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:
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
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
