[Detnet] draft-varga-detnet-pof (sorry, lot of input)
Toerless Eckert <tte@cs.fau.de> Fri, 30 July 2021 22:41 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 28E563A1444 for <detnet@ietfa.amsl.com>; Fri, 30 Jul 2021 15:41:02 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 97OjRMKuZ7QA for <detnet@ietfa.amsl.com>; Fri, 30 Jul 2021 15:40:55 -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 D6CEE3A143A for <detnet@ietf.org>; Fri, 30 Jul 2021 15:40:54 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 966AD548005 for <detnet@ietf.org>; Sat, 31 Jul 2021 00:40:49 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 88B3A4E7BC3; Sat, 31 Jul 2021 00:40:49 +0200 (CEST)
Date: Sat, 31 Jul 2021 00:40:49 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: detnet@ietf.org
Message-ID: <20210730224049.GB9775@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/zuK12XGKuvQ4q2skfBM83Mr1XPM>
Subject: [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: Fri, 30 Jul 2021 22:41:02 -0000
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
- 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