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

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

Hi Fan,

Thanks for the clarification questions. In my view the answers are implementation dependent.

In general all the PREOF functions (PRF, PEF, POF) have a “sequence number” related state and
they are running independently. There can be various triggers for resetting a PREOF function.

A reset can be triggered by management operation (reset of the PxF function, reset of the node
or some part of the node, etc.). Further, reset can be triggered to recover from a failure, for
example when a failure of the PxF detected and it triggers a reset.

Another group of triggers are related to events/states of other entities. Such triggers are used to
ensure faster recovery of a function (via resetting it) after network failures. For example, if a POF
do not receive packets for a while, because of network failure(s), then its state regarding the actual
sequence number of a DetNet flow is outdated and it may result in a wrong decision of the POF
function whether a packet should be delayed or not.

I will discuss with the co-authors to update the reset related part to clarify it better.

Thanks & Cheers
Bala’zs


From: Yangfan (IP Standard) <[e-mail]>
Sent: Wednesday, May 12, 2021 11:57 AM
To: Balázs Varga A <[e-mail]>; Ludovic Thomas <[e-mail]>; [e-mail]
Subject: 答复: [Detnet] Packet Ordering Function (draft-varga-detnet-pof-00.txt)


Hi Bala'zs,



Thank you for bring up this draft. As Greg said, the mechanism is well designed and clearly written. Thank you for the work!

I have a question about the reset of POF function mentioned in section 4.2. I am not sure the reset is likely to refer to a situation of a POF failure or a management operation. Is this POF state necessary and obligatory? I don’t  see any consequence if we remove the definition of state.

Since you mentioned the reset of sequence number on replication node, I wonder if the sequence number (SN) state of PEF is affected by SN reset of PRF, whether SN state of PEF will affect SN state of POF? Are they synchronized or running independently?



Regards,

Fan


发件人: detnet [mailto:[e-mail]] 代表 Balázs Varga A
发送时间: 2021年4月22日 16:10
收件人: Ludovic Thomas <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
主题: Re: [Detnet] Packet Ordering Function (draft-varga-detnet-pof-00.txt)

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://protect2.fireeye.com/v1/url?k=6ac54b90-355e7292-6ac50b0b-869a14f4b08c-c0c40f341c519780&q=1&e=4748c352-f42d-4190-96f8-71b4da870f66&u=https%3A%2F%2Fwww.ieee802.org%2F1%2Ffiles%2Fpublic%2Fdocs2020%2Fnew-varga-FRER-seamless-reset-0320-v02.pdf>
https://www.ieee802.org/1/files/public/docs2019/new-varga-FRER-improvements-0719-v01.pdf<https://protect2.fireeye.com/v1/url?k=835d1e68-dcc6276a-835d5ef3-869a14f4b08c-dfe9cf40bb45eda7&q=1&e=4748c352-f42d-4190-96f8-71b4da870f66&u=https%3A%2F%2Fwww.ieee802.org%2F1%2Ffiles%2Fpublic%2Fdocs2019%2Fnew-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]<mailto:[e-mail]>> On Behalf Of Ludovic Thomas
Sent: Wednesday, April 21, 2021 10:53 AM
To: [e-mail]<mailto:[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