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
<[email protected]> 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
<http://tools.ietf.org/>.
The IETF Secretariat
_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
