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

From: Balázs Varga A <[email-masked]>
Date: Wed, 4 Aug 2021 10:15:15 +0000

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 4.2.2.3)
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 <[email-masked]> On Behalf Of Toerless Eckert
Sent: Saturday, July 31, 2021 12:41 AM
To: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Aug 2021 23:49:24 +0200

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
inerface.  

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

Toerless

-- 
---
[email-masked]