Re: [tsvwg] Welcom to discuss RE: New Version Notification for draft-dang-queuing-with-multiple-cyclic-buffers-00.txt

Toerless Eckert <> Thu, 25 February 2021 13:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82E6E3A1840 for <>; Thu, 25 Feb 2021 05:39:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xQo4nT0k28jg for <>; Thu, 25 Feb 2021 05:39:33 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C53C3A1588 for <>; Thu, 25 Feb 2021 05:39:32 -0800 (PST)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id 56C2054804B; Thu, 25 Feb 2021 14:39:27 +0100 (CET)
Received: by (Postfix, from userid 10463) id 4E584440163; Thu, 25 Feb 2021 14:39:27 +0100 (CET)
Date: Thu, 25 Feb 2021 14:39:27 +0100
From: Toerless Eckert <>
To: Dangjuanna <>
Cc: TSVWG <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [tsvwg] Welcom to discuss RE: New Version Notification for draft-dang-queuing-with-multiple-cyclic-buffers-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Feb 2021 13:39:35 -0000

Thanks, Joanna

I too would love to hear feedback from the TSVWG community.

Alas, AFAIK, the TSVWG community is very unaware of the technology and its benefits
(i don't think it was ever presented to it), and alas the draft itself does not explain
those systematic aspects (yet).  A presentation to the TSVWG community would IMHO be 
very helpfull to bring the community up to speed. 

I for once think this type of technology is a significant improvement in the
ability to predictably control latency and tighly constrain jitter and can not see how we
can make IETF protocol networks better to support critical infrastructure services
without such high-precision and predictable latency management.

Short of being given an opportunity to present to the TSVWG community during a meeting,
maybe i can repeat here my favourite story hopefully to cite some interest. Let me
choose a more fun example than something service critical, because a lot of that
critical stuff is hard to talk publically about (just check out how most of past
TSVWG work on guaranteed services was supported very much by USA public, federal and
defense users).

When digital cable set top boxes where amended with ethernet interfaces a bit over 
a decade ago  or so, to make them become IPTV STB, they somehow failed to deliver
good quality (i was testing them in the lab back then).  Turned out, their playout
buffer was just slightly larger than the frame interval (20 msec), so they where
loosing packets due to IP path jitter. Obviously, a synchronous delivery system like
digital cable did not require larger playout buffers.

IMHO this is exactly the problem that everybody who wants to expand the scope
of their synchronous applications / control-loops will run into. And there are
a huge amount of such industries that just slowly adopt ethernet/IP instead
of synchronous solutions. They may be now tempted to believe that something
like TSN-ATS will suffice (if we could just make it work over IP), but that
solution is eactly the problem: It has the worst-possible jitter of
any solution because it tries to be as much work preserving as possible to
achieve a simple calculus.

Aka: with UBS (the algorithm of TSN-ATS, which seemingly many in DetNet may think
would also get the job done if there was just a sufficient encap with IP), 
you need to build receiver device products that are certified for a particular
network 'jitter diameter':

 "This product works for networks up to xxx msec end-to-end jitter"

Of course, nobody in the industries is thinking about that until it causes them
failures, and i can already see how network operators would severely struggle 
operationalizing deployments of latency aware services in the face of this challenge.

In other words: any network trying to offer latency aware services will set itself
up for failure or horrible operational costs if it does not consider this issue and
 solutions such as this queuing mechanism to solve them.

Last time i had this discussion in DetNet which claims to be all about this
(latency control), but then i was asked by the DetNet chairs to go to TSVWG as thy felt 
that DetNet did not have to authority nor expertise to consider such novel QoS PhB,
but that this was the job of TSVWG. Well... here we are.. 


On Mon, Feb 22, 2021 at 12:49:28PM +0000, Dangjuanna wrote:
> Hi All,
> This document discusses the details of the cyclic queuing mechanisms. We propose a queuing model and mechanism with multiple cyclic buffers, which can improve bandwidth utilization.
> Welcome to discuss and review it.
> Best wishes,
> Joanna
> -----Original Message-----
> From: [] 
> Sent: 2021???2???22??? 20:07
> To: Liubingyang (Bryan) <>om>; 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
> URL:  
> Status:
> Htmlized:
> Htmlized:
> 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
> The IETF Secretariat