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

From: Dangjuanna <[email-masked]>
Date: Mon, 22 Feb 2021 12:49:28 +0000

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: [email-masked] [mailto:[email-masked]] 
Sent: 2021年2月22日 20:07
To: Liubingyang (Bryan) <[email-masked]>; Dangjuanna <[email-masked]>
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.

The IETF Secretariat

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 25 Feb 2021 14:39:27 +0100

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.. 

Cheers
    Toerless

On Mon, Feb 22, 2021 at 12:49:28PM +0000, Dangjuanna wrote:
> Sent: 2021???2???22??? 20:07

-- 
---
[email-masked]