Re: [Detnet] Packet Ordering Function (draft-varga-detnet-pof-00.txt)

[Balázs Varga A <[e-mail]>]

Hi Ludovic,

Many thanks for your comments, really appreciated.

Your comments pointed to some characteristics of POF, what may need to be better highlighted in the draft.
- DetNet uses PREOF for service protection and DetNet excludes usage of ECMP (RFC8964). So, any out-of-order
is caused by PREF (more exactly, out-of-order is caused by PEF).
- POF is never a standalone function in DetNet scenarios, there is always a PEF function before POF applied. The
impact of PEF function on the packet flow must be considered when POF is engineered or evaluated. We may
use for the analysis the rather detailed specification of IEEE 802.1CB on Replication and Elimination functions.
- DetNet uses a circular sequence number space, so comparing 2 sequence numbers is always relative.

Regarding your comments:
1, “POFTakeAnyTime"
Yes, reboot of the source (or just a reset of the sequence generation function in PRF) results in a possible sequence
number order (inside the DetNet network) as described in your example. However, the packet flow hits first the PEF,
having a history window. The PEF will discard the packets with sequence number below 1000, so they will not be
processed by the POF.
Section 4.5 in the draft, refers to that impact of PEF with an example:
“   … For example, under normal circumstances the
   difference of sequence number in consecutive packets is bounded due
   to the history window of PEF.”

I think based on your comment, that impact of PEF would be worth to highlight more in the next version of the draft.
Dealing with reset/reboot scenarios is not a trivial task and may need further markers/flags traveling with the packet.
Reset related improvements were discussed in IEEE, you may check here:
https://www.ieee802.org/1/files/public/docs2020/new-varga-FRER-seamless-reset-0320-v02.pdf
https://www.ieee802.org/1/files/public/docs2019/new-varga-FRER-improvements-0719-v01.pdf

2, “POFLastSent update”
Here I do not agree with your conclusion. The POF algorithm never “stucks”. POF maximum impact on a
packet is to delay it for “POFMaxDelay” time. “POFMaxDelay” is engineered to ensure that the packet
is still within its latency budget.
So as in your example: yes, packet103 will be delayed for POFMaxDelay time. Packet104, packet105
etc. (when received in-order) will be delayed less (if at all). All packets remains within the latency budget.
Average latency is somewhat increased but in case of DetNet we do not care about average, the target is
to be within the bounded latency, what is achieved for all packets.

Thanks & Cheers
Bala’zs

From: detnet <[e-mail]> On Behalf Of Ludovic Thomas
Sent: Wednesday, April 21, 2021 10:53 AM
To: [e-mail]
Subject: Re: [Detnet] Packet Ordering Function (draft-varga-detnet-pof-00.txt)


Hi all, I have two thoughts on it:

=======

1/ what are you thoughts in changing:

"""" [Current version]

The next received packet must be forwarded and the POFLastSent

      updated wheno the POF function was reset OR no packet was received

      for a predefined time ("POFTakeAnyTime").

""""



for



""" [Proposed version]

The next received packet must be forwarded and the POFLastSent

      updated wheno the POF function was reset OR no packet with a seq_num strictly higher (>) than POFLastSent was received

      for a predefined time ("POFTakeAnyTime").

"""

?



Consider the following use-case:



Source has been up for a while, at POF point we received and sent thousand packets such that POFLastSent = 1000

Suddenly the source reboots and the reboot is so fast that the time elapsed between:

               - when packet noted 1000 was sent prior to reboot

               - when packet noted 0 is sent after reboot

is less or equal to the inter-packet spacing. (meaning the time elapsed between 1000 and 0 is about the same or even less than between 999 and 1000).

As such, in any coherent design the time elapsed between 1000 and 0 is less than POFTakeAnyTime.



Now assume POF function receives 1000, 0, 3, 1, [a sequence of out-of order packets], 100, 102, 101, 104, 103 ... again with a spacing between 1000 and 0 that is less than POFTakeAnyTime.



* With the current version, after reception of 1000, timer is started, but reset as soon as 0 is received.

At the end of the day each receiving packet resets the timer before it fires, so POFLastSent stays at 1000 and all packets are forwarded without being reordered until the sequence number reaches 1000 again.



* With the proposed version, neither 0 nor 3, 1, etc resets the timer because their sequence number is <= POFLastSent.

After some time (say just BEFORE packet 100) the timer is fired, POFLastSent is set to 100 and starting from there is the output of POF is back in order.



======



2/ also, the draft states



o  If (seq_num <= POFLastSent + 1)



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

         (POFLastSent = seq_num).



I believe we shouldn't update POFLastSent if the seq_num is <= POFLastSent. In the above example, assume the POFTakeAnyTime is fired just AFTER packet 100. Packet 102 is received, is sent and sets POFLastSent=102.

With the current version, 101 is received, is sent (because seq_num <= POFLastSent + 1) and sets POFLastSent=101, from there the system is stuck because 102 will never be received again, and the following packets will be released after the POFMaxDelay expires.

With the proposed version (no update of POFLastSent if the seq_num is <= POFLastSent), then 101 does not set POFLastSent=101 and the system continues normal operation.



======



My two cents,

Ludovic