[Detnet] 回复: RE: H3C comments for (draft-liu-detnet-large-scale-requirements)

Peng Liu <liupengyjy@chinamobile.com> Fri, 05 August 2022 03:00 UTC

Return-Path: <liupengyjy@chinamobile.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 A7D7FC14F73F for <detnet@ietfa.amsl.com>; Thu, 4 Aug 2022 20:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 e-Yj1RhigkVR for <detnet@ietfa.amsl.com>; Thu, 4 Aug 2022 20:00:55 -0700 (PDT)
Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id C9AECC14F73D for <detnet@ietf.org>; Thu, 4 Aug 2022 20:00:52 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[172.16.121.11]) by rmmx-syy-dmz-app08-12008 (RichMail) with SMTP id 2ee862ec87e2c5e-1752f; Fri, 05 Aug 2022 11:00:51 +0800 (CST)
X-RM-TRANSID: 2ee862ec87e2c5e-1752f
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from CMCC-LP (unknown[223.90.36.26]) by rmsmtp-syy-appsvr06-12006 (RichMail) with SMTP id 2ee662ec87df315-6ab01; Fri, 05 Aug 2022 11:00:50 +0800 (CST)
X-RM-TRANSID: 2ee662ec87df315-6ab01
Date: Fri, 05 Aug 2022 11:05:45 +0800
From: Peng Liu <liupengyjy@chinamobile.com>
To: zhoutianran <zhoutianran@huawei.com>, "zhou.leih" <zhou.leiH@h3c.com>
Cc: detnet <detnet@ietf.org>, Zhushiyin <zhushiyin@h3c.com>, Chengzuopin <czp@h3c.com>
References: <715d99c8da9146afbaa61a300e66938a@h3c.com>, <fa4fe65d40234cad8581779abd11acea@huawei.com>, <d908999d94f041efac568b7bda1fefc3@h3c.com>, <5993ac84413a4a9cb20e719a70af9278@huawei.com>
X-Priority: 3
X-GUID: 93F85FDD-2123-4E08-AD67-FBA6D72C2222
X-Has-Attach: no
X-Mailer: Foxmail 7.2.21.453[cn]
Mime-Version: 1.0
Message-ID: <2022080511054417756424@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart342851416565_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/Uy1NXraMJUX8Tbcpa6kU7nRfIWs>
Subject: [Detnet] 回复: RE: H3C comments for (draft-liu-detnet-large-scale-requirements)
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: Fri, 05 Aug 2022 03:00:59 -0000

Hi Tianran,

Thanks for your comments. Yes, this comment also need to be simplified to avoid the detail based on CQF, which I have missed in the previous email to Lei.

CQF/CSQF is not the only way for large scale detnet, so we doesn't wan to limit it. However, it is the relatively clear way now, so some descriptions of the direction could be mentioned as the example.  We also don't limit the descriptions of others if there is and not too specific. 

It is to show the considerations of requirements to give more or less help to the solution but not to be be solution specific. Hope that could be agreed, and we also welcome more comments for rewording or others.

Regards,
Peng


liupengyjy@chinamobile.com
 
发件人: Tianran Zhou
发送时间: 2022-08-05 09:24
收件人: Zhoulei; liupengyjy@chinamobile.com
抄送: detnet; Zhushiyin; Chengzuopin
主题: RE: H3C comments for (draft-liu-detnet-large-scale-requirements)
It’s good you agree this requirement should be solution independent.
Let’s look at your first comment for example.
“In addition, in order to support large single-hop propagation latency, the queuing mechanism for LAN networks needs to be extended, such as increasing the number of queues in 802.1QCH and specifying the corresponding forwarding period in the stream. Before that, it is required to establish a cycle mapping relationship between the nodes in the path and supporting system measurement mechanism for periodic forwarding to meet the established cycle mapping relationship”
 
My read from this comment, you proposed requirements for extending CQF. This is what I mean solution specific.
However, what we should record in this draft should be from use cases and problem statement. 
I do not think CQF and CSQF (Cycle Specified Queuing and Forwarding, https://datatracker.ietf.org/doc/html/draft-chen-detnet-sr-based-bounded-latency-01 ) extension is the only way for “large scale detnet”.
I would expect some other mechanisms like L4S can also apply.
 
Best,
Tianran
 
From: Zhoulei [mailto:zhou.leiH@h3c.com] 
Sent: Thursday, August 4, 2022 8:16 PM
To: Tianran Zhou <zhoutianran@huawei.com>; liupengyjy@chinamobile.com
Cc: detnet <detnet@ietf.org>; Zhushiyin <zhushiyin@h3c.com>; Chengzuopin <czp@h3c.com>
Subject: RE: H3C comments for (draft-liu-detnet-large-scale-requirements)
 
Tianran,
 
Thanks so much for your nice comments.
 
In my view, these below suggestions from our side doesn’t mean to be specific solution.
 
We only hope to propose some directions to show the requirements could be met.
 
As I mentioned before, we would like to contribute to this draft and have been discussing  with authors of this draft to find out the right way to add/merge some of them.
 
BR
Lei
From: Tianran Zhou [mailto:zhoutianran@huawei.com] 
Sent: Thursday, August 4, 2022 3:22 PM
To: zhoulei (CTS) <zhou.leiH@h3c.com>; liupengyjy@chinamobile.com
Cc: detnet <detnet@ietf.org>; zhushiyin (CTS) <zhushiyin@h3c.com>; chengzuopin (CTS) <czp@h3c.com>
Subject: RE: H3C comments for (draft-liu-detnet-large-scale-requirements)
 
While requirement is a very useful supportive document, it should be driven by use cases and problem statement.
IMO, this document should not be solution specific, i.e., should not involve requirement only for one solution, e.g., cycle mapping/csqf/cqf.
However I see these comments do not go on the right track.
 
Best,
Tianran
 
From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Zhoulei
Sent: Monday, August 1, 2022 11:34 AM
To: liupengyjy@chinamobile.com
Cc: detnet <detnet@ietf.org>; Zhushiyin <zhushiyin@h3c.com>; Chengzuopin <czp@h3c.com>
Subject: [Detnet] H3C comments for (draft-liu-detnet-large-scale-requirements)
 
Peng,
 
Thanks so much for your good summary and discussion.
 
As I mentioned before in our previous email , we are very interested in large-scale deterministic network technology so we would like to contribute on the requirement draft on large-scale deterministic network technology.
 
All in all, on behalf of Shiyin due to his email subscribe issue, I share our summarized comments on  technical requirements for large-scale deterministic network so far and further considerations with you.
 
If necessary, we would like to send the revised document on this draft with revision mark to you.
 
Any comments are appreciated.
 
Looking forward to your response.
 
===============================================================
4.2.  Support Large Single-hop Propagation Latency
  …
  For a cyclic based method, suppose a large-scale network wants to
   keep using the simple cycle mapping relationship, however the link
   distance between two nodes is longer.  Moreover, a downstream node
   may have many upstream nodes each with different link propagation
   delays (e.g., 9 us, 10 us, 11 us, 15 us and 20 us).  In order to
   absorb the longest link propagation delay, the length of cycle must
   be set to at least 20 us.  However, since packet's arrival time
   varies within the receiving cycle, larger cycle length means larger
   delay variance.
Suggest adding:
In addition, in order to support large single-hop propagation latency, the queuing mechanism for LAN networks needs to be extended, such as increasing the number of queues in 802.1QCH and specifying the corresponding forwarding period in the stream. Before that, it is required to establish a cycle mapping relationship between the nodes in the path and supporting system measurement mechanism for periodic forwarding to meet the established cycle mapping relationship
 
 
4.4.  Be Scalable to Numerous Network Devices and Massive Traffic Flows
 
   …
   The micro-burst will happen more often due to the massive traffic
   flows, so some methods to decrease it are
   needed.[I-D.du-detnet-layer3-low-latency]introduces a reference
   method requiring a scalable buffer to adjust the speed of sending the
   packets, so as to keep a uniform transmission rate, and it also
   support the flow aggregation.
Suggest adding:
Moreover, it is required to provide unified mechanisms to resolve the micro-burst problem within the deterministic domain, especially incast  problem within the large-scale nonlinear topology domain. The micro-burst is limited to edge access and jitter is reduced by the edges shaping so as to achieve bounded latency.
 
In addition, for refined management of forward resources and providing resource assurance for deterministic forwarding when establishing/ deleting sessions, it is required to establish unified mechanisms on quantification and measurement of resources associated with interface and queue
 
 
 
 
4.5 Tolerate Failures of Links or Nodes and Topology Changes
 
   Network link failures are more common in large-scale networks.  Path
   switching or re-convergence of routing will cause high latency of
   packet loss and retransmission, which is usually in seconds before
   the network becomes stable again.  It is necessary to support certain
   mechanisms to adapt to failures of links or nodes and topology
   changes.
 
   The change of path or topology poses a higher challenge to packet
   replication and elimination.  The full disjoint paths when
   implementing the Packet Replication, Elimination, and Ordering
   Functions (PREOF) gives a better chance of survival when one of the
   nodes or links in the path fails.  At the same time, it brings the
   challenges of finding paths with similar distance and/or number of
   hops so that there is enough buffer space to absorb the latency
   difference caused by different paths when the scale is large. 
Suggest adding:
Therefore, it is required to provide system models and design methodology so that the transmission of deterministic traffic flows through different paths has similar transmission latency, so as to support flexible planning of multiple paths and provide a solid foundation for the implementation of PREOF.
 
 
4.7.  Support Queueing Mechanisms Switchover Crossing Multi-domains
 
   In large-scale deterministic networks, it may across multiple network
   domains and adopt a variety of different queueing mechanisms within
   each domain.  It is required to support the inter-domain
   deterministic mechanism at the inter-domain boundary nodes such as
   the priority redefinition and rescheduling of queues to achieve the
   end-to-end latency, bounded jitter and packet loss ratio.
 
   Moreover, changing from one queueing mechanism to another may
   generate additional end-to-end latency and/or jitter which should be
   taken into consideration.  For example, when a flow is forwarded
   across multiple network domains based on different queueing
   mechanisms, such as a time synchronous Qbv mechanism[IEEE802.1Qbv]
   and an asynchronous Qcr mechanism [IEEE802.1Qcr], a collaboration
   mechanism crossing multi-domains MUST be considered, such as
   increasing the buffer of inter-domain devices to provide enough
   adjustment space for the flow to cross different queueing mechanisms,
   so as to provide end-to-end deterministic services across multiple
   network domains.
 
Suggest adding:
At the same time, due to different scheduling granularities or phase differences between the two domains, it is required that queuing Mechanisms support flow aggregation function and queue stitching function. Furthermore, it is necessary to reduce the coupling between two domains as much as possible, as long as the network meets a certain range of requirements and end-to-end devices implement the jitter compression, end-to-end deterministic latency services can be supported.
 
In addition, it is required to provide the feasibility of end-to-end DetNet service flow scheduling in a large-scale network and solve the bandwidth, cycle, and queue mismatch problems in the cycle-based cross-domain scheduling. Queueing mechanisms vary in different network standards or drafts (e.g., TSN, DetNet). In order to guarantee the bounded delay of these queue mechanisms in different domains, additional traffic shaping solutions need to be introduced at the edge of the network and between domains. These solutions are expected to eliminate the non-deterministic factors (additional delay and jitter) caused by mismatches between different queue mechanisms such as bandwidth, queue number, cycle size, etc.
 
Suggest adding new chapter “4.8 Supports hierarchical deterministic peers”. 
Suggest adding:
4.8 Supports hierarchical deterministic peers
Large-scale deterministic network can often cross multiple domains, and one of DetNet network's goals is to provide end-to-end deterministic latency services. The technology and capabilities of each domain are different and the corresponding topology models are either segmented or nested. In this way, it is necessary to reduce the coupling between two domains as much as possible, as long as the network meets a certain range of requirements and end-to-end devices implement the jitter compression, end-to-end deterministic latency services can be supported. For example, the two-end user networks are carried by the operator's intermediate network. As long as the operator's intermediate network ensures its end-to-end latency, bounded jitter and reliability capabilities for deterministic flow,  the operator network can be made as a pipeline for the two-end user network. So gateway equipment deployed on both ends utilizes these mechanisms including flow access control, traffic shaping, traffic mark, deterministic scheduling, and jitter compression to meet the end-to-end deterministic latency service.
===================================================================
 
BR
Shiyin, Lei & Zuopin
New H3C
From: zhushiyin (CTS) 
Sent: Monday, August 1, 2022 10:49 AM
To: zhoulei (CTS) <zhou.leiH@h3c.com>
Subject: H3C comments for detnet 
 
Hi lei
  Because my email subscribe issue, please represent me to send H3C comments to the detnet group. thanks
 
 
4.2.  Support Large Single-hop Propagation Latency
  …
  For a cyclic based method, suppose a large-scale network wants to
   keep using the simple cycle mapping relationship, however the link
   distance between two nodes is longer.  Moreover, a downstream node
   may have many upstream nodes each with different link propagation
   delays (e.g., 9 us, 10 us, 11 us, 15 us and 20 us).  In order to
   absorb the longest link propagation delay, the length of cycle must
   be set to at least 20 us.  However, since packet's arrival time
   varies within the receiving cycle, larger cycle length means larger
   delay variance.
Suggest adding:
In addition, in order to support large single-hop propagation latency, the queuing mechanism for LAN networks needs to be extended, such as increasing the number of queues in 802.1QCH and specifying the corresponding forwarding period in the stream. Before that, it is required to establish a cycle mapping relationship between the nodes in the path and supporting system measurement mechanism for periodic forwarding to meet the established cycle mapping relationship
 
 
4.4.  Be Scalable to Numerous Network Devices and Massive Traffic Flows
 
   …
   The micro-burst will happen more often due to the massive traffic
   flows, so some methods to decrease it are
   needed.[I-D.du-detnet-layer3-low-latency]introduces a reference
   method requiring a scalable buffer to adjust the speed of sending the
   packets, so as to keep a uniform transmission rate, and it also
   support the flow aggregation.
Suggest adding:
Moreover, it is required to provide unified mechanisms to resolve the micro-burst problem within the deterministic domain, especially incast  problem within the large-scale nonlinear topology domain. The micro-burst is limited to edge access and jitter is reduced by the edges shaping so as to achieve bounded latency.
 
In addition, for refined management of forward resources and providing resource assurance for deterministic forwarding when establishing/ deleting sessions, it is required to establish unified mechanisms on quantification and measurement of resources associated with interface and queue
 
 
 
 
4.5 Tolerate Failures of Links or Nodes and Topology Changes
 
   Network link failures are more common in large-scale networks.  Path
   switching or re-convergence of routing will cause high latency of
   packet loss and retransmission, which is usually in seconds before
   the network becomes stable again.  It is necessary to support certain
   mechanisms to adapt to failures of links or nodes and topology
   changes.
 
   The change of path or topology poses a higher challenge to packet
   replication and elimination.  The full disjoint paths when
   implementing the Packet Replication, Elimination, and Ordering
   Functions (PREOF) gives a better chance of survival when one of the
   nodes or links in the path fails.  At the same time, it brings the
   challenges of finding paths with similar distance and/or number of
   hops so that there is enough buffer space to absorb the latency
   difference caused by different paths when the scale is large. 
Suggest adding:
Therefore, it is required to provide system models and design methodology so that the transmission of deterministic traffic flows through different paths has similar transmission latency, so as to support flexible planning of multiple paths and provide a solid foundation for the implementation of PREOF.
 
 
4.7.  Support Queueing Mechanisms Switchover Crossing Multi-domains
 
   In large-scale deterministic networks, it may across multiple network
   domains and adopt a variety of different queueing mechanisms within
   each domain.  It is required to support the inter-domain
   deterministic mechanism at the inter-domain boundary nodes such as
   the priority redefinition and rescheduling of queues to achieve the
   end-to-end latency, bounded jitter and packet loss ratio.
 
   Moreover, changing from one queueing mechanism to another may
   generate additional end-to-end latency and/or jitter which should be
   taken into consideration.  For example, when a flow is forwarded
   across multiple network domains based on different queueing
   mechanisms, such as a time synchronous Qbv mechanism[IEEE802.1Qbv]
   and an asynchronous Qcr mechanism [IEEE802.1Qcr], a collaboration
   mechanism crossing multi-domains MUST be considered, such as
   increasing the buffer of inter-domain devices to provide enough
   adjustment space for the flow to cross different queueing mechanisms,
   so as to provide end-to-end deterministic services across multiple
   network domains.
 
Suggest adding:
At the same time, due to different scheduling granularities or phase differences between the two domains, it is required that queuing Mechanisms support flow aggregation function and queue stitching function. Furthermore, it is necessary to reduce the coupling between two domains as much as possible, as long as the network meets a certain range of requirements and end-to-end devices implement the jitter compression, end-to-end deterministic latency services can be supported.
 
In addition, it is required to provide the feasibility of end-to-end DetNet service flow scheduling in a large-scale network and solve the bandwidth, cycle, and queue mismatch problems in the cycle-based cross-domain scheduling. Queueing mechanisms vary in different network standards or drafts (e.g., TSN, DetNet). In order to guarantee the bounded delay of these queue mechanisms in different domains, additional traffic shaping solutions need to be introduced at the edge of the network and between domains. These solutions are expected to eliminate the non-deterministic factors (additional delay and jitter) caused by mismatches between different queue mechanisms such as bandwidth, queue number, cycle size, etc.
 
Suggest adding new chapter “4.8 Supports hierarchical deterministic peers”. 
4.8 Supports hierarchical deterministic peers
Large-scale deterministic network can often cross multiple domains, and one of DetNet network's goals is to provide end-to-end deterministic latency services. The technology and capabilities of each domain are different and the corresponding topology models are either segmented or nested. In this way, it is necessary to reduce the coupling between two domains as much as possible, as long as the network meets a certain range of requirements and end-to-end devices implement the jitter compression, end-to-end deterministic latency services can be supported. For example, the two-end user networks are carried by the operator's intermediate network. As long as the operator's intermediate network ensures its end-to-end latency, bounded jitter and reliability capabilities for deterministic flow,  the operator network can be made as a pipeline for the two-end user network. So gateway equipment deployed on both ends utilizes these mechanisms including flow access control, traffic shaping, traffic mark, deterministic scheduling, and jitter compression to meet the end-to-end deterministic latency service.
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息,仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、
或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本
邮件!
This e-mail and its attachments contain confidential information from New H3C, which is 
intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender 
by phone or email immediately and delete it!