Re: [Detnet] New Version Notification for draft-liu-detnet-large-scale-requirements-03.txt

Peng Liu <liupengyjy@chinamobile.com> Tue, 11 October 2022 13:05 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 C3636C1522BA; Tue, 11 Oct 2022 06:05:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.832
X-Spam-Level:
X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, OBFU_TEXT_ATTACH=1.042, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_KAM_HTML_FONT_INVALID=0.01, T_OBFU_HTML_ATTACH=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=no 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 0WHm1zyUAvgN; Tue, 11 Oct 2022 06:05:46 -0700 (PDT)
Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id EE49CC159A25; Tue, 11 Oct 2022 06:05:25 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[172.16.121.3]) by rmmx-syy-dmz-app12-12012 (RichMail) with SMTP id 2eec63456a11e23-c6f58; Tue, 11 Oct 2022 21:05:24 +0800 (CST)
X-RM-TRANSID: 2eec63456a11e23-c6f58
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from CMCC-LP (unknown[123.120.31.83]) by rmsmtp-syy-appsvr02-12002 (RichMail) with SMTP id 2ee263456a125b6-7b545; Tue, 11 Oct 2022 21:05:24 +0800 (CST)
X-RM-TRANSID: 2ee263456a125b6-7b545
Date: Tue, 11 Oct 2022 21:11:01 +0800
From: Peng Liu <liupengyjy@chinamobile.com>
To: lberger <lberger@labn.net>
Cc: detnet <detnet@ietf.org>, draft-liu-detnet-large-scale-requirements <draft-liu-detnet-large-scale-requirements@ietf.org>
References: <20220817165050546620113@chinamobile.com>, <6dcceab2-b32e-9fd5-3494-d6d5229b44d9@labn.net>, <2022092716350706580495@chinamobile.com>, <7ca3f9ce-9627-35d1-a26d-2d9612688c6f@labn.net>, <20221004183151258162248@chinamobile.com>, <30d25532-1709-1ad7-4796-c92f13cfc75d@labn.net>
X-Priority: 3
X-GUID: 91AAB72C-3185-4CC5-93DB-868ADF5C8860
X-Has-Attach: yes
X-Mailer: Foxmail 7.2.21.453[cn]
Mime-Version: 1.0
Message-ID: <20221011211100820335152@chinamobile.com>
Content-Type: multipart/mixed; boundary="----=_001_NextPart418541645114_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/HFGpyVNlMbrMzzDWydVpr6Rq_qw>
Subject: Re: [Detnet] New Version Notification for draft-liu-detnet-large-scale-requirements-03.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: Tue, 11 Oct 2022 13:05:50 -0000

Hi Lou,
 
Thanks for your comments! Please find the reply with 'PL'. I also merge some comments from Toerless, hope that could work:
 
- I remain a bit uncomfortable the use of relative measures as a means to define "large-scale" - e.g, " The link delay between network nodes is larger..." - I think this is largely answered by section where specific technical requirements are defined.  I think it would be best if the description in the introduction (more) closely aligned with the requirement areas/topics called out in that section (4).
[PL] Yes. We will add a paragraph in the intro and modify subsections in section 4 to closely aligned with it by providing expanding text on the requirement areas/topics for each key attributes in intro. I attached the key changes at the bottom of the email. Please check if it fits what you suggested.
 
- A more minor comment - While the reference to "Local area network" may be applicable to TSN, I think the current text mistakenly reads as if current DetNet only to "Local area network".
[PL] We will correct it. 
 
- You include high speed links as part of what what defines a "Large-scale" DetNet.  My understanding is that any rate link is supported via current DetNet definitions. I do agree that number of flows can be used to identify a "large-scale" DetNet (independent of link speeds).
 
[PL] Yes. We agree that the current DetNet definitions support any rate link.  Some more considerations based on RFC 8938, it says " The forwarding sub-layer provides the QoS-related functions needed by the DetNet flow. It may do this directly through the use of queuing techniques and traffic engineering methods, or it may do this through the assistance of its underlying connectivity. For example, it may call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN[IEEE802.1TSNTG]. The forwarding sub-layer uses buffer resources for packet queuing, as well as reservation and allocation of bandwidth capacity resources."
 
It seems to use the TSN as an example to support the forwarding sub-layer service. The high speed links often used in the backbone network, and will bring more challenges to the cycle or buffer set. For instance, in draft-yizhou-detnet-ipv6-options-for-cqf-variant, the dead time of CQF is a time interval at the end of a cycle to ensure the last byte of the cycle to be received earlier than the end of the same cycle by the next downstream node, will have bigger influence of bandwidth utilization when the higher speed makes the cycle interval lower. Besides, the number of aggregated flow, and the difference of in and out port speed will also be influenced by the higher link speed. Now we haven't seen the standard solutions or mechanisms could coordinate with the various link speeds, so we are thinking to propose this requirement to lead out some work in this direction. 
 
- Similarly, I don't understand how asymmetric links are new to the large-scale problem, e.g., consider the RAW use case.
[PL] This is mainly to say the asymmetric delay caused by asymmetric links. Current time synchronization usually assumes one-way delay is half of the two-way delays.  Asymmetric delays may not be a big deal when the network is small or link is short. When moving to wider area with longer link, it will introduce challenges for some existing forwarding sub-layer, especially those time synchronization based. For example, the time controlled gate at ports may require more relaxed configuration or some new way to derive the accurate one-way delay or people may prefer fully non synchronized mechanisms.
 
----------------------------------------------------------------------------------------------
-Based on your comments, we wonder if the modification as follows is acceptable:
 
In this document we define a large-scale DetNet network as a network that requires DetNet solutions for typically one or more of the following key attributes:
 
(1)There is relaxed clock synchronization or no clock synchronization in different domains.
(2)The end to end path is a combination of short and long distance hops. 
(3)There are various transmission rate supported at the different ports and on different network node.
(4)There are a large number of flows which may has different level demands of DetNet service accrossing multi-domains.
(5)The topology change and failures of link might be common.
(6)The mechanisms used to ensure bounded latency (e.g. queuing mechanism) may be multiple or have different configuration/parameter in multi-domains.
 
-It could be matched well with the technical requirement Section, while we merged the Section 3 of old version into the new section 3.4:
 
3.1.  Tolerate Time Asynchrony  
3.2.  Support Large Single-hop Propagation Latency 
3.3.  Accommodate the Higher Link Speed Various Transmission Rate
3.4.  Be Scalable to Numerous Network Devices and the large number of flows
3.5.  Tolerate Failures of Links or Nodes and Topology Changes     
3.6.  Support Configuration of Multiple Queuing Mechanisms(Merge Section 4.7)
4.7.  Support Queuing Mechanisms Switchover Crossing Multi-domains
 
It didn't mention the asymmetric links in the attributes, which could be described in the text. For the Section 3.3 Higher Link Speed, if you still have more comments, we can further refine it.
 
The updated version could be found in attachment to help a overall view. 

Regards,
Peng


liupengyjy@chinamobile.com
 
From: Lou Berger
Date: 2022-10-07 21:24
To: Peng Liu
CC: detnet; draft-liu-detnet-large-scale-requirements
Subject: Re: [Detnet] New Version Notification for draft-liu-detnet-large-scale-requirements-03.txt
Hi Peng,

Thank you for the update.  I think the clarifications are quite helpful.  I still have a few comments:

- I remain a bit uncomfortable the use of relative measures as a means to define "large-scale" - e.g, " The link delay between network nodes is larger..." - I think this is largely answered by section where specific technical requirements are defined.  I think it would be best if the description in the introduction (more) closely aligned with the requirement areas/topics called out in that section (4).

- A more minor comment - While the reference to "Local area network" may be applicable to TSN, I think the current text mistakenly reads as if current DetNet only to "Local area network".

- You include high speed links as part of what what defines a "Large-scale" DetNet.  My understanding is that any rate link is supported via current DetNet definitions.  I do agree that number of flows can be used to identify a "large-scale" DetNet (independent of link speeds).

- Similarly, I don't understand how asymmetric links are new to the large-scale problem, e.g., consider the RAW use case.

I suspect there will be more refinement in the document besides the points above once this document is accepted as a WG document,but do think the above should be clarified before WG adoption so that the scope of the work is clear to all.

Thank you,
Lou

On 10/4/2022 6:31 AM, Peng Liu wrote:
Hi Lou,

Thanks. According to your suggestion, we modified the text as follows, which have the definition and the key attributes of large-scale deterministic network, and each requirements proposed in Section 4 could map to the attributes directly or indirectly. We hope this could work. The new version of the document and the diff could be found in attachment.

In this document we define a large-scale DetNet network as a network that has longer transmission distance, more network devices and more kinds of traffic flows than a local area network, it includes one or more of the following key attributes:

   * There are many types of network nodes which may introduce disparate local time variation and buffering capabilities.
   * The link delay between network nodes is larger, and the end to end path is a combination of short and long distance hops.
   * There are various transmission rate supported at the different ports and on different network node, varying from tens of Mbps to tens of Gbps or higher.
   * The path between two neighbor nodes can be asymmetric in terms of the link delay.
   * There are a large number of flows which may travel across multiple Detnet domains.
   * The mechanisms used to ensure bounded latency (e.g. queuing mechanism) may be different or have different configuration/parameter in each domain.

Such domains are normally within a single administrative control network or multiple cooperating administrative networks within a closed group of administrative control [RFC8655].  However they may belong to different AS domains and be controlled by multiple peering or cascaded controllers, and at the same time they may not have the same time clock source. Maintaining per flow status becomes impractical in the large scale network.  Aggregation and disaggregation of flows take place at the boundaries of Detnet omains as well as within a Detnet domain with various rules. The flow identification and packet treatment should take care of one or combined changes introduced by the large-scale network.

Based on the defination and characteristics above, this document describes requirements for large-scale deterministic networks which demands the enhancement based on the existing bounded latency mechanisms and the corresponding data plane to ensure the detnet service for single administrative network or multiple (cooperating) administrative networks that defined in the detnet charter. The deterministic network for open internet is not within current scope.

Regards,
Peng


liupengyjy@chinamobile.com
 
From: Lou Berger
Date: 2022-09-30 20:32
To: Peng Liu
CC: detnet; draft-liu-detnet-large-scale-requirements
Subject: Re: [Detnet] New Version Notification for draft-liu-detnet-large-scale-requirements-03.txt
Hi Peng,
Thank you for the response. I think your text below will help, but still does not provide a precise definition of the term 'large-scale'. I think such a precise definition is required to ensure we all understand the problem being described.

I suggest having text that starts with something along the lines of "In this document we define a large-scale DetNet network as a network that includes one or more of the following...." and then expanding a bit on each of the identified key attributes.

Thank you!
Lou

On 9/27/2022 4:35 AM, Peng Liu wrote:
Hi Lou,

Thanks for your comments. We think the large-scale deterministic network aims at the wide area network, which may also has more network devices, detnet flows and cross multi domains. Those characteristics bring more challenges to ensure the detnet service.

As you said, the current version is not clear about what large-scale is, and it is inaccurate to say like 'detnet is limited to a single network domain'. So we propose the modification at the last paragraphs in the Introduction Section:

A large-scale network usually has a longer transmission distance, more network devices and more kinds of traffic flows than a Local area network. It also has the characteristics including:
The link delay between network nodes is larger. The end to end path is a combination of short and long distance hops. The path between two neighbor nodes can be asymmetric in terms of the link delay. There are many types of network nodes which may introduce disparate local time variation and buffering capabilities. At the same time, there are various transmission rate supported at the different ports and on different network node, varying from tens of Mbps to tens of Gbps or higher. A large number of flows can travel across multiple Detnet domains. 
 
Such domains are normally within a single administrative control network or multiple cooperating administrative networks within a closed group of administrative control [RFC8655]. However they may belong to different AS domains and be controlled by multiple peering or cascaded controllers, and at the same time they may not have the same time clock source. Maintaining per flow status becomes impractical in the large scale network. Aggregation and disaggregation of flows take place at the boundaries of Detnet domains as well as within a Detnet domain with various rules. The flow identification and packet treatment should take care of one or combined changes introduced by the large-scale network.  

This document describes requirements for large-scale deterministic networks which demands the enhancement based on the existing bounded latency mechanisms and the corresponding data plane to ensure the detnet service for single administrative network or multiple (cooperating) administrative networks that defined in the detnet charter. The deterministic network for open internet is not within current scope.

Moreover, we will remove/refine the uncorrect description related to the multi domains in the whole text. 

Hope that could address the issues about the 'large-scale' and 'multi domain'. 

Thanks again~
Peng&co authors


liupengyjy@chinamobile.com
 
From: Lou Berger
Date: 2022-09-24 00:52
To: Peng Liu; draft-liu-detnet-large-scale-requirements
CC: DetNet WG
Subject: Re: [Detnet] New Version Notification for draft-liu-detnet-large-scale-requirements-03.txt
Authors,

Thank you for this update. I have a few comments on this draft:

- The first question I have is what is the documents definition of "large-scale deterministic network"?

In the abstract you seems to imply that "large-scale" translates to "wide area":
   ... this document
   describes the technical and operational requirements when the
   different deterministic levels of applications co-exist and are
   transported over a wide area.  

But the intro, you seem to state that "large-scale" translates to "multiple domains":

  ... The current DetNet is limited to a
   single administrative domain network, and there are technical
   elements necessary for application to a large-scale network spanning
   multiple domains.

   This document describes requirements for large-scale deterministic
   networks where different deterministic levels of applications co-
   exist and large-scale deterministic networking across multiple
   administrative domains is possible. 

Can you clarify as well as ensure you are consistent within the document?

FWIW, based on the later sections of the document, I suspect large-scale is used in the document to cover number of flows supported on a device and/or network, as well as longer latency of a link and/or across the detnet domain. No matter what, the document really needs to be explicit.

- The following implies that detnet works only within a single network domain.  I think it would be good to clarify how you define "single *network* domain" in the context of this document.

   DetNet, of which architecture is defined in RFC 8655 [RFC8655],
   provides a capability to carry specified unicast or multicast data
   flows for real-time applications with extremely low data loss rates
   and bounded latency within a network domain.  

Note that the charter says multiple (cooperating) networks that have different administrative control was part of the scope of initial detnet definition, and RFC  8655  defines a "DetNet domain" that is independent from areas/groups/domains of administrative control.
 
- I think the following should be aligned with however you address the previous comment:
   .. As documented in RFC 8578 [RFC8578],
   the scope of networks addressed by the current DetNet is limited to
   networks that can be centrally controlled, i.e., an "enterprise" (aka
   "corporate") network, excluding "the open Internet," explicitly.

RFC 8578 defines *example* use cases.  The appropriate reference for current DetNet *solution* scope is RFC8655 or the other solution oriented documents.  DetNet solutions are not currently limited to central control, enterprise, or corporate networks.  I do agree that the open internet is not within current scope.

   ..The current DetNet is limited to a
   single administrative domain network, and there are technical
   elements necessary for application to a large-scale network spanning
   multiple domains.

As previously noted, the current definition of DetNet is limited to networks that are under a single administrative control or within a closed group of administrative control.

I think clarifying these points would be very helpful (and are necessary) to evaluate the remainder of the document.


Thank you,
Lou (as contributor)

On 8/17/2022 4:50 AM, Peng Liu wrote:
Dear All,

We have posted the new version of draft-liu-detnet-large-scale-requirements-03 based on the discussions and suggestions, and we would like to thanks Bala'zs, Tianran and Fan for their comments. Here are the the major changes:
 
1. Add some descriptions of the requirements and clarifications not to specify solutions in Section 4.
2. Change the name of Section 5.2 as "Support Information used by Functions ensuring Deterministic Latency".
3. Add some clarifications text in Section 5.1 and Section 5.2.
4. Add Shiyin Zhu as the co author and Lei Zhou as the contributor.
5. Correct some formatting and spelling errors.
 
Most of the solution draft presented in IETF 114 reference this document as the base requirement draft. We tried to put the common requirements together and made some updates here. There were around 20 people showing they had read the document during 114 session polling. We think it is a reasonable number to use this draft as the starting point for the milestone of Enhanced DetNet Data Plane Requirements document.
So we encourage the group to review the document. We plan to ask for a call for adoption maybe next month upon chairs’ agreement.

Regards,
Peng&co authors


liupengyjy@chinamobile.com
 
From: internet-drafts
Date: 2022-08-17 15:51
To: Jeong-dong Ryoo; Peng Liu; Quan Xiong; Shiyin Zhu; Toerless Eckert; Yizhou Li; zhushiyin
Subject: New Version Notification for draft-liu-detnet-large-scale-requirements-03.txt
 
A new version of I-D, draft-liu-detnet-large-scale-requirements-03.txt
has been successfully submitted by Peng Liu and posted to the
IETF repository.
 
Name: draft-liu-detnet-large-scale-requirements
Revision: 03
Title: Requirements for Large-Scale Deterministic Networks
Document date: 2022-08-17
Group: Individual Submission
Pages: 18
URL:            https://www.ietf.org/archive/id/draft-liu-detnet-large-scale-requirements-03.txt
Status:         https://datatracker.ietf.org/doc/draft-liu-detnet-large-scale-requirements/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-liu-detnet-large-scale-requirements
Diff:           https://www.ietf.org/rfcdiff?url2=draft-liu-detnet-large-scale-requirements-03
 
Abstract:
   Aiming at the large-scale deterministic network, this document
   describes the technical and operational requirements when the
   different deterministic levels of applications co-exist and are
   transported over a wide area.  This document also describes the
   corresponding Deterministic Networking (DetNet) data plane
   enhancement requirements.
 
                                                                                  
 
 
The IETF Secretariat
 
 

_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet