Re: [Detnet] DetNet working meetings on scaling/queueing

Toerless Eckert <tte@cs.fau.de> Mon, 10 April 2023 03:51 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 1B000C14CE24 for <detnet@ietfa.amsl.com>; Sun, 9 Apr 2023 20:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.947
X-Spam-Level:
X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 hfzcI8Ic6Xm0 for <detnet@ietfa.amsl.com>; Sun, 9 Apr 2023 20:51:01 -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 8A088C14CF1B for <detnet@ietf.org>; Sun, 9 Apr 2023 20:50:59 -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 4Pvw4F4kcXznkYV; Mon, 10 Apr 2023 05:50:53 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4Pvw4F43v4zkvYQ; Mon, 10 Apr 2023 05:50:53 +0200 (CEST)
Date: Mon, 10 Apr 2023 05:50:53 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Yizhou Li <liyizhou@huawei.com>
Cc: "Black, David" <David.Black@dell.com>, "detnet@ietf.org" <detnet@ietf.org>
Message-ID: <ZDOHnc8UeQ9fjqHM@faui48e.informatik.uni-erlangen.de>
References: <MN2PR19MB404569D92C4E0AE8166B221B83969@MN2PR19MB4045.namprd19.prod.outlook.com> <7d1a2f15cd254697a6c0e53bab965468@huawei.com> <MN2PR19MB4045CA45E8345BABF4B58FAD83959@MN2PR19MB4045.namprd19.prod.outlook.com> <aa543cb8cff34d8a968b35b0e716d570@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <aa543cb8cff34d8a968b35b0e716d570@huawei.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/4Tk3O12gcThxTUP33Nw1tW6EMlw>
Subject: Re: [Detnet] DetNet working meetings on scaling/queueing
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: Mon, 10 Apr 2023 03:51:06 -0000

Thanks, Yizhou, agree.

David, *:

TO add from my side:

IMHO both drafts describe the same same underlying queuing mechanism. If there are discrepancies,
then i think they would mostly be bugs/easily corrected. But the drafts differ in what type
of details they include, each of us trying to include what we felt was necessary/important to
capture - in my drafts case i was specifically trying to rely on pseudocode to describe the
behavior and add systematic components based on WG feedback, such as minimal ingres shaping,
calculation of clock offsets (so developers of controllers will understand what they would
need to do), and so on.

I do also agree with Yizhou, that it would be good to understand what we would need to have in
the standard track documents first, and then figure out what additional informational
drafts would have to describe. From our first round of discussing this (back from the times
of IETF Bangkok), i also had the impression that describing an actual on-the-wire encoding
was the most easy way for the IETF to agree that a mechanism was describing something that
requires standardization (on the wire interoperability).

I guess it would be useful to have in our upcoming regular meetings some discuss about
what type of details proposals should include and how, and maybe how to break up or
merge proposals so each draft is better in a shape of what ultimately a WG could adopt
(and i do not mean this for all drafts on the table, not just our cyclic queuing ones).

Cheers
    Toerless


On Mon, Apr 10, 2023 at 02:32:25AM +0000, Yizhou Li wrote:
> Hi David,
> 
> If we set aside MPLS label, DSCP, IP options, long/short fields etc, the scheduling mechanisms are quite similar.
> 
> >From the perspective of elaboration, there are some differences.
> 
> draft-yizhou-detnet-ipv6-options-for-cqf-variant explains more on what are the problems and which part of scheduling needs to be extended to adapt to large scale network and to migrate from fundamental 2-buffer or 3-buffer CQF.
> 
> It looks to me that IETF usually has no normative language to describe queueing or scheduling.
> So if the group think it would be better to put scheduling as a standalone documents without touching how the info to be carried, I think it could be done by merging some text from both. Toerless and I started some conversations in IETF 116, maybe we can use some of the working session time to discuss this as well?
> 
> 
> Thanks,
> Yizhou
> 
> From: Black, David [mailto:David.Black@dell.com]
> Sent: Monday, April 10, 2023 9:50 AM
> To: Yizhou Li <liyizhou@huawei.com>; detnet@ietf.org
> Cc: Black, David <David.Black@dell.com>
> Subject: RE: DetNet working meetings on scaling/queueing
> 
> Hi Yizhou,
> 
> If we (temporarily) set aside where the cycle identification information is carried in each packet (that will need to be addressed, later), what are the differences between the scheduling mechanisms in  draft-yizhou-detnet-ipv6-options-for-cqf-variant and draft-eckert-detnet-tcqf ?
> 
> Thanks, --David
> 
> From: Yizhou Li <liyizhou@huawei.com<mailto:liyizhou@huawei.com>>
> Sent: Sunday, April 9, 2023 8:52 PM
> To: Black, David; detnet@ietf.org<mailto:detnet@ietf.org>
> Cc: Black, David
> Subject: RE: DetNet working meetings on scaling/queueing
> 
> 
> [EXTERNAL EMAIL]
> Hi David,
> 
> There is one more draft draft-yizhou-detnet-ipv6-options-for-cqf-variant-01 related to scheduling. Would you please add to the list?
> 
> I would like to  give a more detailed presentation if the time permits in one of the open working meetings.
> 
> Thanks,
> Yizhou
> 
> 
> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Black, David
> Sent: Saturday, April 8, 2023 5:13 AM
> To: detnet@ietf.org<mailto:detnet@ietf.org>
> Cc: Black, David <David.Black@dell.com<mailto:David.Black@dell.com>>
> Subject: [Detnet] DetNet working meetings on scaling/queueing
> 
> With the first of these working meetings coming up next week (Tuesday evening or Wednesday morning depending on time zone - WebEx info here: https://mailarchive.ietf.org/arch/msg/detnet/5Ckc25NPr3C-wsQ9Zv4RzsADM1I/ [mailarchive.ietf.org]<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/detnet/5Ckc25NPr3C-wsQ9Zv4RzsADM1I/__;!!LpKI!lBepWUdXMG3R80CH1JYnT2jDhXknUDZyZ_KtO0ByFw8eZOWuJLksyCBCFPxGHkzTPCwyDTD579RAm2oNvw$>), I thought I'd try to describe some expectations (and non-expectations).
> 
> These open working meetings will be less structured than DetNet meetings during IETF week or the interim meeting (no fixed time slots, discussion will not be entirely organized/oriented around slide decks).  The initial open working meeting focus will be queuing and packet scheduling within individual DetNet nodes, where we're aware of the following four drafts that propose node queuing or scheduling mechanisms:
> 
> draft-eckert-detnet-tcqf-02 Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF)
> 
> draft-joung-detnet-asynch-detnet-framework-02 Asynchronous Deterministic Networking Framework for Large-Scale Networks
> 
> draft-peng-detnet-deadline-based-forwarding-05 Deadline Based Deterministic Forwarding
> 
> draft-peng-detnet-packet-timeslot-mechanism-01 Generic Packet Timeslot Scheduling Mechanism
> 
> If any drafts are missing from the above list (or any of the above drafts should be removed), please send a note to the list or directly to me with the WG chairs (detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>) cc:'d.
> 
> The open working meetings will initially address three items:
> 
> 
>   1.  Refining requirements: The scaling requirements draft (Requirements for Scaling Deterministic Networks) ought to be stable enough by the end of April that work invested in determining whether and to what extent the proposed mechanisms do/don't meet its requirements will not be wasted.
> 
> 
> 
>   1.  Longer presentations of the proposed mechanisms.  Each open working meeting ought to be able to accommodate one or two 40-45 minute slots for longer, more detailed presentations than have been possible during the limited time available in WG meetings - that would be 30-35 minutes of presentation, 10-15 minutes of questions.  With apologies for the short notice, authors of proposals who would like to do this at next week's meeting should please contact me and cc: the WG chairs.
> 
> 
>   1.  Evaluation criteria.  It seems clear to me that we will need to look at evaluation criteria beyond the requirements draft - a process discussion of how to go about this in a reasonable and fair fashion seems appropriate (e.g., much as the effort that has gone into draft-eckert-detnet-criteria-assessment is worthy, the author has been open and honest about being a proponent of one of the solutions - I don't like the optics of the group for one of the proposal drafts being in charge of writing the evaluation criteria for all of the proposals).
> 
> Please keep in mind that these open working meetings cannot make decisions for the WG - any suggestions/recommendations that emerge will have to be taken to this mailing list for further discussion.
> 
> Comments, questions and alternate suggestions are welcome.
> 
> Thanks, --David
> 
> David L. Black, Sr. Distinguished Engineer, Technology & Standards
> Infrastructure Solutions Group, Dell Technologies
> mobile +1 978-394-7754 David.Black@dell.com<mailto:David.Black@dell.com>
> 

-- 
---
tte@cs.fau.de