Re: [auth48] AUTH48: RFC-to-be 9550 <draft-ietf-detnet-pof-11> for your review

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.


1) <!-- [rfced] This is a question for Stephan and Tobias. Would you like to use
a shortened form of your affiliation in the first-page header and then
the full name in the Authors' Addresses section? Please review the
first-page header in each of the output formats (txt, html, and pdf), and
let us know your thoughts.
-->


2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->


3) <!-- [rfced] Would it be helpful to revise this sentence to state that
"[RFC8655] defines" rather than "The DetNet Working Group has defined"?
In addition, please clarify "but without any implementation details" in
the second sentence below.

Original:
   The DetNet Working Group has defined packet replication (PRF) and
   packet elimination (PEF) functions for achieving extremely low packet
   loss.  PRF and PEF are described in [RFC8655] and provide service
   protection for DetNet flows.  
   ...
   The IETF DetNet WG has defined
   in [RFC8655] the external observable result of a POF function, i.e.,
   that packets are reordered, but without any implementation details.   

Perhaps: 
   [RFC8655] defines the Packet Replication Function
   (PRF) and Packet Elimination Function (PEF) in DetNet for achieving extremely
   low packet loss. PRF and PEF provide service protection for DetNet flows.
   ...   
   [RFC8655] defines the external observable result of a POF
   function (i.e., that packets are reordered) but does not specify any implementation
   details.
-->


4) <!-- [rfced] Please confirm that [RFC8655] is correct here. We believe it is
correct, but we want to make sure. We see "sequence number" and
"encapsulation" in RFC 8655 but not used together.

Original:
   This can be
   done by adding a sequence number as part of DetNet encapsulation
   [RFC8655].  
-->


5) <!-- [rfced] Are the parentheses needed here with "DetNet"?

Original:
   POF ensures in-order delivery for packets being within the latency bound of
   the (DetNet) flow. 

Perhaps: 
   POF ensures in-order delivery for packets within the latency bound of
   the DetNet flow. 
-->


6) <!-- [rfced] The title of Section 3 uses "POF Implementations", but the first
sentence in the section uses "POF function". Should these be consistent?

Original:
   3.  Requirements on POF Implementations

      The requirements on a POF function are:

Perhaps: 
   3.  Requirements for POF Implementations

      The requirements for POF implementations are:
-->


7) <!-- [rfced] Would moving "in network nodes" to the end of the sentence
improve readability? Also, please review "states/configuration parameters
and resources". Specifically, is "states" separate from "configuration
parameters", or does "states/configuration" describe the type of
parameters?

Original:
   *  to be simple and to require in network nodes only a minimum set of
      states/configuration parameters and resources per DetNet Flow.

Perhaps:
   *  To be simple and to require only a minimum set of
      states, configuration parameters, and resources per DetNet flow in network nodes.

Or ("states" to "state"):
   *  To be simple and to require only a minimum set of
      state/configuration parameters and resources per DetNet flow in network nodes.
-->


8) <!-- [rfced] The text above Figure 2 uses "Conditional buffer", but Figure 2
uses "Conditional Delay Buffer". Should the figure be updated for
consistency with the text or vice versa?
-->


9) <!-- [rfced] Please review "the difference of sequence number" in these
sentences. Is the intended meaning "the difference between sequence
numbers"?
     
Original:
   Note: the difference of sequence number in consecutive packets is
   bounded due to the history window of the Elimination function before
   the POF.  
   ...
   For example, under normal
   circumstances the difference of sequence number in consecutive
   packets is bounded due to the history window of PEF.    

Perhaps:
   The difference between sequence numbers in consecutive packets is
   bounded due to the history window of the elimination function
   before the POF.  
   ...
   For example, under normal
   circumstances, the difference between sequence numbers in consecutive
   packets is bounded due to the history window of PEF. 
-->


10) <!-- [rfced] We updated "Packets being in order" as shown below. Please review.

Original:
   Packets being in order are not delayed. 

Updated:
   In-order packets are not delayed.
-->


11) <!-- [rfced] Please confirm that "relations" is the correct word choice here. 

Original:
   Figure 3 shows the delay budget relations at the POF point.
   ...
   Figure 3: Delay Budget Relations at the POF Point

Perhaps:
   Figure 3 shows the relationship between delay budgets at the POF point.
   ...
   Figure 3: Relationship between Delay Budgets at the POF Point
-->


12) <!-- [rfced] In the text introducing the list, may we update "needs two
extensions of" in one of the following ways to improve clarity?

Original:
   The advanced POF algorithm needs two extensions of the basic POF
   algorithm:

   *  to identify the received packet's path at the POF location and

   *  to make the value of "POFMaxDelay" for buffered packets path
      dependent ("POFMaxDelay_i", where "i" notes the path the packet
      has used).
   
Perhaps: 
   The advanced POF algorithm extends the basic POF
   algorithm:

   *  to identify the received packet's path at the POF location and

   *  to make the value of "POFMaxDelay" for buffered packets path
      dependent ("POFMaxDelay_i", where "i" notes the path the packet
      has used).

Or:
   The advanced POF algorithm requires extensions of the basic POF
   algorithm:

   *  to identify the received packet's path at the POF location and

   *  to make the value of "POFMaxDelay" for buffered packets path
      dependent ("POFMaxDelay_i", where "i" notes the path the packet
      has used).
-->


13) <!-- [rfced] How may we clarify the beginning of this sentence (i.e.,
"By....information")? Also, should "POFMaxDelay_i" appear in parentheses?

Original:
   By identifying the path of a given packet, the POF algorithm can use
   this information to select what predefined time "POFMaxDelay_i" to
   apply for the buffered packet.  

Perhaps: 
   The POF algorithm identifies the path of a given packet and uses
   this information to select the predefined time ("POFMaxDelay_i") to
   apply for the buffered packet.  
-->


14) <!-- [rfced] We are having trouble understanding the text in the parenthetical
(i.e., "e.g., replication...PathID"). Please clarify.

Original:
   It can be implemented via
   various techniques, for example using ingress interface information,
   encoding the path in the packet itself (e.g., replication functions
   can set different FlowID per egress what can be used as a PathID), or
   in other means.  

Perhaps: 
   It can be implemented via
   various techniques, for example, using ingress interface information,
   encoding the path in the packet itself (e.g., replication functions
   can set a different FlowID per egress, which can be used as a PathID), or
   other means.  
-->


15) <!-- [rfced] Please review "for example" here. Is it needed, or would it be
more clear if placed elsewhere in the sentence?

Original:
   The challenge for POF initialization is that for example after a
   reset it is not known whether the first received packet is in-order
   or out-of-order.  

Perhaps:
   The challenge for POF initialization is that it is not known whether the
   first received packet is in order or out of order (for example, after a
   reset).

Or:
   The challenge for POF initialization is that after a
   reset, it is not known whether the first received packet is in-order
   or out-of-order.  
-->


16) <!-- [rfced] Should "(see before)" be updated to a specific section? If not,
we will update to "(see above)".

Original:
   The original initialization (see before) considers
   the first packet as in-order, so out-of-order packet(s) during
   "POFMaxTime"/"POFMaxTime_path_i" time - after the first packet was
   received - cannot be corrected.  
-->


17) <!-- [rfced] Will "basic/advanced" be clear to readers? 

Original:
   *  No basic/advanced POF rules are applied until the first timer
      expires.
      ...
   *  The basic/advanced POF rules are applied for the packet(s) in the
      buffer and the subsequently received packets.

Perhaps: 
   *  No basic or advanced POF rules are applied until the first timer
      expires.
      ...
   *  The basic or advanced POF rules are applied for the packet(s) in the
      buffer and the subsequently received packets.
-->


18) <!-- [rfced] How may we update "needs setting of" in this sentence?
	   
Original:
   POF algorithms needs setting of the following parameters:

Perhaps: 
   The following parameters should be set for POF algorithms:

Or:
   POF algorithms require the following parameters to be set:
-->


19) <!-- [rfced] We tried to access the URL in this reference entry, but it is
behind a sign-in wall. Also, it looks like this reference entry points to
a draft that has now been published. May use one of the following URLs
and update the rest of the entry accordingly (e.g., title, DOI, and
date)?

Possible URLs:
https://standards.ieee.org/ieee/802.1CBcv/7285/
https://ieeexplore.ieee.org/document/9715061

Original:
   [IEEEP8021CBcv]
              Kehrer, S., "FRER YANG Data Model and Management
              Information Base Module", IEEE P802.1CBcv
              /D1.2 P802.1CBcv, March 2021,
              <https://www.ieee802.org/1/files/private/cv-drafts/d1/802-
              1CBcv-d1-2.pdf>.

Perhaps:
   [IEEEP8021CBcv]
             IEEE, "IEEE Standard for Local and metropolitan area networks - Frame
             Replication and Elimination for Reliability - Amendment 1: Information
	     Model, YANG Data Model, and Management Information Base Module,
             IEEE Std 802.1CBcv-2001, DOI 10.1109/IEEESTD.2022.9715061, February 2022,
             <https://standards.ieee.org/ieee/802.1CBcv/7285/>.
-->


20) <!-- [rfced] We updated these names in the Acknowledgements section. Please
review and let us know any concerns.

a) Per https://datatracker.ietf.org/person/[e-mail]:

Original:
  Mohammadpour Ehsan

Updated:
  Ehsan Mohammadpour 


b) Per https://datatracker.ietf.org/person/[e-mail]:

Original:
  Shirley Yangfan

Updated:
  Fan Yang
-->


21) <!-- [rfced] Should "algorithm" be updated to "algorithms" (plural) in the
following sentences as both a basic and advanced POF algorithm are
defined in Section 4? Or in some of these instances (perhaps the last two
below), is the intent to say "the basic POF algorithm" or "the advanced
POF algorithm"?

Original:
   The Packet Ordering Function (POF)
   algorithm described herein enables to restore the correct packet
   order when replication and elimination functions are used in DetNet
   networks.  
   ...
   4.6.  Selecting and using the POF algorithm
   ...
   The POF Algorithm discussed in this document makes some assumptions
   and tradeoffs regarding the characteristics of the sequence of
   received packets.
   ...
   In particular, the algorithm assumes that a Packet
   Elimination Function (PEF) is performed on the incoming packets
   before they are handed to the POF function.
   ...
   The algorithm further requires that the delay difference between two
   replicated packets that arrive at the PEF before the POF is bounded
   and known.
   ...
   The algorithm also makes some tradeoffs.
   ...
   Note2: The algorithm can be extended to cope with multiple failure
   scenarios (i.e., simultaneous packet loss and out-of-order packets), ...
   ...
   By identifying the path of a given packet, the POF algorithm can use
   this information to select what predefined time "POFMaxDelay_i" to
   apply for the buffered packet.  
-->


22) <!-- [rfced] Terminology

a) We see inconsistency in the capitalization of the following. We updated to
use the lowercase form. Please let us know any objections.

Replication and Elimination function
replication and elimination functions
replication function
Elimination function


b) Should "function" be removed in these instances because the expansion of
the acronym already includes the word "Function"? For example, if expanded,
"POF function" would read "Packet Ordering Function function".

PEF function
POF function
PREOF functions


c) Use of quotation marks for the following terms is inconsistent. Please
review and let us know how to update for consistency.

"POFLastSent" vs. POFLastSent

"POFMaxDelay" vs. POFMaxDelay

"POFMaxDelay_i"

"POFMaxTime"/"POFMaxTime_path_i"

"POFTakeAnyTime"


d) Please review the usage of the articles "a" or "the" with PEF, PRF, and POF
when used as a noun. An article is used in some instances but not others. Are
any updates needed, or is the current usage acceptable? This may be on a
case-by-case basis. A few examples with and without the article are listed
below.

Some examples with article (the POF, the POF, the PEF):

   Note: the difference of sequence number in consecutive packets is
   bounded due to the history window of the Elimination function before
   the POF.  

   Error cases in which duplicate packets are
   presented to the POF can lead to out of order delivery of duplicate
   packets as well as to increased delays.

   The algorithm further requires that the delay difference between two
   replicated packets that arrive at the PEF before the POF is bounded
   and known. 

Some examples with no article (PEF, POF, POF):

   For example, under normal
   circumstances the difference of sequence number in consecutive
   packets is bounded due to the history window of PEF.  

   POF only provides ordering within the latency bound of a
   DetNet flow, and does not provide any additional reliability.

   POF ensures in-order delivery for packets being within the latency
   bound of the (DetNet) flow.  POF does not correct errors in the
   packet flow e.g., duplicate packets, too late packets.
-->


23) <!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for 
content that is semantically less important or tangential to the 
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->


24) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Note that our script did not
flag any words in particular, but this should still be reviewed as a best
practice.
-->


Thank you.

RFC Editor/rv



On Mar 1, 2024, at 5:32 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2024/03/01

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

  Please review and resolve any questions raised by the RFC Editor 
  that have been included in the XML file as comments marked as 
  follows:

  <!-- [rfced] ... -->

  These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

  Please ensure that you review any changes submitted by your 
  coauthors.  We assume that if you do not speak up that you 
  agree to changes submitted by your coauthors.

*  Content 

  Please review the full content of the document, as this cannot 
  change once the RFC is published.  Please pay particular attention to:
  - IANA considerations updates (if applicable)
  - contact information
  - references

*  Copyright notices and legends

  Please review the copyright notice and legends as defined in
  RFC 5378 and the Trust Legal Provisions 
  (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

  Please review the markup in the XML file to ensure that elements of  
  content are correctly tagged.  For example, ensure that <sourcecode> 
  and <artwork> are set correctly.  See details at 
  <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

  Please review the PDF, HTML, and TXT files to ensure that the 
  formatted output, as generated from the markup in the XML file, is 
  reasonable.  Please note that the TXT will have formatting 
  limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:

  *  your coauthors

  *  [e-mail] (the RPC team)

  *  other document participants, depending on the stream (e.g., 
     IETF Stream participants are your working group chairs, the 
     responsible ADs, and the document shepherd).

  *  [e-mail], which is a new archival mailing list 
     to preserve AUTH48 conversations; it is not an active discussion 
     list:

    *  More info:
       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc

    *  The archive itself:
       https://mailarchive.ietf.org/arch/browse/auth48archive/

    *  Note: If only absolutely necessary, you may temporarily opt out 
       of the archiving of messages (e.g., to discuss a sensitive matter).
       If needed, please add a note at the top of the message that you 
       have dropped the address. When the discussion is concluded, 
       [e-mail] will be re-added to the CC list and 
       its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
— OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files 
-----

The files are available here:
  https://www.rfc-editor.org/authors/rfc9550.xml
  https://www.rfc-editor.org/authors/rfc9550.html
  https://www.rfc-editor.org/authors/rfc9550.pdf
  https://www.rfc-editor.org/authors/rfc9550.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9550-diff.html
  https://www.rfc-editor.org/authors/rfc9550-rfcdiff.html (side by side)

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9550-xmldiff1.html

Alt-diff of the text (allows you to more easily view changes 
where text has been deleted or moved): 
  https://www.rfc-editor.org/authors/rfc9550-alt-diff.html

The following files are provided to facilitate creation of your own 
diff files of the XML.  

Initial XMLv3 created using XMLv2 as input:
  https://www.rfc-editor.org/authors/rfc9550.original.v2v3.xml 

XMLv3 file that is a best effort to capture v3-related format updates 
only: 
  https://www.rfc-editor.org/authors/rfc9550.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9550

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9550 (draft-ietf-detnet-pof-11)

Title            : Deterministic Networking (DetNet): Packet Ordering Function
Author(s)        : B. Varga, J. Farkas, S. Kehrer, T. Heer
WG Chair(s)      : Lou Berger, János Farkas

Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston