[Detnet] DetNet: Question against

Toerless Eckert <tte@cs.fau.de> Fri, 24 June 2022 01:19 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 58E7AC15A759 for <detnet@ietfa.amsl.com>; Thu, 23 Jun 2022 18:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.66
X-Spam-Level:
X-Spam-Status: No, score=-6.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HIBN50QuAeN for <detnet@ietfa.amsl.com>; Thu, 23 Jun 2022 18:19:00 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32AE5C15A747 for <detnet@ietf.org>; Thu, 23 Jun 2022 18:18:58 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 99D6158C4B0; Fri, 24 Jun 2022 03:18:52 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 871B64EB27E; Fri, 24 Jun 2022 03:18:52 +0200 (CEST)
Date: Fri, 24 Jun 2022 03:18:52 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: detnet@ietf.org
Cc: balazs.a.varga@ericsson.com, janos.farkas@ericsson.com, rodney.cummings@ni.com, jiangyuanlong@huawei.com, dfedyk@labn.net
Message-ID: <YrUQ/EiflZM+111v@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/jtFZ5br_cEw7kTuFVnk-IWWmETw>
Subject: [Detnet] DetNet: Question against
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.39
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, 24 Jun 2022 01:19:02 -0000

Dear DetNet WG, RFC9016 authors

I am trying to understand how to map the traffic specification commonly used
in deterministic queuing mechanisms such as TSN ATS to those in RFC9016 section
5.5, and to understand how the claim in that section

"These attributes can be used to describe any type of traffic (e.g., CBR, Variable Bitrate (VBR), etc.)"

 makes sense.

Q1) In my reading of 5.5, a flow may send in every interval

  MaxPacketsPerInterval * MaxPayloadSize

correct ?

Q2) What is supposed to happen if a flow asks for 

  MinBandwidth < (MaxPacketsPerInterval * MaxPayloadSize) / Interval

Is that supposed to be an error resulting in rejection of the admission
request, or should the DetNet acccept the admission and discard or
demote (non DetNet level of service) received packet that exceed MinBandwidth
but that are still still within the traffic specification (MaxPacketsPerInterval * MaxPayloadSize) / Interval ?

Q4) If Q2 is it's supposed to be an error

Q5) If my interpretation of Q1) is correct, then i can not
see how either the admission control system nor the forwarding plane
could take into account for example the MinPacketsPerInterval number ?
Especially given the fact that it may be a complete bogus number, and
the flow would never send anything less than its Max* - because
there is no Traffic Specification parameter forcing the flow
to vary (somehow) between Min* and Max*.

Q4) If R = (MaxPacketsPerInterval * MaxPayloadSize) / Interval is smaller
than the ingres link rate, and let's say MinBandwidth is requested to be R,
Is the flow then permitted to send its MaxPacketsPerInterval back to back
at the ingres link rate ? That would instantaneously exceed MinBandwidth.
If the flow was required to have within Interval an inter-packet
gap to not exceed the MinBandwidth (if it still wants DetNet treatment).

Thanks!
    Toerless