Re: [Detnet] AD Review of draft-ietf-detnet-pof-04

Hi Roman,

Many thanks for your detailed review and good suggestions.

Please, find replies and resolutions as follows:

1, "idnits"

Right, solved by removing Section "2.3.  Requirements Language"

2, " Section 1, 3 errors in-a-row"

Right, this is a common error threshold for industrial applications.

I have named this example explicitly.

OLD TEXT

   ... 3 errors in-a-row is a usual error threshold and

   can cause the application to stop (e.g., to go to a fail-safe state).

NEW TEXT

   ... For example, in industrial scenarios 3 errors in-a-row is a usual error threshold and

   can cause the application to stop (e.g., to go to a fail-safe state).

END

3, “Section 4.3, Sequence number”

OK, text added:

NEW TEXT

    In general, the use of PREOF functions require sequencing information

    to be included in the packets of a DetNet compound flow.  This can be

    done by adding a sequence number as part of DetNet encapsulation

     [RFC8655].  Sequencing information is typically added once, at or

    close to the source.

END

4, “Section 4.3, History window”

OK, clarification added, see previous mail to Henning.

5, Is “delay difference” than the worst-case value for the end-to-end latency?

There can be multiple POF functions applied for a DetNet flow. It is the worst case value up to the POF

function location. If POF is at the egress of the DetNet domain, then end-to-end.

6, Section 4.3.  Editorial.  Per Figure 3, are “fastest” and “slowest” the right adjectives to use for a time duration?

Right, we have selected fastest/slowest as e.g., a shorter path with low speed interfaces may cause bigger latency.

Proposed change:

-- “fastest path delay” to “path with min delay”?

-- “slowest path delay” to “path with max delay”?

7, Section 4.5, parameter design

OK, note added as proposed.

NEW TEXT

   Design of these parameters is out-of-scope in this document.

END

Above changes will be posted in v05 (today).

Please, let us know if You think further changes are needed.

Thanks

Bala’zs

-----Original Message-----
From: detnet <detnet-bounces@ietf.org> On Behalf Of Roman Danyliw
Sent: Friday, October 27, 2023 6:44 PM
To: detnet@ietf.org
Subject: Re: [Detnet] AD Review of draft-ietf-detnet-pof-04

Feedback from idnits:

  Miscellaneous warnings:

  ----------------------------------------------------------------------------

  == The document doesn't use any RFC 2119 keywords, yet seems to have RFC

     2119 boilerplate text.

> -----Original Message-----

> From: Roman Danyliw

> Sent: Friday, October 27, 2023 12:36 PM

> To: detnet@ietf.org<mailto:detnet@ietf.org>

> Subject: AD Review of draft-ietf-detnet-pof-04

>

> Hi!

>

> I performed an AD review on draft-ietf-detnet-pof-04 to help load

> balance the IESG PubReq queue.  Thanks for this document.  I have the

> following feedback, largely to improve clarity.

>

> Please review and respond to Henning Rogge's review at

> https://datatracker.ietf.org/doc/review-ietf-detnet-pof-04-rtgdir-earl

> y-rogge-

> 2023-10-23/ -- thanks Henning!

> In particular, please review his hypothetical case of seq= 10, 5, 7

> and 9 per the algorithm in Section 4.3.

>

> ** Section 1.

>    3 errors in-a-row is a usual error threshold and

>    can cause the application to stop (e.g., to go to a fail-safe

> state)

>

> What is the basis for assessment that 3 is a common error threshold in

> applications?

>

> ** Section 4.3. I am unsure of the framing assumed with of Detnet as

> it applies here.  Is there obvious basic assumption around the seq_num

> coming from a layer 2 or 3 protocol (e.g., it has one?  Which one

> would you choose?)  Please add text similar to Section 1 of

> draft-ietf-detnet-mpls-over-ip-preof-07 without the reference to timestamps:

>

>    In general, the use of PREOF functions require sequencing information

>    to be included in the packets of a DetNet compound flow.  This can be

>    done by adding a sequence number or time stamp as part of DetNet

>    encapsulation.  Sequencing information is typically added once, at or

>    close to the source.

>

> ** Section 4.3.

>    Note: the difference of sequence number in consecutive packets is

>    bounded due to the history window of the Elimination function before

>    the POF.  Therefore "<=" can be evaluated despite of the circular

>    sequence number space.

>

> As far as I can tell find, the “history window of the elimination

> function” is not defined.

>

> ** Section 4.3

>    *  "POFMaxDelay", which cannot be smaller than the delay difference

>       of the paths used by the flow.

>

> Is “delay difference” than the worst-case value for the end-to-end latency?

>

> ** Section 4.3.  Editorial.  Per Figure 3, are “fastest” and “slowest”

> the right adjectives to use for a time duration?

> -- “fastest path delay” to “shortest path delay”?

> -- “slowest path delay” to “longest path delay”?

>

> ** Section 4.5.  Recommend repeating what was already said in Section

> 4.3, “Design of these parameters is out-of-scope in this document.”

>

> Regards,

> Roman

_______________________________________________

detnet mailing list

detnet@ietf.org<mailto:detnet@ietf.org>

https://www.ietf.org/mailman/listinfo/detnet