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

Ludovic Thomas <> Thu, 14 October 2021 17:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BB033A177D for <>; Thu, 14 Oct 2021 10:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q4wm8u5gQOq3 for <>; Thu, 14 Oct 2021 10:29:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B39BE3A1758 for <>; Thu, 14 Oct 2021 10:29:31 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 900D223973 for <>; Thu, 14 Oct 2021 17:28:59 +0000 (UTC)
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 0FA4A233C3D13 for <>; Thu, 14 Oct 2021 17:28:58 +0000 (UTC)
Authentication-Results:; auth=pass (GARM-102R0046c13c2a2-3fc5-4f06-88d1-2009e7ea460b, 116C8763F641FDE7E28AF166465A2968031563BB)
References: <>
From: Ludovic Thomas <>
Message-ID: <>
Date: Thu, 14 Oct 2021 19:28:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020200010609060506060709"
X-Ovh-Tracer-Id: 7555632800377696541
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvtddrvdduvddgudduudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepuffvfhfhkffffgggjggtsehgtdertedtfeehnecuhfhrohhmpefnuhguohhvihgtucfvhhhomhgrshcuoehluhguohhvihgtrdhthhhomhgrshesfihoohhlrggsrdhfrheqnecuggftrfgrthhtvghrnhephefghfeggeekfeejfeduhfekfeehfeevudevleegfeegfedtheegteehgeduteehnecuffhomhgrihhnpegrrhigihhvrdhorhhgpdhivghtfhdrohhrghenucfkpheptddrtddrtddrtddpudelfedrheegrdduvddvrdeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrjeekkedrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehluhguohhvihgtrdhthhhomhgrshesfihoohhlrggsrdhfrhdprhgtphhtthhopeguvghtnhgvthesihgvthhfrdhorhhg
Archived-At: <>
Subject: Re: [Detnet] detnet Digest, Vol 86, Issue 16
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Oct 2021 17:29:38 -0000

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 

- 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:
To obtain the results on PEF+POF, we have reused the results from regarding packet mis-ordering in 
time-sensitive networks and their reordering using POF.


Ludovic, Ahlem and Jean-Yves

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

Le 21/09/2021 à 21:00, a écrit :
> Send detnet mailing list submissions to
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> You can reach the person managing the list at
> 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