Re: [Detnet] [Detnet ] Fwd: New draft on A Queuing Mechanism with Multiple Cyclic Buffers

"Liubingyang (Bryan)" <> Wed, 03 March 2021 10:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CA1F3A0C4E for <>; Wed, 3 Mar 2021 02:35:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FSpOI1z7RmXI for <>; Wed, 3 Mar 2021 02:35:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 958003A0C4C for <>; Wed, 3 Mar 2021 02:35:12 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4Dr8vW0fdzz67vVx; Wed, 3 Mar 2021 18:12:55 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 3 Mar 2021 11:18:36 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Wed, 3 Mar 2021 18:18:34 +0800
Received: from ([]) by ([]) with mapi id 15.01.2106.006; Wed, 3 Mar 2021 18:18:34 +0800
From: "Liubingyang (Bryan)" <>
To: Mohammadpour Ehsan <>, "" <>
CC: Dangjuanna <>
Thread-Topic: [Detnet] [Detnet ] Fwd: New draft on A Queuing Mechanism with Multiple Cyclic Buffers
Thread-Index: AdcP+tVTb2V6NjQiRXqpVQSPsMznwwABG3uAAATaJvA=
Date: Wed, 3 Mar 2021 10:18:33 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_1191c68c16ca49d8a7e1fb0de23acf52huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Detnet] [Detnet ] Fwd: New draft on A Queuing Mechanism with Multiple Cyclic Buffers
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: Wed, 03 Mar 2021 10:35:16 -0000

Hi Ehsan,

Great questions.

First, the queues of different nodes do not have to open/close at the same time.  Theoretically, time does not have to be synchronized. What is required is that the difference between the cycle starting times of neighbor nodes should be stable, i.e., the maximum time interval error (MTIE) should be bounded. According to ITU-T G.8261, the MTIE is bounded by 300 ns when a chain of up to 20 enhanced synchronous Ethernet (SyncE) clocks are traceable to an enhanced primary reference time clock (ePRTC).

The CQF as described in 802.1Q should work with different cycle times. I suspect the mechanism described in this draft should work with different cycle times, too. But I haven’t worked into the details. We can together discuss and work on it. Do you mean that a single node can run multiple cyclic buffers, and some of the buffers are with cycle values 10us, 20us, 40us … ?

Bryan (Bingyang Liu)

From: detnet [] On Behalf Of Mohammadpour Ehsan
Sent: Wednesday, March 3, 2021 4:32 PM
To: Dangjuanna <>
Cc:; Liubingyang (Bryan) <>
Subject: Re: [Detnet] [Detnet ] Fwd: New draft on A Queuing Mechanism with Multiple Cyclic Buffers

Hello Joanna,

I think this is an interesting topic to be studied. The CQF with two buffers is addressed in IEEE802.1Q (annex T); however, it is not discussing multiple-queue version that leads to increase bandwidth utilisation when the dead time is large. From my understanding, this document covers CQF with multiple queues that is very nice. Regarding that, I have two questions:

1) Is the proposed mechanism operating in non-synchronised network?
2) Does the proposed mechanism allow different cycle times throughout a network? If so, how does the buffer allocation work (I didn’t get it well from the document)?



On 3 Mar 2021, at 08:01, Dangjuanna <<>> wrote:

Hi All,

Network forwarding with bounded latency and zero congestion loss is important for various industrial applications.  The DetNet working group draft "DetNet Bounded Latency"[draft-ietf-detnet-bounded-latency] describes requirements for queuing mechanisms.  To cope with long link delay, more than two cyclic buffers can be used.  Among the referenced queuing mechanisms, Cyclic Queuing and Forwarding (CQF) requires no per-flow dynamic state at core nodes, which is scalable when the number of flows grows.  This draft<> discusses the details of the cyclic queuing mechanisms. We propose a queuing model and mechanism with multiple cyclic buffers, which can improve bandwidth utilization without sacrificing latency and jitter.

I list a few points as follows for discussion.

1.       The mechanism with multiple cyclic buffers can be used for bounded latency guarantee.

2.       In actual deployment, we need to know which nodes have this mechanism. Therefore, both the controller and YANG model need to be extended.

3.       While the latency is guaranteed, network bandwidth utilization and long-distance deployment should be the key considerations.

I hope that those above issues will arouse our attention.



-----Original Message-----
From:<> []
Sent: 2021年2月22日 20:07
To: Liubingyang (Bryan) <<>>; Dangjuanna <<>>
Subject: New Version Notification for draft-dang-queuing-with-multiple-cyclic-buffers-00.txt

A new version of I-D, draft-dang-queuing-with-multiple-cyclic-buffers-00.txt
has been successfully submitted by Joanna Dang and posted to the IETF repository.

Name:               draft-dang-queuing-with-multiple-cyclic-buffers
Revision:  00
Title:                  A Queuing Mechanism with Multiple Cyclic Buffers
Document date:       2021-02-22
Group:               Individual Submission
Pages:               6

   This document presents a queuing mechanism with multiple cyclic

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at<>g/>.

The IETF Secretariat

detnet mailing list<>