[Detnet] Comments on draft-ietf-detnet-scaling-requirements-03.txt

[Kiran Makhijani <[e-mail]>]

Hello Authors,
My apologies for the late review. The document is in a very good shape and covers several large-scale aspects.

My only concern is in the very last comment at the bottom of this email. Would like to hear your thoughts about that. Hope you find these comments useful.

Section 1. Introduction
* There are a large number of flows which may be difficult to identify per-flow state and cause the high utilization.(Section 3.4)

>>High utilization of what? - could be bandwidth, buffers, energy, cpu, etc.

* The mechanisms used to ensure bounded latency (e.g. queuing mechanism) may be multiple or have different configuration/parameters in multi-domains.

>> The first part of the sentence is not clear whether the "mechanisms may be multiple" in a single or multi-domain. I suggest use 'different' instead of 'multiple'. Did authors mean one domain will implement one type of mechanism? Or do you consider the situation where each hop may process packet for bounded/definite latency differently?

Section 3.1.1.:
‘This can be done, for example, by putting extra buffer space at the ingress of a new domain, increasing the dead time as a guard band, or using some timing compensation mechanism.’

>> Can you provide references to dead time and timing compensation details for offline reading? I am not familiar with technical details here but identifying 'how much' 2 domains are out of sync is also a requirement. Similarly,

in section 3.1.1 should we not say
"identify (or estimate), “recover and absorb such time variance..."

Section 3.1.3

>>wondering what is a better term - Full time synchronization or end-to-end time synchronization? I am also concerned that partial synchronization could mean something else – like the traffic was only synchronized for a certain part. What if we used alternate terms like inter-domain time synchronization and intra-domain time synchronization to mean full and partial?

Section 3.2
‘It is much greater than that of a LAN, and introduces impacts on queuing mechanisms, such as cyclic or time aware scheduling method. So the queuing mechanism for LAN networks needs to be extended,’

>> I think we can rephrase the second path of the sentence. The requirement is to consider propagation delays in end-to-end computations. Why only restrict to LAN queueing. "queuing for LAN needs to be extended" does not appeal as correct to me.
                                                                                                                                                                                                                                                                                                                                                  Section 3.3                                                                                                                                                              It is practical to have a few flow- based or aggregated-flow based status in the local network.But in higher speed and larger scale networks, it is hardly feasible. If [IEEE802.1Qcr] is in use, it requires more buffers comparing to the other full/partial time synchronized mechanisms. Therefore, it requires optimizations to support higher link speeds.

>> The text started to discuss flow-state in small-scale vs large-scale networks. But then there is a discussion about buffers which is related to packet-queueing. I think these are 2 separate things. Do you want to say explicitly that managing status for large number of flows will need more resources to maintain the state on per flow basis.                                                                                                                                                                                                                                                                                                                                             Section 3.4, maybe related to 3.6
Curious question: DetNet are described to have always sufficient resources so that they will be congestion-free. Does high-utilization mean that there is a possibility of congestion?

Section 3.6                                                                                                                                                              It is required to support bursty traffic and some methods to decrease the micro-burst. So the pre-planned , ingress traffic conditioning, scalable queuing, and enhanced capacity of buffer are required to accommodate the flow fluctuation,

>> It is slightly difficult to infer whether traffic above means mixed traffic or is it always deterministic traffic? Is it expected to support both deterministic and best-effort traffic over the same network. I'd suggest a discussion to clarify this aspect should be done (one or 2 sentences in introduction).
                                                                                                                                                                                                                                                                                                                                                  Section 3.8.1                                                                                                                                                            Support Configuration of Multiple Mechanisms

>> have authors considered provisioning as a better term? Since the scale of distributing queueing mechanisms and corresponding metadata can be a daunting task in large-scale networks, more dynamic or in-band means may be needed. Moreover, it will be good to discuss that having a common set of set of parameters for different mechanisms will help with interoperability.

Section 3.8.2
s/Both of the two cases may may generate/Both of the cases may generate·

Section 4. Data plane enhancements

>>If the data plane is enhanced, should we say something about the existing DetNet data plane and backward compatibility with it?

Lastly,

I found control plane considerations section missing. Since large scale networks are formed from stitching of multiple domains, at least one activity standards worthy is how the domains will exchange information together? This is somewhat covered in Section 3.8.2. But my overall concern with this requirements document is that it has very few constraints. There are no limits on time-sync requirements, mechanisms, topologies, link speeds, buffers etc. Then how do we verify/claim that the DetNet flows will meet the requested QoS for all DetNet flows in that large-scale network. Maybe we also need a requirement for control planes to signal feasibility, violations, and monitoring performance of the deterministic flows.


Thanks
Kiran