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: =?iso-8859-1?Q?Bal=E1zs?= 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