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

[Toerless Eckert <[e-mail]>]

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


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

-- 
---
[e-mail]