Re: [Detnet] Comments for draft-km-detnet-for-ocn-03

[[e-mail]]

Hi Kiran and Peng,

Sorry for the late reply!

For the discussion about "4.2.4. Provisioning for a variety of Traffic flows", I have same opinions with you.


Scaling-requirements section 3.8 has mentioned the enhanced DetNet should support different levels of application requirements.  I think this is an important requirement for the DetNet deployment.
The draft-km-detnet-for-ocn has provided a good example use case and it may cover different levels of applications within industrial operations and control process.



Moreover, mutiple services and traffic flows with different bounded latency requirements may be also co-existed in the same application.
These flows should be transmitted and forwarded with different DetNet behaviors.

From the use cases in RFC8578, DetNet applications differ in their network topologies and specific desired behavior and different services requires differentiated DetNet QoS. 
But the DetNet QoS in RFC8655 is expressed in single goal of bounded latency.   Differentiated DetNet QoS and different DetNet behaviors may be discussed.
The detailed requirements and gap analysis has been provided  in https://datatracker.ietf.org/doc/draft-xiong-detnet-enhanced-detnet-gap-analysis/. 
Hope more discussion and collaborate with you about this topic! Thanks!


Best Regards,
Quan













<Thanks Peng for reviewing the recent version. Please see inline.


<On September 27, 2023 at 8:28:48 PM, Peng Liu ([e-mail])
<wrote:

<Hi Authors,


<I have read this document, it is clear and the use case is good, here are
<some questions and comments.


<*4.2.3. Split Traffic flows*

<As I can image, the data reported from the sensor is in a period of s/ms,
<which is longer than the period that detnet can provide, it is a waste for
<the detnet capability. Or, is there any other data reported in a matched
<period with detnet?

<[KM} I am interested in using DetNet for closing the control loops. While
<some sensors are longer periods, others are part of control-loops and will
<be in response to control-cmds. I find them both essential; the expectation
<is a DetNet service provider will know how to forward them. Moreover, an
<application should have one interface to the network. Assuming in a network
<both DetNet and BE flows will be supported, an intelligent network edge can
<steer the traffic per application’s request.

<*4.2.4. Provisioning for a variety of Traffic flows
<<https://www.ietf.org/archive/id/draft-km-detnet-for-ocn-03.html#name-provisioning-for-a-variety->*

If my understanding is right, you mean that a same application have at
least two kinds of flows that need detnet service, but they have different
latency requirement. If the flows are from two different applications, they
will have different 5/6 tuples that are easily to be distinguished.
However, it can’t do that when the flows are from the same app. It is good,
I also thought about this before, the flow of audio, video, text, control
function have different level in a same application, for instance, the
XR/could gaming.

Yes, you are right. In case of industrial control applications a PLC
(especially the ones in top of hierarchy) can support upto 256 or more
devices. Each request towards field devices can have different latency from
the software PLC. Moreover, this approach supports better programmability
and dynamic changes. Essentially, we want to generalize EH approach for any
number of app-flows to provide graceful scalability.

Yes, the XR case is also a very good use case and gaming is actually quite
suitable here because this will allow to close the control loop. So
feedback in low latency applications can be deterministic and programmable.



*5.1. System Behavior*


In the old version it was 'Application association to Forwarding sub layer'
and proposed two potential ways, it is good to remove the method '*carry
the application defined data over DetNet as is and enable processing on
transit nodes*' .

I will happy to remove this. It was added because I had received an offline
comment about this possibility. I think I do mention that option is not of
immediate interest (or scope).



We can see there are people have many thoughts about the enhancement of
DetNet, and the WG is working on the queuing mechanisms and dataplane
enhancement now. We should follow the steps of WG.

I am afraid did not understand this comment. IMO, this approach is UNI data
plane is orthogonal to (Deterministic) network queuing mechanisms.


Meanwhile, I think this document is a good start to think from the
applications side to use detnet. In the requirements document section 3.8,
it also demonstrates some about the different levels of the applications
now.

Another aspect is that do you have any PoC of your draft? It is important
now at this stage. Some of the queuing solution drafts have the trial or
PoC to verify their effectiveness.

I am shorthanded for ietf-118 timeframe but of course, we plan to share our
code and post implementation details definitely before 119.

Thanks again for your interest in this work.

-Kiran



Regards,
[e-mail]_______________________________________________
detnet mailing list