Dear SF0 authors, all
I've gone through the SF0 draft (v04) published last Friday (28th April).
Please find my constructive comments after reading the document. I hope
they are useful.
kind regards,
X
-------
Abstract:
allocated cells -> scheduled cells?
Intro:
- for the 6top sublayer -> using the 6P protocol
- the minimal set of functionalities -> what is the minimal set?
- The intro explains that there are 2 algorithms. After this initial
introduction the purpose of the algorithms is briefly explained. Here I
suggest to add another section for each of them and let the introduction
just detail the goal of the document and motivation of the decisions taken
for this SF.
- The description of the Sched. Alg. is somehow confusing.
"The Scheduling Algorithm: A number of TX and/or RX cells must be
allocated between neighbor nodes in order to enable data transmission
among them. A portion of these allocated cells will be utilized by
neighbors,
- what utilized by neighbors mean? do you refer that the cells will be used
to transmit packets/frames between the neighbors?
while the remaining cells can be over-provisioned to
handle unanticipated increases in cell requirements. "
-over-provisioning must be defined so everybody understands the concept.
The Scheduling Algorithm collects the cell allocation/deletion requests
from the
neighbors and the number of cells which are currently under usage .
First, the Cell Estimation
- Algotithm -> Algorithm
calculates the number of required cells by adding the collected values
- What does this mean? what are the collected values? what is their meaning?
and second, the calculated value is given to the Allocation Policy,
which provides stability by adding hystheresis and overprovisioning by
deciding when
to schedule the new number of cells, according to a threshold.
-Lots of information here. Maybe explain a little bit better. Give details
about why it gives stability and how overprovisioning and hysteresis are
used for that.
- Also it is not clear what is the role of the threshold here.
In order to reduce consumption, this algorithm is triggered only when
there is a change on the number of effectively used cells
- assume later we will know how to calculate the number of effectively used
cells.
or if there is a change on the number of requested cells from a particular
node.
"A relocation is
triggered when the PDR value drops below a certain threshold,
compared to the average PDR of the rest of allocated cells. The
destination location on the schedule is defined randomly."
- this assertion is central to the document, seems like this is one of the
major key points of the document. As said before, for me this should not be
in the introduction bu in a dedicated section explaining how reloaction
works.
Section "Scheduling Function Identifier"
should not be: IANA_SFID_SF0 -> IANA_6TiSCH_SFID_SF0.
Section "SF0 Triggering Events"
1. If there is a change in the current number of required cells
- is this triggered by what? 6P allocation? queue size? increase on cell
usage?
2. If there is a successful cell allocation/deallocation process
with the neighbour.
-A cell allocation is a result of a decision taken in a previous step, i.e
some algorithm has decided that more cells are needed and those are
allocated. Then after the allocation the algorithm is triggered again.
Could you clarify in the text what is the purpose?
This allows SF0 to be triggered by any change in locally generated or
incoming traffic. The exact mechanism of when SF0 is triggered is
implementation-specific.
Section "SF0 Cell Estimation Algorithm"
The Cell Estimation Algorithm takes into account the new incoming
cell requirements
- define somewhere what incoming cell requirements are?
from the neighbor node and the current outgoing number of used cells.
- idem, define outgoing
This allows the algorithm to estimate a new
number of cells to be allocated. As a consequence, the Cell
Estimation Algorithm for SF0 follows the steps described below:
1. Collect the current number of used cells
-to the particular neighbor or in total in its schedule?
2. Calculate the new number of cells to be allocated by adding the
current number of used cells plus an OVERPROVISION number of
cells
- Considering the cells in the schedule, how the current number of used
cells are identified?
3. Submit the request to the allocation policy as REQUIREDCELLS
- explain better. What is submitted? is this a function call? Does this
mean, "indicate to the allocation policy the required cells".
4. Return to step 1 and wait for a triggering event.
- Maybe a flow diagram would be a good complement to clarify its use.
The OVERPROVISION parameter is a percentage of the
currently allocated cells -> number of currently allocated cells
- Why this link here. Maybe use a . and start a new sentence.
e.g., The OVERPROVISION value is added to the used cells parameter ...
which is added to the used cells to guarantee that
the growth on the number of used cells can be detected without packet
loss. This percentage value is implementation-specific.
A value of
OVERPROVISION equal to zero leads to queue growth and possible packet
loss, since there are no overprovisioned cells to detect if there is
a growth on the number of used cells.
-clarify this.
- 1) if no overprovision then no extra cells in the schedule to cope
with sudden increments or unexpected retransmissions
- 2) this may cause the queue to grow and eventually drop packets.
Section "SF0 allocation policy"
The "Allocation Policy" is the set of rules used by SF0 to decide
when to add/delete cells to a particular neighbor to satisfy the cell
requirements.
SF0 uses the following parameters:
SCHEDULEDCELLS: The number of cells scheduled from the current node
to a particular neighbor.
REQUIREDCELLS: The number of cells calculated by the Cell Estimation
Algorithm from the current node to that neighbor.
SF0THRESH: Threshold parameter introducing cell over-provisioning in
the allocation policy.
- what is the relation of this with OVERPROVISION percentage in the
previous section?
Section "Rules for Celllist"
How do you handle error situations? is there a retry-policy?
Section "6P Timeout value"
"The general timeout equals the equivalent time of the number of slots
until the next scheduled cell."
- I assume this is from the moment the transaction starts. Isn't it? Please
clarify in the description.
- Could you elaborate why this decision?
Section SF0 Statistics
-I do not understand the PDR definition
Packet Delivery Rate (PDR) is calculated per cell, as the quotient of
the number of successfully delivered packets to 10
what is 10? is this how many of the last 10 have been acknowledged?
, for the last 10
packet transmission attempts, without counting retransmissions.
Section "Relocating Cells"
... PDR_THRESHOLD, defined as a percentage of the
average of the PDR of the rest of the scheduled cells
-Could you express this in a function? What percentage it is?
-If PDR_THRESHOLD is defined as indicated above, why later it is stated
that "PDR_THRESHOLD is out of the scope of this document and it is
implementation-dependent."
General comments:
the document introduces the main ideas for SF0 but IMHO it needs some
editorial work to clarify the functionalities and do not mix concepts
during the explanation, in general it lacks clarity that may compromise an
implementation.
I suggest adding more flow diagrams and trying to narrow and maybe put in a
table the configuration values of the mechanism. Also add the mathematical
formulation of the different computations that are conducted. The use of
SF0THRESH and its relation to OVERPROVISION percentage needs to be
clarified. Also the mechanism that trigger the SF0 policy need to be
reviewed, and mention somehow how hysteresis is introduced to avoid
constant variations of the number of scheduled cells.
--
Dr. Xavier Vilajosana
Wireless Networks Lab
*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email protected] <[email protected]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
[image: Universitat Oberta de Catalunya]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
