Re: [Detnet] Fw: New Version Notification for draft-peng-detnet-packet-timeslot-mechanism-01.txt

peng.shaofu@zte.com.cn Thu, 06 April 2023 10:52 UTC

Return-Path: <peng.shaofu@zte.com.cn>
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 4E866C1516F8 for <detnet@ietfa.amsl.com>; Thu, 6 Apr 2023 03:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 2bBaALKCnlNE for <detnet@ietfa.amsl.com>; Thu, 6 Apr 2023 03:52:41 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC466C151557 for <detnet@ietf.org>; Thu, 6 Apr 2023 03:52:39 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4Psdcj6KVDz8R040 for <detnet@ietf.org>; Thu, 6 Apr 2023 18:52:37 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxct.zte.com.cn (FangMail) with ESMTPS id 4Psdc65JfCz5B1Gr; Thu, 6 Apr 2023 18:52:06 +0800 (CST)
Received: from njy2app04.zte.com.cn ([10.40.12.64]) by mse-fl1.zte.com.cn with SMTP id 336ApwPS066574; Thu, 6 Apr 2023 18:51:58 +0800 (+08) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njy2app03[null]) by mapi (Zmail) with MAPI id mid201; Thu, 6 Apr 2023 18:52:01 +0800 (CST)
Date: Thu, 06 Apr 2023 18:52:01 +0800
X-Zmail-TransId: 2afb642ea451ffffffff8df-2a6d5
X-Mailer: Zmail v1.0
Message-ID: <202304061852011972288@zte.com.cn>
In-Reply-To: <667aab47-2d68-ff55-b50c-b9b9b78654f1@linutronix.de>
References: 202303141140135401721@zte.com.cn, 667aab47-2d68-ff55-b50c-b9b9b78654f1@linutronix.de
Mime-Version: 1.0
From: peng.shaofu@zte.com.cn
To: florian.kauer@linutronix.de
Cc: detnet@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 336ApwPS066574
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 642EA475.000/4Psdcj6KVDz8R040
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/Mllv6Ie9TYKqXZTFM-5jThBzS_o>
Subject: Re: [Detnet] Fw: New Version Notification for draft-peng-detnet-packet-timeslot-mechanism-01.txt
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, 06 Apr 2023 10:52:43 -0000

Hi Florian,





Sorry for the late reply due to holidays, and thank you for bringing this discussion.

Please see inline.







Regards,


PSF







Original



From: FlorianKauer <florian.kauer@linutronix.de>
To: 彭少富10053815;detnet@ietf.org <detnet@ietf.org>;
Date: 2023年04月04日 18:20
Subject: Re: [Detnet] Fw: New Version Notification for draft-peng-detnet-packet-timeslot-mechanism-01.txt


Hi Shaofu,
this sounds very interesting! For many DetNet applications that I have in mind,
timeslot scheduling is the most promising approach by providing hard bounds
on the latencies.[PSF] Thank you for your interest in this proposal.




However, I have low experience with MPLS (since I mostly worked in the area
of timeslotted low-power wireless communication), so I would be very happy if  
we could discuss a few questions I have regarding your draft.
 
My main question is how you imagine the realization of the timeslots themselves,
especially in comparison to TSN CQF. 

[PSF] The timeslots realized in IP/MPLS routers and cycle duration used in TSN switches are similar in that they both divide the sending time of the outgoing port into pieces for scheduling, regardless of which type of forwarding entry (i.e., MAC entry, or IP/MPLS entry) is used to access that outgoing port and the corresponding timeslot/cycle resources. However, the difference between them is that, timeslots realized in each router are independent (e.g, no time synchronization, different timeslot length), while cycles in each switch are forcibly correlated (e.g, time synchronization, same cycle duration within specific domain).




So TSN CQF can utilize Qbv (for positioning the slots in time), Qbu (for frame
preemption) and Qci (for ingress traffic policing). 

[PSF] If I understand correctly, Qbv defines the TAS algorithm to set the deterministic queue to OPEN in the duration of "arrival/departure time" according to the arrival time and departure time of each data frame of the deterministic flow on the device, while sets other non deterministic queues to CLOSED within that duration, to ensure that the deterministic flow can avoid interference delay from non deterministic traffic flow when it actually reaches the device. The "arrival/departure time" duration is not fixed, such as 11us, 17us, etc., and is related to the burst size of deterministic flow. TAS is an ideal scheduling mechanism, but it is difficult to implement because when the scale of deterministic flows changes (resulting in changes in "arrival/departure time" duration, e.g, changed from 11us to 17us), it is necessary to dynamically update the gate-control list on each node.

Unlike TAS, CQF uses a fixed time interval to rotate the OPEN/CLOSED state of the queue, such as a fixed 10us or a fixed 20us, without considering whether there is deterministic traffic passing through. CQF reduces the complexity of setting gating states, but it still needs to consider how to solve the collision problem of multiple deterministic flows arriving simultaneously.




Do you plan to reuse some of the

functionality on the higher layer (e.g. applying MPLS over TSN and then allow the  
DetNet control plane to configure Qbv and schedule traffic in time slots provided
by Qbv according to the methods described in your draft) or would you prefer to  
completely skip the use of TSN on a lower layer and provide everything separately?[PSF] No, this proposal will not adopt a Qbv like method to dynamically set the status of the queue by the controller, but rather adopt a fixed time interval to rotate like CQF. In terms of queueing mechanism, it is universal for routers and switches (as mentioned above, the difference is accessing the corresponding outgoing ports and queue resources according to different types of FIB entries). Therefore, overall, this proposal is not MPLS over TSN (in which case the entire TSN domain is treated as a single hop of MPLS domain). Instead, it provides an enhanced (compared to TSN) queueing mechanism on routers to be suitable to IP/MPLS networks (for more backgrounds please refer to https://datatracker.ietf.org/doc/draft-ietf-detnet-scaling-requirements/), and then combines the existing resource reservation habits of IETF to complete the reservation of timeslot resources (which is very important, we believe that all queueing mechanism should have corresponding resource reservation methods). In brief, we did not completely ignore TSN, but the existing queueing mechanism or resource reservation mechanism of TSN cannot be directly reused in IP/MPLS.




Greetings,
Florian
 
On 14.03.23 04:40, peng.shaofu@zte.com.cn wrote:
>  
> Hi WG,
>  
>  
> The packet timeslot scheduling mechanism is inspired by TSN CQF and applied in large-scale networks. 
>  
> Compared with CQF, it has the follow enhancements (or tagets that try to have):
>  
> 1) Introduce timeslot resource in IP/MPLS network.
>  
> 2) Create flexible timeslot mapping based on timeslot resource reservation.
>  
> 3) Avoid overprovision and support more services.
>  
> 4) Avoid conflicts through simple and easy-to-implement (non theoretical) methods.
>  
>  
> The current version is still rough. We look forward to your any suggestions, comments, and welcome cooperation. Thanks !
>  
>  
> Regards,
>  
> PSF
>  
>  
>  
> Original
> *From: *internet-drafts@ietf.org <internet-drafts@ietf.org> 
> *To: *刘爱华10024999;Dong Yang <dyang@bjtu.edu.cn>;Peng Liu <liupengyjy@chinamobile.com>;彭少富10053815;
> *Date: *2023年03月10日 20:51
> *Subject: **New Version Notification for draft-peng-detnet-packet-timeslot-mechanism-01.txt*
>  
> A new version of I-D, draft-peng-detnet-packet-timeslot-mechanism-01.txt
> has been successfully submitted by Shaofu Peng and posted to the
> IETF repository.
>  
> Name:        draft-peng-detnet-packet-timeslot-mechanism
> Revision:    01
> Title:        Generic Packet Timeslot Scheduling Mechanism
> Document date:    2023-03-10
> Group:        Individual Submission
> Pages:        17
> URL:            https://www.ietf.org/archive/id/draft-peng-detnet-packet-timeslot-mechanism-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mechanism/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-peng-detnet-packet-timeslot-mechanism
> Diff:           https://author-tools.ietf.org/iddiff?url2=draft-peng-detnet-packet-timeslot-mechanism-01
>  
> Abstract:
>    IP/MPLS networks use packet switching (with the feature store-and-
>    forward) and are based on statistical multiplexing.  S tatistical
>    multiplexing is essentially a variant of time division multiplexing,
>    which refers to the asynchronous and dynamic allocation of link
>    timeslot resources.  In this case, the service flow does not occupy a
>    fixed timeslot, and the length of the timeslot is not fixed, but
>    depends on the size of the packet.  Statistical multiplexing has
>    certain challenges and complexity in meeting deterministic QoS, and
>    its delay performance is closely related to the used queueing
>    mechanism.  This document further describes a generic time division
>    multiplexing scheme in IP/MPLS networks, which we call packet
>    timeslot scheme.  It aims to make the control plane easier to
>    calculate the delay performance and more flexible to allocate
>    deterministic resources, and make the data plane create more flexible
>    timeslot mapping.
>  
>                                                                                   
>  
>  
> The IETF Secretariat
>  
>  
>  
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet