Re: [Detnet] Materials for April 26 open meeting

"Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com> Thu, 11 May 2023 09:47 UTC

Return-Path: <gengxuesong@huawei.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 900C6C151553 for <detnet@ietfa.amsl.com>; Thu, 11 May 2023 02:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.096
X-Spam-Level:
X-Spam-Status: No, score=-4.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6cKx1IZnDvH for <detnet@ietfa.amsl.com>; Thu, 11 May 2023 02:47:10 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36654C15153D for <detnet@ietf.org>; Thu, 11 May 2023 02:47:10 -0700 (PDT)
Received: from lhrpeml100003.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4QH6V64dM7z6D8qB for <detnet@ietf.org>; Thu, 11 May 2023 17:46:22 +0800 (CST)
Received: from canpemm100009.china.huawei.com (7.192.105.213) by lhrpeml100003.china.huawei.com (7.191.160.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Thu, 11 May 2023 10:47:07 +0100
Received: from canpemm500010.china.huawei.com (7.192.105.118) by canpemm100009.china.huawei.com (7.192.105.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Thu, 11 May 2023 17:47:05 +0800
Received: from canpemm500010.china.huawei.com ([7.192.105.118]) by canpemm500010.china.huawei.com ([7.192.105.118]) with mapi id 15.01.2507.023; Thu, 11 May 2023 17:47:05 +0800
From: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
To: "peng.shaofu@zte.com.cn" <peng.shaofu@zte.com.cn>
CC: "David.Black@dell.com" <David.Black@dell.com>, "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: [Detnet] Materials for April 26 open meeting
Thread-Index: Adl9IJhfBLqRPuSPS4aWgeNySIopDQCyBtdgAAC7IzAAJtmIIAAyCHFQAFbN8oAAUGc0wA==
Date: Thu, 11 May 2023 09:47:04 +0000
Message-ID: <606f13030cfe43a8bb23de1bfe2a0738@huawei.com>
References: MN2PR19MB4045ED569844FAAEEFA3BFD6836F9@MN2PR19MB4045.namprd19.prod.outlook.com, 10a822698a5e451abff7da395af17929@huawei.com, 1564e2d90d4c4261b5bf66208d349bce@huawei.com, MN2PR19MB4045FE6AF63D96A6C5D3C8D883709@MN2PR19MB4045.namprd19.prod.outlook.com, a92643fe30544836b8dd0f442d019e67@huawei.com <202305101113457723208@zte.com.cn>
In-Reply-To: <202305101113457723208@zte.com.cn>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.41.43]
Content-Type: multipart/alternative; boundary="_000_606f13030cfe43a8bb23de1bfe2a0738huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/KYSNkn637R5a64HPamehebC0cSg>
Subject: Re: [Detnet] Materials for April 26 open meeting
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 11 May 2023 09:47:14 -0000

Hi Shaofu,

Thanks for your question and please find some response inline.

Best
Xuesong

From: peng.shaofu@zte.com.cn [mailto:peng.shaofu@zte.com.cn]
Sent: Wednesday, May 10, 2023 11:14 AM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
Cc: David.Black@dell.com; Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>; detnet@ietf.org
Subject: Re: [Detnet] Materials for April 26 open meeting




Hi Xuesong,



Thanks for your presentation of CSQF, a good work to enhance the TSN CQF.

My questions is:

How to distinguish if there is an actually true conflict or false conflict between multiple flows arrived on a transit node  ?

[Xuesong] If I understand your question right, “true conflict” means that the packets from 2 separate flows will be in the same time slot in the same node with the same cycle number and the “false conflict” means that the  from 2 separate flows will be in different time slot in the same node with the same cycle number because the cycle number is used recursively (For example there are 3 queues in each node and there will be 3 cycle number)

    For example, flow-1 originated on source-1 whith some TSpec, packets of low-1 will arrive at the transit node P, and consume the cycle-id 2, as you said, the controller will allocate resource from cycle-id 2 for the flow-1. Suppose that the burst interval of flow-1 is one hour, that means source-1 will send packets of flow-1 again 1 hour later and the packets will arrive the node P and consume the cycle-id 2 again. Here, we suppose that there are 3-buffer (each for cycle-id 0, 1, 2 respectively) for the underlay multi-CQF mechanism, and ecah cycle is 10 us.

Consider there is another flow-2 originated on source-2 with the same TSpec, packets of low-2 will also arrive at the transit node P, but just later than flow-1 1 minutes, and also consume the cycle-id 2.  So, it can be see that these two flows did not actually collide, but they both wish to allocate the resource of cycle-id 2. If flow-1 exhaust the total resources of cycle-id 2, can flow-2 still allocate resources from cycle-id 2 ? I hope the answer is YES, so that will support more service scale, but the complexity is that controll should maintain the release time of each flow on the network entry, and know what time the packet arrived at each transit node and check if there is true conflict between multiple arrived flows, that is, for the above example, if it is true conflict, flow-2 can not allocate cycle-id 2, otherwise it can. Right ?

[Xuesong] From the controller’s view it could distinguish the “true conflict” and “false conflict” because it is able to maintain the time slot status which decouples with the capability of the device. Although the cycle number allocated by the controller is the same for these 2 packets from 2 different flows, because the packet’s arriving time is different, it will map to the same queue with different output time.



Regards,

PSF




Original
From: Gengxuesong(GengXuesong) <gengxuesong=40huawei.com@dmarc.ietf.org<mailto:gengxuesong=40huawei.com@dmarc.ietf.org>>
To: Black, David <David.Black@dell.com<mailto:David.Black@dell.com>>;Gengxuesong (Geng Xuesong) <gengxuesong=40huawei.com@dmarc.ietf.org<mailto:gengxuesong=40huawei.com@dmarc.ietf.org>>;detnet@ietf.org <detnet@ietf.org<mailto:detnet@ietf.org>>;
Date: 2023年05月08日 09:50
Subject: Re: [Detnet] Materials for April 26 open meeting
_______________________________________________
detnet mailing list
detnet@ietf.org<mailto:detnet@ietf.org>
https://www.ietf.org/mailman/listinfo/detnet
Hi David,

Thanks for arranging the time which is perfect and I will prepare some material for discussion.

Thanks!
Xuesong

From: Black, David [mailto:David.Black@dell.com]
Sent: Sunday, May 7, 2023 10:20 AM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; Gengxuesong (Geng Xuesong) <gengxuesong=40huawei.com@dmarc.ietf.org<mailto:gengxuesong=40huawei.com@dmarc.ietf.org>>; detnet@ietf.org<mailto:detnet@ietf.org>
Cc: Black, David <David.Black@dell.com<mailto:David.Black@dell.com>>
Subject: RE: Materials for April 26 open meeting

Hi Xuesong,

Excellent timing, thank you!  I’ve just put CSQF on the agenda for the May 9 open working meeting (May 10 in many time zones, including China) for the “(2) In-depth presentation” slot at the end of the meeting.

Will that work, or is it too soon?  There will be additional opportunities in the future.

As part of the presentation and discussion, please compare/contrast CSQF with TCQF (draft-eckert-detnet-tcqf-02 <https://datatracker.ietf.org/doc/draft-eckert-detnet-tcqf/>  and draft-yizhou-detnet-ipv6-options-for-cqf-variant-02<https://datatracker.ietf.org/doc/draft-yizhou-detnet-ipv6-options-for-cqf-variant/>).  E.g., do all three drafts define a common queueing/scheduling mechanism that has per-draft alternatives/differences for carrying the cycle identification between DetNet nodes, or is there something specific to SR in the CSQF queueing/scheduling mechanism that would make CSQF inapplicable outside of use by SR?

Thanks, --David

From: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>
Sent: Saturday, May 6, 2023 3:32 AM
To: Gengxuesong (Geng Xuesong); Black, David; detnet@ietf.org<mailto:detnet@ietf.org>
Cc: Black, David
Subject: RE: Materials for April 26 open meeting


[EXTERNAL EMAIL]
Some additional information about CSQF for your reference:

This mechanism has been discussed in WG since IETF 105 : https://datatracker.ietf.org/meeting/104/materials/slides-104-detnet-detnet-srv6-data-plane-encapsulation [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/104/materials/slides-104-detnet-detnet-srv6-data-plane-encapsulation__;!!LpKI!monEwC4gZ1L5JcDb5YianV7VL0k-4hoj4nL0T7u6xoy32UwDmt6oZJvRy441d1-0ZfUFEfltkHtaDrd6Hzd5IA$>
There are also very similar idea like: https://datatracker.ietf.org/doc/html/draft-stein-srtsn-00 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-stein-srtsn-00__;!!LpKI!monEwC4gZ1L5JcDb5YianV7VL0k-4hoj4nL0T7u6xoy32UwDmt6oZJvRy441d1-0ZfUFEfltkHtaDrcivJolrg$>
Related academic work, mainly on controller algorithms:  https://www.sciencedirect.com/science/article/pii/S0140366420319642 [sciencedirect.com]<https://urldefense.com/v3/__https:/www.sciencedirect.com/science/article/pii/S0140366420319642__;!!LpKI!monEwC4gZ1L5JcDb5YianV7VL0k-4hoj4nL0T7u6xoy32UwDmt6oZJvRy441d1-0ZfUFEfltkHtaDreXQVFW9w$>

Best
Xuesong
From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Saturday, May 6, 2023 3:10 PM
To: Black, David <David.Black=40dell.com@dmarc.ietf.org<mailto:David.Black=40dell.com@dmarc.ietf.org>>; detnet@ietf.org<mailto:detnet@ietf.org>
Cc: Black, David <David.Black@dell.com<mailto:David.Black@dell.com>>
Subject: Re: [Detnet] Materials for April 26 open meeting

Hi David,

Thanks a lot for uploading the material.
We have a document about CSQF mechanism for bounded latency, which also would like to be discussed in the DT (It could be found: https://datatracker.ietf.org/doc/html/draft-chen-detnet-sr-based-bounded-latency-01 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-chen-detnet-sr-based-bounded-latency-01__;!!LpKI!monEwC4gZ1L5JcDb5YianV7VL0k-4hoj4nL0T7u6xoy32UwDmt6oZJvRy441d1-0ZfUFEfltkHtaDrdURX4E-Q$>)
Do we have agenda for next week’s discussion? Shall we request a timeslot for this mechanism?

Best
Xuesong

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Black, David
Sent: Wednesday, May 3, 2023 2:09 AM
To: detnet@ietf.org<mailto:detnet@ietf.org>
Cc: Black, David <David.Black@dell.com<mailto:David.Black@dell.com>>
Subject: [Detnet] Materials for April 26 open meeting

With apologies for delays caused by my day job (… and some badly needed vacation …):

·  Slides have been uploaded and are available from here: https://datatracker.ietf.org/meeting/interim-2023-detnet-02/session/detnet [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/interim-2023-detnet-02/session/detnet__;!!LpKI!monEwC4gZ1L5JcDb5YianV7VL0k-4hoj4nL0T7u6xoy32UwDmt6oZJvRy441d1-0ZfUFEfltkHtaDrfSebKSUg$>

·  Meeting notes are in the Notepad (linked to the same page) – please check them if you haven’t already.

·  The meeting should have been recorded, but I don’t know where the recording is.

Thanks, --David

David L. Black, Sr. Distinguished Engineer, Technology & Standards
Infrastructure Solutions Group, Dell Technologies
mobile +1 978-394-7754 David.Black@dell.com<mailto:David.Black@dell.com>