Subject: [Roll] Review of draft-ietf-roll-nsa-extension-02

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Tue, 25 Jun 2019 19:56:28 -0400

Dear all,
              My review of the draft below:

- The abstract should include more details about the purpose
of packet replication and the context where the metric will
be used. Is it an Objective Function? Is it a new mechanism?

- I think abbreviations such as "aka" shall be avoided

- The expression " to achieve their goal" shall be put in context.
Which is the goal? Maybe it is easier to write "Network-enabled
applications in the industrial context must provide..."

- The phrase "In order

   for wireless networks to be able to be used in such applications, the
   principles of Deterministic Networking
[I-D.ietf-detnet-architecture
<https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-02#ref-I-D.ietf-detnet-architecture>]
   lead to designs that aim at maximizing packet delivery rate and
   minimizing latency and jitter."

should be rewritten differently, it is a little bit complex and long.
>From that expression, I understand that if you are aiming to apply detnet
principles to LLNs, the design shall comply with these principles. Am I
right?

- "uses a fixed communication schedule" is it fixed? I think it could be
better to explain that by using timeslots, TSCH looks like TDMA in the time
dimension (and only for better understanding).

-  "provide a hard bound" isn't it "to provide"? and "and limit jitter"
should be "to limit"?

- "achieves a controlled redundancy" to "achieves controlled redundancy"

- "within the remit of" I do not understand the expression.

- "The specification of the transmission of this information is the focus
of this document."
could it be "This document focuses on the specification of the transmission
of this specific path information"

- "More concretely" to "Specifically"

- "children nodes of the node" of the parent node? maybe "children of the
parent node"?

- "This specification defines the type value and structure for this TLV" to
"This specification defines the type value and structure for the parent
address set TLV". Is there an abbreviation of the parent address set (such
as PAS)?

- "The sending of multiple" to "The transmission of multiple" is better
here.

- "The sending of multiple copies of a packet using multi-path forwarding
over a multi-hop network and the consolidation of multiple received packet
copies to control flooding."
looks awkward. The verb is missing.

- " [I-D.papadopoulos-6tisch-pre-reqs
<https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-02#ref-I-D.papadopoulos-6tisch-pre-reqs>]
for more." to " [I-D.papadopoulos-6tisch-pre-reqs
<https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-02#ref-I-D.papadopoulos-6tisch-pre-reqs>]
for more details.

- "The problem of how to select the next hop target node for a packet copy
to be forwarded to when performing packet replication." can be rephrased:
"Defines the mechanism to choose the next hop node to forward a packet copy
when replicating" (although I think still needs some work on it)

- "Preferred Parent (PP)" is defined after PP is used for the first time.

- "AP node, functionality which is included in the operation of the RPL
Objective
   Function (OF)." to "AP node. This functionality which is included in the
operation of the RPL Objective Function (OF)."

- "A scheme which allows the two paths to remain

   correlated is detailed here.  More specifically, in this scheme a
   node will select an AP node close to its PP node to allow the
   operation of overhearing between parents.  If multiple potential APs
   match this condition, the AP with the lowest rank will be registered".

I think this expression can be improved eliminating the first part.
"The node will select an AP node close to its PP node to allow the operation
of overhearing between parents. If multiple potential APs match this
condition, the AP with the lowest rank will be registered".

- I have not seen anything about overhearing before this point. I think
overhearing can be either explained shortly or referenced to another
document.

- In general, from the abstract and the title, I was expecting only the
technical description of the extension, without the AP selection mechanism.
>From my point of view, either the mechanism should be described in another
document and referenced in this one, or the goal of the document shall be
expanded to include the mechanism too.

-  Moreover, the description of the NSA extension can be expanded to be
used for other selection mechanisms which may consider different criteria
to take advantage of  alternative parent selection.

As always, open to any comments on the above.
Regards,

                                Diego

-- 
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

---

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Fri, 28 Jun 2019 17:45:26 +0200 (CEST)

Hello Diego,

thank you very much for reviewing the draft and for providing us with your
feedback.
The issue of scope also might concern Rahul as well, so I have CCed him as
well.

Responses follow inline.

> be used. Is it an Objective Function? Is it a new mechanism?

As you guessed and as you said in another of your comments further below,
the scope of this draft may need some clarification. Up to this point, the
from feedback that we have received and from discussions with others, we
took the path of providing some introductory material as well as examples
of potential uses of the Parent Set information in an Objective Function.
However, and this is the main point, the draft only specifies the
information to be transferred, its encoding, compression, etc. How exactly
it is to be used (Objective Function) is outside the specification. The
options are to:
a) Create another document with the operation of an OF which uses this
b) Extend this draft with the spec of an OF that uses the information.

Since there is already work by Rahul which might take advantage of the same
information in a different way, we chose a).
Rahul, any comments?

In any case, do you think that
"This document details what information needs to be
transmitted and how it is encoded within a packet to enable this
functionality."

 is not clear enough?

> - I think abbreviations such as "aka" shall be avoided

Absolutely, thanks. An instance of "aka" and "one" of i.e. have been
replaced.

> applications in the industrial context must provide..."

No problem. What do you think about this rephrase:
"Network-enabled applications in the industrial context must provide stringent
guarantees in terms of reliability and predictability. To achieve this they
typically leverage 1+1 redundancy, also known as Packet Replication and
Elimination (PRE) [I-D.papadopoulos-6tisch-pre-reqs
<https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-02#ref-I-D.papadopoulos-6tisch-pre-reqs>
].

>    principles of Deterministic Networking [I-D.ietf-detnet-architecture <https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-02#ref-I-D.ietf-detnet-architecture>]

Yes, you are correct. This is the idea.
What do you think about this rephrase:
"Allowing these kinds of applications to function over wireless networks
requires the application of the principles of Deterministic Networking [I-D.
ietf-detnet-architecture
<https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-02#ref-I-D.ietf-detnet-architecture>].This
results in designs which aim at maximizing packet delivery rate and
minimizing latency and jitter."

> dimension (and only for better understanding).

Well, actually the schedule is not completely fixed, at least not
permanently.
The point is that with TSCH you can avoid probabilistic medium access by
having a common agreed-upon schedule.

Maybe this rephrase is better?

"As an example, to meet this goal, IEEE Std. 802.15.4 [IEEE802154-2015
<https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-02#ref-IEEE802154-2015>]
provides
Time-Slotted Channel Hopping (TSCH), a mode of operation which uses a
common communication schedule
based on timeslots to allow deterministic medium access as well as ..."

> -  " isn't it "to provide"? and "and limit jitter" should be "to limit"?
>

Thanks, fixed.

> - "achieves a controlled redundancy" to "achieves controlled redundancy"

Yes, thanks, fixed.

> - "within the remit of" I do not understand the expression.

Means within the area of responsibility of. Rephrased as:
"which is among the responsibilities of the RPL Objective Function"

> could it be "This document focuses on the specification of the
> transmission of this specific path information"
>

Sure, thanks. Rephrased as suggested.

> - "More concretely" to "Specifically"

It is followed by "this specification focuses ..".
It would become: "Specifically, this specification focuses .."
Left as is, unless a bigger rephrase is required.

> - "children nodes of the node" of the parent node? maybe "children of the

Yes, better, rephrased as "children of the node".

> - "This specification defines the type value and structure for this TLV"
> to "This specification defines the type value and structure for the
> parent address set TLV". Is there an abbreviation of the parent address
> set (such as PAS)?
>

No problem, replaced as suggested. The abbreviation is PS (Parent Set).

> - "The sending of multiple" to "The transmission of multiple" is better

No problem. Replaced as suggested.

> over a multi-hop network and the consolidation of multiple received
> packet copies to control flooding."

Well, the defined term is a noun so for me it makes sense that there is no
verb. I would agree that it is a bit complex, however. Rephrased to:
"A method which transmits multiple copies of a packet using multi-path
forwarding over a multi-hop network and which consolidates multiple
received packet copies
to control flooding. See "Exploiting Packet Replication and Elimination in
Complex Tracks in 6TiSCH LLNs"
[I-D.papadopoulos-6tisch-pre-reqs
<https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-02#ref-I-D.papadopoulos-6tisch-pre-reqs>]
for more details."

> <https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-02#ref-I-D.papadopoulos-6tisch-pre-reqs>]

No problem. Fixed.

> when replicating" (although I think still needs some work on it)

Thanks. As a first step rephrased to:
"The mechanism for choosing the next hop node to forward a packet copy when
replicating packets."

Good catch, thanks. Fixed.

>    Function (OF)." to "AP node. This functionality which is included in
> the operation of the RPL Objective Function (OF)."
>

No problem, replaced as suggested.

> condition, the AP with the lowest rank will be registered".

Thank you for the comment. In this instance I would prefer that
"A scheme which allows the two paths to remain correlated is detailed
here."
is kept, because at this point the draft only gives an **example** of a
potential scheme for alternative parent selection, with the specific
feature that the two paths remain correlated. There are other options
available and this draft at this point does not propose any choice.
I would like to keep it clear that this scheme is not part of the spec
itself.
I am of course open for discussion.

> overhearing can be either explained shortly or referenced to another

Very good point. This is actually the only mention of overhearing, since
although it is beneficial to performance and we do use it in our
implementation, it is in no way required for this spec. Overhearing is only
mentioned here because keeping the paths correlated increased the chances
of taking advantage of overhearing.
I have referenced a section in papadopoulos-6tisch-pre-reqs which explains
it a bit more for those interested.

> expanded to include the mechanism too.

I agree that this is an issue. As I have answered to your first comment in
more detail, for now the answer has been that this draft only specifies the
parent set information, not the Objective Function.
We can definitely discuss this though.

> to take advantage of  alternative parent selection.

Sure, any ideas are very welcome. :)

> As always, open to any comments on the above.

Again, thank you very much for the help.
A new version of the draft (draft-ietf-roll-nsa-extension-03) has been
posted with the discussed changes.

Best,
Aris

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Sat, 29 Jun 2019 02:11:49 +0000

I actually prefer having OF defined in the same document. Having OF defined gives a clear context on how to use the newly defined metrics/constraints. Secondly we have very few OCPs defined till date. We have just used 2 OCPs from a total of 65536 (last OCP was defined almost 8 years back). In your case you already have done experiments and you have the test-bed… so we might as well try to get OF done in the same experiment.

…. we took the path of providing some introductory material as well as examples of potential uses of the Parent Set information in an Objective Function.
However, and this is the main point, the draft only specifies the information to be transferred, its encoding, compression, etc. How exactly it is to be used (Objective Function) is outside the specification. The options are to:
a) Create another document with the operation of an OF which uses this
b) Extend this draft with the spec of an OF that uses the information.

Since there is already work by Rahul which might take advantage of the same information in a different way, we chose a).
Rahul, any comments?