Re: [Detnet] draft-varga-detnet-pof (sorry, lot of input)
Toerless Eckert <tte@cs.fau.de> Wed, 11 August 2021 21:49 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662843A2678 for <detnet@ietfa.amsl.com>; Wed, 11 Aug 2021 14:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO5rWSXROQVK for <detnet@ietfa.amsl.com>; Wed, 11 Aug 2021 14:49:38 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA793A2640 for <detnet@ietf.org>; Wed, 11 Aug 2021 14:49:36 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0447F548015; Wed, 11 Aug 2021 23:49:25 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (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 <tte@cs.fau.de>
To: Balázs Varga A <balazs.a.varga@ericsson.com>
Cc: "detnet@ietf.org" <detnet@ietf.org>
Message-ID: <20210811214924.GA1823@faui48f.informatik.uni-erlangen.de>
References: <20210730224049.GB9775@faui48e.informatik.uni-erlangen.de> <AM0PR07MB53470FA231A1BEF81A8F7396ACF19@AM0PR07MB5347.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AM0PR07MB53470FA231A1BEF81A8F7396ACF19@AM0PR07MB5347.eurprd07.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/2Bb-gJl6AkVE79MNZysVntYOsvY>
Subject: Re: [Detnet] draft-varga-detnet-pof (sorry, lot of input)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=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 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 <detnet-bounces@ietf.org> On Behalf Of Toerless Eckert > Sent: Saturday, July 31, 2021 12:41 AM > To: detnet@ietf.org > 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 > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet -- --- tte@cs.fau.de
- Re: [Detnet] draft-varga-detnet-pof (sorry, lot o… Toerless Eckert
- [Detnet] draft-varga-detnet-pof (sorry, lot of in… Toerless Eckert
- Re: [Detnet] draft-varga-detnet-pof (sorry, lot o… Balázs Varga A
- Re: [Detnet] draft-varga-detnet-pof (sorry, lot o… Toerless Eckert
- Re: [Detnet] draft-varga-detnet-pof (sorry, lot o… Toerless Eckert
- Re: [Detnet] draft-varga-detnet-pof (sorry, lot o… Balázs Varga A
- Re: [Detnet] draft-varga-detnet-pof (sorry, lot o… Toerless Eckert
- Re: [Detnet] draft-varga-detnet-pof (sorry, lot o… Balázs Varga A
- Re: [Detnet] draft-varga-detnet-pof (sorry, lot o… Norman Finn
- Re: [Detnet] draft-varga-detnet-pof (sorry, lot o… Toerless Eckert