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

Toerless Eckert <tte@cs.fau.de> Wed, 03 March 2021 12:18 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 E75563A0EF9 for <detnet@ietfa.amsl.com>; Wed, 3 Mar 2021 04:18:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level:
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 xQePSKnaKthB for <detnet@ietfa.amsl.com>; Wed, 3 Mar 2021 04:18:16 -0800 (PST)
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 E754F3A0F02 for <detnet@ietf.org>; Wed, 3 Mar 2021 04:18:15 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 10407548053; Wed, 3 Mar 2021 13:18:05 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 09362440166; Wed, 3 Mar 2021 13:18:05 +0100 (CET)
Date: Wed, 03 Mar 2021 13:18:04 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: "Liubingyang (Bryan)" <liubingyang@huawei.com>
Cc: Mohammadpour Ehsan <ehsan.mohammadpour@epfl.ch>, "detnet@ietf.org" <detnet@ietf.org>, Dangjuanna <dangjuanna@huawei.com>
Message-ID: <20210303121801.GA55599@faui48f.informatik.uni-erlangen.de>
References: <3deb453684ed4b4997e53b76fa41e38d@huawei.com> <5C4A651B-3319-49C8-9917-8446D4AEFC00@epfl.ch> <1191c68c16ca49d8a7e1fb0de23acf52@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1191c68c16ca49d8a7e1fb0de23acf52@huawei.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/8UPl1usQhglqkwzbkL164EHFnmg>
Subject: Re: [Detnet] [Detnet ] Fwd: New draft on A Queuing Mechanism with Multiple Cyclic Buffers
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, 03 Mar 2021 12:18:19 -0000

Hi Ehsan,

To add to Bryans explanations:

The way i understand IEEE CQF, the MTIE really needs to make the clock of adjacent nodes stay
within the dead interval, so that packets received are appropriately put into the right
cycle purely ased on their arrival time. I think the dead time is <= 10% of cycle time,
 leading to often MTIE requirements in the nsec range.

In the packet header tagged queuing, my understanding is that a simple operating model exists
when the MTIE is such that a packet with a particular cycle tag does arrive within the window
in which the receiver can accept packets for that cycle instance. If you have
for example 4 cycles i think the MTIE can be > 1 cycle time, which is a factor 10 larger
than without indicating the cycle in a packet tag. If time synchronization was used to
achieve the MTIE, then it could be a factor 10 less accurate over CQF, which especially in wide
area networks could be a significant capex/opex reduction.

Just off the top of my head. There is a lot of room IMHO for optimization, for example,
if every buffer is virtual on the receive side, and can thus receive all the time,
then it should be possible to achieve this relaxed MTIE with fewer cycle tags
on the wire (and less overall latency).

There are IMHO also be good uses of the scheme without strict admission control and not
requring zero congestion loss - in the same way that i think PREOF will find deployments
without combining it with explicit admission control. In those scenarios, the requirments
for specific MTIE guarantees will also be different (IMHO). Aka: it would be great to
recognize these schemes such as CQF and his multi-buffer cyclic queuing also independently
from congestion loss as a building block in DetNet for not only bounded latency,
but tightly bounded jitter, for example in the bounded latency draft - in the same way
as PREOF is also recognized as an individual building block to provide significant reduced NCL.

Let us know what you think!

Cheers
    Toerless

On Wed, Mar 03, 2021 at 10:18:33AM +0000, Liubingyang (Bryan) wrote:
> 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 [mailto:detnet-bounces@ietf.org] On Behalf Of Mohammadpour Ehsan
> Sent: Wednesday, March 3, 2021 4:32 PM
> To: Dangjuanna <dangjuanna@huawei.com>
> Cc: detnet@ietf.org; Liubingyang (Bryan) <liubingyang@huawei.com>
> 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)?
> 
> Thanks!
> 
> 
> Best,
> Ehsan
> 
> 
> 
> On 3 Mar 2021, at 08:01, Dangjuanna <dangjuanna@huawei.com<mailto:dangjuanna@huawei.com>> 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<https://www.ietf.org/archive/id/draft-dang-queuing-with-multiple-cyclic-buffers-00.txt> 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.
> 
> 
> 
> Regards,
> 
> Joanna
> 
> -----Original Message-----
> From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org]
> Sent: 2021???2???22??? 20:07
> To: Liubingyang (Bryan) <liubingyang@huawei.com<mailto:liubingyang@huawei.com>>; Dangjuanna <dangjuanna@huawei.com<mailto:dangjuanna@huawei.com>>
> 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
> URL:            https://www.ietf.org/archive/id/draft-dang-queuing-with-multiple-cyclic-buffers-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-dang-queuing-with-multiple-cyclic-buffers/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-dang-queuing-with-multiple-cyclic-buffers
> Htmlized:       https://tools.ietf.org/html/draft-dang-queuing-with-multiple-cyclic-buffers-00
> 
> 
> Abstract:
>    This document presents a queuing mechanism with multiple cyclic
>    buffers.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________
> detnet mailing list
> detnet@ietf.org<mailto:detnet@ietf.org>
> https://www.ietf.org/mailman/listinfo/detnet
> 

> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet


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