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 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.
The IETF Secretariat
_______________________________________________
6tisch mailing list
[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
