IETF Logo Mail Archive

Re: [Detnet] questions about draft-eckert-detnet-mpls-tc-tcqf

Norman Finn Consulting <nfinn@nfinnconsulting.com> Wed, 17 November 2021 20:37 UTC

Return-Path: <nfinn@nfinnconsulting.com>
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 D9F413A0485; Wed, 17 Nov 2021 12:37:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nfinnconsulting.com
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 Xb5ZzA_1fgFl; Wed, 17 Nov 2021 12:37:30 -0800 (PST)
Received: from us2-ob1-4.mailhostbox.com (us2-ob1-4.mailhostbox.com [162.210.70.57]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2051A3A0483; Wed, 17 Nov 2021 12:37:29 -0800 (PST)
Received: from norms-mbp.attlocal.net (99-117-116-219.lightspeed.sndgca.sbcglobal.net [99.117.116.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nfinn@nfinnconsulting.com) by us2.outbound.mailhostbox.com (Postfix) with ESMTPSA id 85B882EB5FF; Wed, 17 Nov 2021 20:37:27 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nfinnconsulting.com; s=20161121; t=1637181447; bh=2JCcx8RFoe+EN1C1H69JUFT0ZN2gS9x9ojF3WT3Lla4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ecnhEzXC4bk7HbecUAG/4OhBo/VtbYQFNdJqSzi29fU5THm3SIniF9JS/8CdXKebL rDiVKHSouaVMpPyQT8/B2BY2EzbfxaAqAEe8Wz+XGsX/I2C27TK51xFHXAcd14Ng3a G3ynhqYL8/hmuk7seXkGh5+2UakvakJ1uZymQTZI=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Norman Finn Consulting <nfinn@nfinnconsulting.com>
In-Reply-To: <F3BDE1D8-DCA8-4926-A045-E277E75BC78F@nfinnconsulting.com>
Date: Wed, 17 Nov 2021 12:37:26 -0800
Cc: draft-eckert-detnet-mpls-tc-tcqf@ietf.org, detnet@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0733C6A7-8719-4750-8406-6A38F72B7081@nfinnconsulting.com>
References: <202111111500108747580@zte.com.cn> <F3BDE1D8-DCA8-4926-A045-E277E75BC78F@nfinnconsulting.com>
To: peng.shaofu@zte.com.cn
X-Mailer: Apple Mail (2.3608.120.23.2.7)
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.4 cv=Ma8PB7zf c=1 sm=1 tr=0 ts=61956807 a=aTmnyjqu01k1Du4yLKcxzA==:117 a=aTmnyjqu01k1Du4yLKcxzA==:17 a=IkcTkHD0fZMA:10 a=5KLPUuaC_9wA:10 a=XLpdG_O0AAAA:8 a=1RTuLK3dAAAA:8 a=48vgC7mUAAAA:8 a=_jOOV1ILpjOdZhfw8GYA:9 a=QEXdDO2ut3YA:10 a=WOE-n-Zn2_2uhfR19-Pu:22 a=kRpfLKi8w9umh8uBmg1i:22 a=w1C3t2QeGrPiZgrLijVG:22
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/oA60w96a-nnAJ7g844MxDRPA5mo>
Subject: Re: [Detnet] questions about  draft-eckert-detnet-mpls-tc-tcqf
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, 17 Nov 2021 20:37:35 -0000

A follow-on.

CQF is under consideration for improvement for use in TSN, where network sizes are relatively small.  My paper, referenced by Janos, does not address the issue of bundling many flows into a single flow, then merging or splitting them arbitrarily.  Without bundling, TSN CQF has scaling issues; a large number of flows requires large buffers, which increase the per-hop delays.  But, bundling is not a trivial operation.  Bundling may require buffers and state machines, itself, and may therefore reduce the no-touch advantage of CQF.  My next step for the CQF proposals in TSN will be to address this issue.  I imagine that Janos will keep you informed if progress is made.

-- Norm

> On Nov 15, 2021, at 22:56, Norman Finn <nfinn@NFINNCONSULTING.COM> wrote:
> 
> You’ve got it.  Admission control is the key. Either through a reservation protocol or a central supervisor, you have to ensure that no output interface is given more load than can be handled in a single transmission period. No sender can proceed without permission.
> 
> Reservation-before-transmission is required by all TSN techniques. You can't guarantee zero congestion loss to an arbitrarily large load. The nice thing about CQF is that, with centralized control, you don't have to touch any intermediate nodes to admit or delete a flow; only contract enforcement at the ingress node has to be configured.
> 
> — Norm
> 
>> On Nov 10, 2021, at 23:00, peng.shaofu@zte.com.cn wrote:
>> 
>> Hi authors,
>> 
>> Thanks for the effort to introduce TSN CQF to IP network, especially, a large scale WAN.
>> 
>> Can you help me to understand how does T-CQF solve the congestion ?  For example, an intermediate node with multiple incoming ports may receive T-CQF packets from many sources, and  these packets are put into the same cycle-id related queue. Can they be guaranteed to be sent together in the next cycle?  Appreciate for additional description of that in the document.
>> 
>> I have seen examples of single T-CQF flow competed with best-effor backgroup flows, that is OK. However, the competetion between multiple T-CQF flows may be more interesting.
>> One may say that there is a central controller to plan and arrange T-CQF flows, and never permit more T-CQF flows match the same local cycle-id at the intermediate node then to avoid congestion. I think that may be possible for a small network, but may be challange for large scale WAN.
>> 
>> Regards,
>> PSF
>> 
>> _______________________________________________
>> detnet mailing list
>> detnet@ietf.org
>> https://www.ietf.org/mailman/listinfo/detnet

v2.20.3 | Report a Bug | By Email