Re: [Detnet] draft-varga-detnet-pof (sorry, lot of input)

Toerless Eckert <> Wed, 11 August 2021 21:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 662843A2678 for <>; Wed, 11 Aug 2021 14:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UO5rWSXROQVK for <>; Wed, 11 Aug 2021 14:49:38 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BA793A2640 for <>; Wed, 11 Aug 2021 14:49:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0447F548015; Wed, 11 Aug 2021 23:49:25 +0200 (CEST)
Received: by (Postfix, from userid 10463) id F1ED34400EF; Wed, 11 Aug 2021 23:49:24 +0200 (CEST)
Date: Wed, 11 Aug 2021 23:49:24 +0200
From: Toerless Eckert <>
To: Balázs Varga A <>
Cc: "" <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [Detnet] draft-varga-detnet-pof (sorry, lot of input)
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: Wed, 11 Aug 2021 21:49:56 -0000

High level answer:

If we would start to describe the management interface, e.g.:
what we want be able to configure and observe about all of PREOF
(maybe starting with POF), then i think we will immediately get
to the point that we expect a much more explicit description of
what PREOF/POF has to do so that it can comply with that management

I am saying this because when i did design features in the past it
did work out best by first starting to think about how the operator
should see the feaure. Otherwise a lot was forgotten. In the
IETF i did admittedly wiggle myself around doing this 100% correctly,
by just informally referring to the CLI/config aspects (such as RFC8994),
but that was primarily because for that work the manaement work is
really big, so it didn't first. Writing a yang module into a POF
draft itself should be rather painless in comparison.

>From there on out, we can start to see how well we could describe
the per-hop-behavior, if that is how we are allowed to call it.

Details hat may be missing are about stuff like: what if a packet
arrives whose sequence number does not fall into the window
of sequence numbers that the POF currently accepts ? Ok, we discard
it. We update a counter tracking these events. Do we update
our POF state machinery ? Maybe that needs to be configurable.
Should the window-size of sequence number be configurable, etc. pp

Good info about TSN. Thanks


On Wed, Aug 04, 2021 at 10:15:15AM +0000, Balázs Varga A wrote:
> Hi Toerless,
> Many thanks for the comments. Some clarifications/reactions:
> a) "per hop behavior"
> In general I agree, "unexpected behavior of DetNet products" must be avoided.
> We have already POF specifics in DetNet RFCs:
> - RFC8655: introduces the term POF
> - RFC8938: gives some characteristics of POF (uses sequence numbers, range of 
> packet order protection, buffer resources)
> - RFC8964: defines POF packet processing (section
> What is missing in your view?
> Regarding terminology I also dislike "input vs. outbut timing for traffic " as POF
> is not about explicit timing but order of packets.
> b) Management interface
> Yes, management is an important topic. If I understand your comment correctly
> You are more concerned about the operation/maintenance related 
> counters/parameters. I think it is a valid comment, but in my view it might be 
> better to discuss it in the OAM related drafts. 
> In this draft all the POF algorithm's specific parameters are defined. E.g., required
> buffer space can be derived from these parameters and the network/flow specifics.
> c) TSN standards about ordering function
> There were discussions about ordering in TSN, but nothing standardized.
> d) "Another algorithm option: configure for every packet copy path a fixed time delay"
> I think this topic needs more clarification. Some comments:
> - I do not see differences in topologies used by TSN and by DetNet. Rings are also typical
> in TSN networks.
> - We have a path specific delay parameter defined in section "4.4. The Advanced POF 
> Algorithm", namely "POFMaxDelay_i". 
> - I am not sure your proposal is a POF function or a PDF (Packet Delay Function).
> Again, thanks for the review and the comments.
> Cheers
> Bala'zs
> -----Original Message-----
> From: detnet <> On Behalf Of Toerless Eckert
> Sent: Saturday, July 31, 2021 12:41 AM
> To:
> Subject: [Detnet] draft-varga-detnet-pof (sorry, lot of input)
> Balazs, *:
> I very much support work on POF, however:
> I think we should aim higher than informational guidelines
> I think we can build a normative document on two interfaces:
> a) "per hop behavior"
>    We can stanardize the externally observable behavior
>    between arriving and sent packets on the node.
>    This was regularily done for DiffServ Traffic Classes in
>    TSVWG, where it is calle Per Hop Behavior. When i tried
>    to apply this term to the input vs. outbut timing for
>    traffic from what today is an IntServ flow (DetNet),
>    David Black was somewhat concerned about re-use of the
>    term, which is why i wrote "per hop behavior". IMHO,
>    it is perfectly valid to also call this PHB, but i will
>    leave it up to David to recommend appropriate terminology.
>    I am only interested to be able to get as little as possible
>    unexpecte behavior of DetNet products, and we can only 
>    arrive that if we standardize the behavior.
> b) Management interface
>    Yang module specifying what the operator 
>    can observe about the function about the POF function, e.g: 
>    "static" parameters such as how many buffers there are available,
>      algorithm (you do have algorithm in the draft)
>     - maybe read/write if configurable.
>    "dynamic parameters" - read-only for monitoring, troubleshooting:
>      - buffers dynamically used,
>      - latency between first and further copies
>      - missing packets
>      - ...
> Now wrt to other content:
> c) It would be lovely to have a section summarizing what if anythng
>    TSN did standardize about their ordering function for all those
>    IETF participants too lazy to read all that documentation
>    and/or rejecting the notion of having to pay money to read a document.
>    (informational, appendix).
> d) I think it would be great to have anoher algorithm option
>    by which one could configure for every packet copy path
>    (assuming we can identify that in the forwardin plane)
>    a fixed time delay.
>    The reason for this, and why i think it was not an issue in
>    TSN (with its typical topologies) is that in DetNets
>    we much more likely will have rings with significant path 
>    latency differences between A and B path,
>    and whenever the A (shorter) path looses a packet, we would wait
>    until the B path packet arrives, resulting in a lot of
>    jitter. If the DetNet controller could configure 
>    the B-A pah lateny difference as a delay, we could get rid
>    of this problem.
> Still have to dig deeper into the algo details you proposed for more comments.
> Cheers
>     Toerless
> _______________________________________________
> detnet mailing list