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

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

Hi Henning,

I think my clarification was not detailed and clear enough or I
have missed something in your example.

DetNet has defined many building blocks. Some are responsible for 
bounded latency, some are focusing on reliability. PREOF is 
targeting lossless delivery. None of the PREOF functions care 
whether a packet is too-late or in-time. It is not their 
task.

The only occasion when latency matters for PREOF is during the network 
design. When configuring PREOF components (their network location,
used paths over the network, etc.) the network designer must 
consider the "delay budget" of the communication (e.g., excluding 
paths with too much delay).

As multiple paths are used simultaneously by PREOF, some paths are 
faster, some are slower. POF is not able to decide whether a packet 
is too-late or not, but that is not needed for POF to work. 

POF always forwards packets, it never drops any packet. 

POF intends to give a chance for a missing packet to arrive over the
slow path. If it happens it will forward packets with correct order.
If it does not happen or the missing packet arrives too-late (compared 
to the intended design (see above)), then POF cannot correct the order, 
but will forward the packet.

Regarding your example:
- it is a severely unhealthy scenario from DetNet perspective
- several packets are missing (2,3,4,5,6,7,9)
- if seq_num 10 and 8 are too-late POF cannot make the situation 
better (but it is not a task for POF).
- seq_num 10 and 8 are always forwarded by POF
- yes, seq_num 11 will be buffered, but if it is "in-time" it does 
not matter as the buffering time is designed according to the "delay 
budget" (again see above). So it will be delivered "in-time".

Cheers
Bala'zs

-----Original Message-----
From: Henning Rogge <[e-mail]> 
Sent: Wednesday, November 8, 2023 10:24 AM
To: Balázs Varga A <[e-mail]>
Cc: [e-mail]; [e-mail]; Daniam Henriques <[e-mail]>
Subject: Re: [Detnet] Review of draft-ietf-detnet-pof-04 for the RTGDIR

On Wed, Nov 8, 2023 at 10:07 AM Balázs Varga A <[e-mail]> wrote:
>
> Hi Henning,
>
> Thanks for further clarifications. I think that highlights the 
> somewhat different mindset deterministic communication related 
> functions follow. The per packet replication and elimination are used 
> for applications those require extreme parameters on loss, i.e., practically lossless communication.
> Replication (PRF) and Elimination (PEF) are doing their job to ensure 
> this lossless communication. POF is intended to correct the rare 
> side-effect (i.e., out-of-order
> delivery) resulted from PRF/PEF.
>
> With those in mind, POF should never drop any packet as it would harm 
> the application (requiring lossless communication). If POF configured 
> incorrectly (like in your example), then it will not correct 
> out-of-order delivery. However dropping packets would make the 
> situation even worst for the application. Dropping out-of-order packets is a task for the application, if it decides to do so for too late or out-of-order packets.
>
> I hope these clarifies your concerns.

Sorry, I have my problem with this point of view...

If out-of-order packets arriving too late are an invalid state, you should not modify your protocol control variable, regardless of the decision if you want to forward them or not. Protocols should be robust against failures of communication partners.

Imagine the following sequence of packets.

seq 1: arriving in time
seq 10: arriving too late (invalid state?) seq 8: arriving out-of-order AND too late (also invalid state?), this will set POFLastSent to 8 seq 11: arriving in time, but will be delayed by buffer because POFLastSent is 8.

regardless of the decision if sequence number 10 and 8 are delivered or not (which should be defined in the document), sequence number 11 should not be buffered.

Henning Rogge