Re: [Detnet] Moving forward on queuing mechanism

Dangjuanna <> Thu, 08 July 2021 02:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB6883A00AE for <>; Wed, 7 Jul 2021 19:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pMsRMhom6mGf for <>; Wed, 7 Jul 2021 19:10:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE64C3A0063 for <>; Wed, 7 Jul 2021 19:10:57 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4GKzyF4Kgcz6M4Yc for <>; Thu, 8 Jul 2021 10:00:05 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 8 Jul 2021 04:10:53 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 8 Jul 2021 10:10:51 +0800
Received: from ([]) by ([]) with mapi id 15.01.2176.012; Thu, 8 Jul 2021 10:10:51 +0800
From: Dangjuanna <>
To: DetNet WG <>
Thread-Topic: [Detnet] Moving forward on queuing mechanism
Thread-Index: AQHXLT4tHJ96l/Ir/0iz+vE0K6jLeqs40zhQ
Date: Thu, 08 Jul 2021 02:10:51 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Detnet] Moving forward on queuing mechanism
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Jul 2021 02:11:04 -0000

Hi All,

After IETF 110, I have been thinking about the advancement of such related work for a long time. 

There seem to be 3 individual and active drafts related to the queuing mechanism.

There is a common understanding that the queuing mechanism can affect the certainty of the E2E delay, and the final E2E delay obtained by different queuing mechanisms is different.

I read almost all of the DetNet documents carefully and think that the whole working group is still very pragmatic and produced a lot of solid documents. Based on the current IP queuing mechanism, DetNet's work has solved most of the deterministic delay problems, such as through resource reservation, deterministic paths, and traffic engineering. And the methods to solve the problem are to try to use the extension and enhancement of the existing technical mechanism to ensure good compatibility. I think this is the charm of the IETF spirit.

I suggest that we should still think about whether the existing QoS queues of network equipment need to be improved or added with new mechanisms in the MPLS over IP or SR over IP scenarios? Can it better serve current and future highly deterministic businesses, such as delay accuracy ranging from seconds to milliseconds, even microseconds, and nanoseconds? 

I suggest that we will explore in this direction. E.g. In the MPLS over IP with CQF or SR over IP with CQF scenario,
1. What problems still exist in Detnet service deployment?
2. Is time label switching necessary between DetNet nodes with CQF to ensure cycle alignment?
3. Is the existing CQF mechanism further optimized?

Welcome to comment and discuss it.

Best wishes,

-----Original Message-----
From: detnet [] On Behalf Of Lou Berger
Sent: 2021年4月9日 20:45
To: DetNet WG <>
Subject: [Detnet] Moving forward on queuing mechanism


There has been some discussion on if/where new DetNet related queuing mechanism should be specified.  One possibility is DetNet.  For us to undertake this work, which is atypical for a routing area WG, we will need to revise our charter to reflect the intended scope of our work. We'd like to get the discussion started on this scope.

We think the next step is for those who are interested in working on new queuing mechanisms for DetNet to help by providing a concise problem statement and possible related work items. The WG can then discuss any proposals, agree on the problem to be solved and work to be done.

Thank you,

Lou and Janos

detnet mailing list