Re: [Detnet] suggested text revision to draft-ietf-detnet-scaling-requirements

[Peng Liu <[e-mail]>]

Hi Yizhou,

Thank you. I have been working on the issues of this section to address the comments of traffic class. 
Considering your text, I propose to change Section 3.4 as follows(most of them are in the second paragraph):

OLD:

   The deterministic network may have the large number of traffic flows.
   According to [RFC2475], per-flow state identification in the network
   becomes infeasible as flow count scales up.  So, it is almost
   impossible to identify individual IP flows at the DetNet data plane
   for a massive number of flows.
   DetNet allows the leverage of the flow aggregation, while individual
   flows may join and exit the aggregated flow rapidly in the scaling
   network with large number of flows, which causes the dynamic in
   identification of the aggregated DetNet flow.  The wildcards and
   value ranges used in the identification may have to change in order
   to ensure the aggregated flows have compatible deterministic
   characteristics.  Moreover, for scaling network, proper provision at
   the control plane to accommodate such higher aggregation is required.
   The deterministic latency forwarding mechanisms MUST scale to
   networks of significant size with the massive traffic flows.

   Meanwhile, the traffic that requires deterministic networking can
   significantly fill up the capacity of a link or the portion of the
   link which is dedicated to such traffic, for example, more than 75%
   and/or up to near 100% utilization.  The over-provisioning of link
   capacity does not work in such cases.  In order to guarantee
   deterministic latency and jitter in this environment, it is required
   to provide scalable queuing solutions to improve the bandwidth
   utilization.  For instance, when the bandwithd utilization is high,
   the guard band in each cycle in [IEEE802.1Qch] is a type of over-
   provisioning and can be improved with more scalable queuing add-ons.



NEW:

   The deterministic network may have the large number of traffic flows.
   According to [RFC2475], per-flow state identification in the network
   becomes infeasible as flow count scales up.  So, it is almost
   impossible to identify individual IP flows at the DetNet data plane
   for a massive number of flows, neither for the per-node state machine
   configuration.  DetNet allows the leverage of the flow aggregation,
   while individual flows may join and exit the aggregated flow rapidly
   in the scaling network with large number of flows, which causes the
   dynamic in identification of the aggregated DetNet flow.  The
   wildcards and value ranges used in the identification may have to
   change in order to ensure the aggregated flows have compatible
   deterministic characteristics.

   For scaling network, proper provision at the control plane to
   accommodate such higher aggregation is required.  Provisioning on the
   aggregated flows normally improve the scalability at the cost of
   coarse granularity of the incoming traffic filtering and protection.
   It is desirable that adding a flow to the network does not affect the
   latency of the existing flows, or requires the complex re-
   calculation, it should require as less work as possible.  For
   instance, only the filtering and policing configuration on the
   ingress node but not the intermediate nodes.  The [IEEE802.1Qbv] uses
   traffic class to divide the flows and the number of it is usually 8,
   so that the forwarding mechanisms itself isn't complex with a large
   number of flows or higher aggregation.  However, when adding new
   flows, the Gate Control List may be changed, and the re-calculation
   is complex.  There might be the method to simplify the calculation or
   configuration, which need more work to enhance it.

   Meanwhile, the traffic that requires deterministic networking can
   significantly fill up the capacity of a link or the portion of the
   link which is dedicated to such traffic, for example, more than 75%
   and/or up to near 100% utilization.  The over-provisioning of link
   capacity does not work in such cases.  In order to guarantee
   deterministic latency and jitter in this environment, it is required
   to provide scalable queuing solutions to improve the bandwidth
   utilization.  For instance, when the bandwithd utilization is high,
   the guard band in each cycle in [IEEE802.1Qch] is a type of over-
   provisioning and can be improved with more scalable queuing add-ons.

Regards,
Peng


[e-mail]
 
From: Yizhou Li
Date: 2023-06-29 20:59
To: Peng Liu
CC: david.black; detnet; ryoo
Subject: [Detnet] suggested text revision to draft-ietf-detnet-scaling-requirements
Hi Peng,
 
Based on some discussions in the interim, I’d suggest to add the following text to section 3.4 of draft-ietf-detnet-scaling-requirements in some place you think appropriate.  
 
 
It is generally desired that no per-flow, per-node state machine configuration is required for better scalability. Provisioning a new flow should require as less work as possible, e.g. only the filtering and policing configuration on the ingress node but not the intermediate nodes. Provisioning on the aggregated flows normally improve the scalability at the cost of coarse granularity of the incoming traffic filtering and protection. In addition, it is desirable that adding a flow to the network does not affect the latency of the existing flows, or that the bounded latency requirement of the existing flows still meets without the complex re-calculation after adding a new flow.
 
 
Thanks,
Yizhou