Subject: Re: [Detnet] detnet Digest, Vol 86, Issue 16

From: Ludovic Thomas <[email-masked]>
Date: Thu, 14 Oct 2021 19:28:56 +0200

Hi all,

we have performed the worst-case delay analysis of the PREOF functions 
and of their interactions with traffic regulators (either per-flow or 
interleaved, as in TSN-ATS).

Our main findings are:

- The traffic profile at the output of the PEF depends on both the 
traffic profile just before the PEF (on the paths to be merged) and on 
the topology between the PRF (Packet-Replication Function) and the PEF. 
We thus agree with Balázsthat both factors do play a role. If we only 
consider the incoming traffic profiles before the PEF to compute the 
output traffic profile (an approach denoted as "intuitive" in the 
preprint), then the obtained latency bounds are much worse than the 
tight model, as we illustrate on an industrial use-case. Delay bounds 
can also be obtained in more complex networks with several duplication 
locations (several PRFs) for a unique PEF, or the opposite.

- Placing a POF (packet ordering function) after a PEF further increases 
the burstiness of the flow.

- Placing a regulator (per-flow or TSN-ATS) after the PEF such that the 
regulator reinforces the source contract makes the redundancy 
"transparent" to downstream nodes. But if the regulator is placed 
directly after the PEF, then it incurs a delay penalty: PEF + PFR 
(per-flow regulator) comes with a bounded delay penalty, however PEF + 
ATS can induce unbounded latencies, unbounded backlogs and congestion 
losses.

- Placing a POF between the PEF and the regulator solves the above issue 
(this gives the configuration "PEF + POF + regulator"). But, for the 
case of ATS, it is not sufficient for the POFs to reorder each flow 
independently (as written today in RFC8655). The POF must reorder the 
whole aggregate as a unique flow in order to solve the above issue, when 
using ATS.

We hope that this provides additional insights on the possible 
combinations for PEF, POF and the regulators.
The results have been obtained using Network Calculus and if you are 
interested, the following preprint contains more details: 
https://arxiv.org/pdf/2110.05808.pdf
To obtain the results on PEF+POF, we have reused the results from 
https://arxiv.org/pdf/2008.03075.pdf regarding packet mis-ordering in 
time-sensitive networks and their reordering using POF.

Cheers,

Ludovic, Ahlem and Jean-Yves

(sorry moderators for the previous email with wrong sender address)

Le 21/09/2021 à 21:00, [email-masked] a écrit :
> Send detnet mailing list submissions to
> 	[email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/detnet
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
>
> You can reach the person managing the list at
> 	[email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of detnet digest..."
>
> Today's Topics:
>
>     1. Re: Policing/shaping and related calculus [was
>        draft-varga-detnet-pof (sorry, lot of input)] (Toerless Eckert)
>
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 19 Oct 2021 18:05:41 +0000

Hi Ludovic, Ahlem and Jean-Yves,

Many thanks for the analysis. Very interesting reading.
Helps definitely during DetNet network design (e.g.,
proper placement of functionalities).

ATS related findings may be interesting for IEEE folks as well.

Cheers
Bala'zs

From: detnet <[email-masked]> On Behalf Of Ludovic Thomas
Sent: Thursday, October 14, 2021 7:29 PM
To: [email-masked]
Subject: Re: [Detnet] detnet Digest, Vol 86, Issue 16

Hi all,
we have performed the worst-case delay analysis of the PREOF functions and of their interactions with traffic regulators (either per-flow or interleaved, as in TSN-ATS).

Our main findings are:

- The traffic profile at the output of the PEF depends on both the traffic profile just before the PEF (on the paths to be merged) and on the topology between the PRF (Packet-Replication Function) and the PEF. We thus agree with Balázsthat both factors do play a role. If we only consider the incoming traffic profiles before the PEF to compute the output traffic profile (an approach denoted as "intuitive" in the preprint), then the obtained latency bounds are much worse than the tight model, as we illustrate on an industrial use-case. Delay bounds can also be obtained in more complex networks with several duplication locations (several PRFs) for a unique PEF, or the opposite.

- Placing a POF (packet ordering function) after a PEF further increases the burstiness of the flow.

- Placing a regulator (per-flow or TSN-ATS) after the PEF such that the regulator reinforces the source contract makes the redundancy "transparent" to downstream nodes. But if the regulator is placed directly after the PEF, then it incurs a delay penalty: PEF + PFR (per-flow regulator) comes with a bounded delay penalty, however PEF + ATS can induce unbounded latencies, unbounded backlogs and congestion losses.

- Placing a POF between the PEF and the regulator solves the above issue (this gives the configuration "PEF + POF + regulator"). But, for the case of ATS, it is not sufficient for the POFs to reorder each flow independently (as written today in RFC8655). The POF must reorder the whole aggregate as a unique flow in order to solve the above issue, when using ATS.

We hope that this provides additional insights on the possible combinations for PEF, POF and the regulators.
The results have been obtained using Network Calculus and if you are interested, the following preprint contains more details: https://arxiv.org/pdf/2110.05808.pdf
To obtain the results on PEF+POF, we have reused the results from https://arxiv.org/pdf/2008.03075.pdf regarding packet mis-ordering in time-sensitive networks and their reordering using POF.

Cheers,

Le 21/09/2021 à 21:00, [email-masked]<mailto:[email-masked]> a écrit :

  [email-masked]<mailto:[email-masked]>

  [email-masked]<mailto:[email-masked]>

  [email-masked]<mailto:[email-masked]>

Today's Topics:

detnet mailing list

[email-masked]<mailto:[email-masked]>

---

From: Ludovic Thomas <[email-masked]>
Date: Thu, 21 Oct 2021 11:42:51 +0200

Hi Balázs,

thanks a lot for your feedback and for your suggestion.
I believe that we plan to share this with the TSN folks, but we haven't 
decided/found the best way to do it so far...

Cheers,
Ludovic

PS: I'm changing the subject for more clarity.
My previous mail was intended to follow your conversation with Toerless 
but I did not answer to the correct email.

Le 19/10/2021 à 20:05, Balázs Varga A a écrit :
> Bala’zs
> *From:* detnet <[email-masked]> *On Behalf Of *Ludovic Thomas
> *Sent:* Thursday, October 14, 2021 7:29 PM
> *To:* [email-masked]
> *Subject:* Re: [Detnet] detnet Digest, Vol 86, Issue 16
>
> Hi all,
>
> the topology between the PRF (Packet-Replication Function) and the 
> PEF. We thus agree with Balázsthat both factors do play a role. If we 
> only consider the incoming traffic profiles before the PEF to compute 
> the output traffic profile (an approach denoted as "intuitive" in the 
> - Placing a regulator (per-flow or TSN-ATS) after the PEF such that 
> the regulator reinforces the source contract makes the redundancy 
> - Placing a POF between the PEF and the regulator solves the above 
> issue (this gives the configuration "PEF + POF + regulator"). But, for 
> the case of ATS, it is not sufficient for the POFs to reorder each 
> flow independently (as written today in RFC8655). The POF must reorder 
> the whole aggregate as a unique flow in order to solve the above 
> issue, when using ATS.
>
>
> <https://arxiv.org/pdf/2110.05808.pdf>
> https://arxiv.org/pdf/2008.03075.pdf 
> <https://arxiv.org/pdf/2008.03075.pdf> regarding packet mis-ordering 
> in time-sensitive networks and their reordering using POF.
>
> Cheers,
>
> Le 21/09/2021 à 21:00, [email-masked] 
> <mailto:[email-masked]> a écrit :
>
>        [email-masked]  <mailto:[email-masked]>
>
>        https://www.ietf.org/mailman/listinfo/detnet  <https://www.ietf.org/mailman/listinfo/detnet>
>
>        [email-masked]  <mailto:[email-masked]>
>
>        [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>
>     https://www.ietf.org/mailman/listinfo/detnet  <https://www.ietf.org/mailman/listinfo/detnet>
>