Xavi,
I answer to your comments inline. I am really grateful
for your comments, since most the new version had not had
a detailed revision since the migration from OTF to SF0.
Regards,
Diego
2017-04-30 8:37 GMT-03:00 Xavi Vilajosana Guillen <[email protected]>:
> 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?
>
This belongs to the OTF way of naming scheduled cells, I will update it.
>
> 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.
>
OK. I will move the explanations from the introduction to the current
algorithm
description sections which already exist on the draft.
>
> - 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?
>
First, there is a difference between the allocated an used cells: You can
allocate a cell, and send a packet
over that cell when the time arrives, or keep the cell without a packet
during a slotframe. So, in SF0 terms,
an allocated cell may or may not be used. I listen to suggestions to change
the term "used" to a more
representative one.
Now, going to your comment, first, SF0 only requests the scheduling of TX
cells to a neighbour, which are
RX cells on the other side. There are no shared cells since we have no clue
on what the application(s) is(are)
running on the node is(are) doing. Then, RX cells is a mistake there.
The term "utilized" will be changed to "used" or to the proposed way of
calling them. When the correct term is
chosen, I will define it before this paragraph.
>
> 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.
>
OK. I will define what overprovisioning stands for.
>
> 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
>
OK. Typo. It was hiding from me to survive in future versions, thanks for
catching it.
>
> calculates the number of required cells by adding the collected values
>
> - What does this mean? what are the collected values? what is their
> meaning?
>
This phrase should go away, it has currently no application. In the former
versions
we proposed that we were a part of a chain instead of having exclusively
peer-to-peer
negotiation.
>
> 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.
>
>
I will delete this phrase for the sake of clarity.
> 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.
>
The "effectively used cells" term was coined originally to highlight that
there is a huge
difference between allocating and using a cell. It will be changed to
"used" cells.
>
> or if there is a change on the number of requested cells from a particular
> node.
>
This will be removed. In order to trigger SF0, we only look now at the
number of used cells vs. the allocated cells
from the node to any of the neighbours. Looking into requests from other
neighbours and relating this to a possible
traffic increase towards any of the remaining neighbours is not current.
This was the original idea when we could
identify a parent neighbour from a child neighbour. SF0 is now
relative-agnostic.
>
> "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.
>
Relocation is defined on section 4.3.3 of 6P. We only define here that we
trigger
that mechanism when an user-defined PDR threshold is reached, compared to
the average PDR of all the other cells. Now, we do not go deep on how the
average
PDR is calculated (it may be calculated from the average PDR of all the
cells where
statistics are available except from the blacklisted ones). We also state
that the
replacement cell will be selected randomly among the unscheduled ones.
We do not define retries. If it fails, this will be retriggered on the next
slotframe
and a retry will be issued.
>
> Section "Scheduling Function Identifier"
>
> should not be: IANA_SFID_SF0 -> IANA_6TiSCH_SFID_SF0.
>
OK.
>
> 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?
>
change on the number of used cells towards any of the neighbours.
>
> 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 will be deleted now. As I explained before, we do not look on the
other neighbours just in case this may mean that a new allocation
will be reflected on any of the remaining neighbours.
> 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.
>
no incoming traffic triggering. Candidate for deletion.
>
> Section "SF0 Cell Estimation Algorithm"
>
> The Cell Estimation Algorithm takes into account the new incoming
> cell requirements
>
> - define somewhere what incoming cell requirements are?
>
I will delete this line.
>
> from the neighbor node and the current outgoing number of used cells.
>
> - idem, define outgoing
>
only used vs. scheduled, no 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?
>
to the particular neighbour. We are always scheduling to a single neighbour
at a time,
except for relocation, which monitors the whole schedule and relocates
accordingly.
>
> 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?
>
There should be statistics from the last slotframe on the number of
used cells (vs, the number of scheduled cells) towards each of the
neighbours. But this
is implementation specific and SF0 does not specify how this is collected.
>
> 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".
>
I like "transferred". Function calls are not a matter of SF0, but it can be
implemented that way.
>
> 4. Return to step 1 and wait for a triggering event.
>
> - Maybe a flow diagram would be a good complement to clarify its use.
>
OK.
>
> The OVERPROVISION parameter is a percentage of the
>
> currently allocated cells -> number of currently allocated cells
>
>
>
OK. This was proposed by Tengfei, but I have not seen tested yet compared
to a fixed implementation-specific value.
> - Why this link here. Maybe use a . and start a new sentence.
> e.g., The OVERPROVISION value is added to the used cells parameter ...
>
OK
>
> 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.
>
I wouldn't use retransmissions. SF0 should not to retransmit anything, we
only retrigger SF0
in case of failure. I think it could be better to say sudden increment in
traffic towards the neighbour.
But 1) and 2) are connected: no overprovisioned cells -> queue growth can
lead to packet loss.
>
>
> 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?
>
There is no relation. We keep both independent on purpose. One decides the
number
of cells to be scheduled, the other decides when. This avoids instability
by adding
hysteresis, but the allocation policy does not care on how the number of
requested cells was
chosen by the cell estimation algorithm.
This is one of the strong points of SF0. We have completely changed the
estimation
algorithm from one which had most information (knew about child, parent,
cell application
requests) to one that only knows the number of used cells vs. the scheduled
cells. and
the allocation policy did not change.
>
> Section "Rules for Celllist"
>
> How do you handle error situations? is there a retry-policy?
>
With respect to the retry policy, if the required cells are not satisfied,
SF0 will be retriggered.
The only condition (I find) we have not taken into account is when the
schedule is full,
and I have commented that several times without answer.
We can specify here a number of transactions taking advantage of the
celllist response
with the available cells (given the number of requested cells for
allocation), as a better
policy than choosing randomly each time SF0 is retriggered.
>
> 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?
>
I truly believe the timeout calculation does not belong to SF0, but to 6P.
That is why this sentence
is there. We have tried several schemes, but, in the end, they depend on
the transactions at the 6P
level. From my point of view, the only reason here is that if a transaction
fails during a slotframe,
it will be retriggered in the next.
>
> 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?
>
Succesfully delivered packets is acknowledged. I can change the term, no
problem if
it clarifies the idea. "to 10" will be deleted.
>
> , 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."
>
Because it is implementation specific. I will delete the former sentence.
>
> 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.
>
>From the comments I made above, I will uniformize terms and delete specific
algorithm explanations from the introduction.
> 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.
>
AFAIK, there are no configuration values except the PDR calculation.
However, there are thresholds and parameters which are
implementation-specific. I will add the missing flow diagram for the cell
estimation algorithm as requested. As I mentioned above, there is no
relation between SF0THRESH and OVERPROVISION. If there are available
simulations that show one possible relationship, we can add it as a
reference. I will remove the idea of hysteresis, and just mention that
improves stability by reducing the number of transactions and scheduling
events between nodes.
>
>
>
> --
> Dr. Xavier Vilajosana
> Wireless Networks Lab
>
> *Internet Interdisciplinary Institute (IN3)Professor*
> (+34) 646 633 681 <+34%20646%2063%2036%2081>
> [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
>
>
--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
