Re: [Detnet] Review of draft-ietf-detnet-pof-04 for the RTGDIR

Hi Henning,

Many thanks for your detailed review and good suggestions.

Please, find replies and resolutions as follows:

1, " duplicate text what happens when a packet is forwarded"

Agree, it might be seen as duplication, but they differ.

The difference of the third and fifth bullet points is that in the "Then" block of the third bullet point the packet is

forwarded without buffering. The fifth bullet describes action for a buffered packet.

I intend to clarify this by modifying the third bullet:

OLD TEXT

   *  If (seq_num <= POFLastSent + 1)

      -  Then the packet is forwarded and "POFLastSent" is updated

         (POFLastSent = seq_num).

NEW TEXT

   *  If (seq_num <= POFLastSent + 1)

      -  Then the packet is forwarded without buffering and "POFLastSent" is updated

         (POFLastSent = seq_num).

END

2, "why POFLastSent is always set to seq_num"

Yes, this is an interesting question. Both POF algorithm assume, that the POFMaxDelay parameter applied on a

buffered packet is correctly designed. It means, that a packet is removed from the buffer only if there is no chance

anymore to receive an earlier (smaller SeqNum) packet over the slowest path. (In practice that means that

POFMaxDelay > latency difference of the fastest and the slowest paths.) Therefore "if seq_num 10 already has

been forwarded and now seq_num 5 is being forwarded" is a broken scenario, with correctly designed POFMaxDelay

arrival of seq_num 5 is an invalid event or happened due to multiple network failures.

State and initialization of the basic POF algorithm are described on page 7, so I would propose no change to the text.

3, "circular sequence number space"

Thanks for pointing out this aspects. Right, implementation of Elimination is not defined in RFC8655. A possible

Implementation is described in IEEE 802.1CB, which I have added as reference.

OLD TEXT

   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.

NEW TEXT

   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. A possible implementation of the PEF function

   and the impact of the history window is described in [IEEE8021CB].

END

4, "Advanced POF Algorithm, maximum delay reached at exactly the same time"

Right, The following changes proposed:

NEW TEXT (added to the "Advanced POF" section)

    Note: for the "Advanced POF Algorithm" the path dependent delays

            might result in multiple packets triggering the "maximum delay

             reached" at exactly the same time. The transmission order of

             these packets then should be done in their seq_num order.

END

5, "Nitpick"

Right, Done as per your suggestion.

OLD TEXT

"POFMaxDelay_i"

NEW TEXT

"POFMaxDelay_i" for each possible path i

END

Again, many thanks for the detailed review. Above changes will be posted in v05 (very soon).

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 Henning Rogge
Sent: Monday, October 23, 2023 10:04 AM
To: detnet@ietf.org
Cc: rtg-dir@ietf.org; Daniam Henriques <daniam.henriques@liquid.tech>
Subject: [Detnet] Review of draft-ietf-detnet-pof-04 for the RTGDIR

Hi,

Denim Henriques of the RTGDIR secretaries asked me to review the latest draft-ietf-detnet-pof draft last Thursday. Unfortunately it seems I already got asked to review an earlier revision of the draft, but the request got lost (most likely on my side).

I read through draft-ietf-detnet-pof-04 and parts of RFC8655 and I think the concept of a POF function is pretty straight forward.

When reading through "4.3 The Basic POF Algorithm" I see a couple of issues that could use clarification (or a fix).

First, I would suggest eliminating the duplicate text what happens when a packet is forwarded. The fifth bullet point on page 6 already states what has to be done, so you can remove the POFLastSent update in the "Then" block of the third bullet point.

Second, I would like to hear a clarification on why POFLastSent is always set to seq_num when a package is transmitted and not only if seqnum is larger than POFLastSent. When a package with sequence number X is forwarded for any reason, everything with a smaller sequence number than X should be instantly forwarded (order is already being disrupted anyways).

As an example, if seq_num 10 already has been forwarded and now seq_num 5 is being forwarded, I would still expect seq_num 7 to 9 going through the POF, which doesn't happen if POFLastSent is reset to 5. If this is correct, I would suggest something like "POFLastSent = max(POFLastSent, seq_num)" in the algorithm.

Third, the Note on page 6 hints (correctly) that comparison (and maximum detection) can be done but is a bit tricky in circular sequence number space. I could not find an example how to handle this in RFC 8655, so maybe putting an example of how to do it sequence number overflow in an appendix could improve this document.

Lastly, for the "Advanced POF Algorithm" the path dependent delays might result in multiple packets triggering the "maximum delay reached" at exactly the same time. It might be worth writing down that the transmission order of these packets then should be preserver, should be done in seq_num order or that it doesn't matter.

Nitpick:

in the description of the POFMaxDelay_i in "5. Control and Management Plane Parameters for POF" it might be a good idea to mention that this represents multiple parameters, e.g.

"POFMaxDelay_i" for each possible path i

Henning Rogge

_______________________________________________

detnet mailing list

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

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