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

["Georgios Z. Papadopoulos" <[e-mail]>]

Hello Pascal,

Noted, we will updated it accordingly.

many thanks,
Giorgos


> On Jul 1, 2019, at 15:57, Pascal Thubert (pthubert) <[e-mail]> wrote:
> 
> Hello Remous
>  
> maximizing packet delivery rate and minimizing latency and jitter."
>  
> The goal is to optimize packet delivery within bounded latency. For some flows the controller can also minimize the latecy but only a few. Think of an ambulance with all the green lights as it traverses the city. Other important vehicles e.g., police, will have to wait more. Minimizing jitter can be a secondary goal, not always.
>  
>  
>  
> "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
>  
> Please use dateless reference unless you want to quote a particular text or section that may move or go away in the next respin.
> e.g.,
>  
>       <reference anchor="IEEE802154">
>          <front>
>             <title>IEEE Std. 802.15.4, Part. 15.4: Wireless Medium Access
>             Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate
>             Wireless Personal Area Networks
>             </title>
>             <author>
>                <organization>IEEE standard for Information Technology</organization>
>             </author>
>             <date/>
>          </front>
>       </reference>
>  
>  
> All the best,
>  
> Pascal
>  
> From: Roll <[e-mail]> On Behalf Of Remous-Aris Koutsiamanis
> Sent: vendredi 28 juin 2019 17:45
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Cc: Georgios Z. Papadopoulos <[e-mail]>
> Subject: Re: [Roll] Review of draft-ietf-roll-nsa-extension-02
>  
> 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.
>  
> On Wed, Jun 26, 2019 at 1:56 AM Prof. Diego Dujovne <[e-mail] <mailto:[e-mail]>> wrote:
> 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?
>  
> 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.
>  
>  
> - 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..."
>  
> 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>].
>  
>  
> - 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?
>  
> 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."
>  
>  
> - "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).
>  
> 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"
>  
> - "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"
>  
> 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 parent node"?
>  
> 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 here.
>  
> No problem. Replaced as suggested. 
>  
> - "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.
>  
> 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."
>  
> - " [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.
>  
> No problem. Fixed.
>  
> - "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)
>  
> Thanks. As a first step rephrased to: 
> "The mechanism for choosing the next hop node to forward a packet copy when replicating packets."
>  
> - "Preferred Parent (PP)" is defined after PP is used for the first time.
>  
> Good catch, thanks. Fixed.
>  
> - "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)."  
>  
> No problem, replaced as suggested.
>  
> - "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".
>  
> 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.
>  
> - I have not seen anything about overhearing before this point. I think overhearing can be either explained shortly or referenced to another document. 
>  
> 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.
>  
> - 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.
>  
> 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.
>  
> -  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. 
>  
> Sure, any ideas are very welcome. :)
>  
>  
> As always, open to any comments on the above.
> Regards,
>  
>                                 Diego 
>  
> 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
> 
>  
>  
>  
> -- 
> DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Informática y Telecomunicaciones
> Facultad de Ingeniería - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl <http://www.ingenieria.udp.cl/>
> (56 2) 676 8125
> _______________________________________________
> Roll mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>