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

[[e-mail]]

Hi Kiran,

Thanks for your reply!
Please see inline with [Quan].





>Hi Quan,
>No worries, glad you got time to skim through the document. Please see
>inline [KM].
 
 
>On October 9, 2023 at 12:12:16 AM, [e-mail]
>([e-mail] (mailto:[e-mail])) wrote:
 
> 
> 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 forocn has provided a good example use case and it may cover different levels of applications within industrial operations and control process.
> 
>[KM] Thanks! Just a bit of a nit - yes, we have provided a use case
that was not discussed in-depth earlier but more importantly, we are
also providing a solution. It would be nice (and is feasible) to
relate this approach to large-scale enhanced DetNet requirements. I
believe we all are waiting for queuing analysis to be finished first,
since that is the biggest focus right now.

[Quan]Agree, waiting for queuing solutions. And different levels of application requirement is also important and you give us a good example use case and solution. Thanks.


> 
> 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/.
> 
>[KM] I quickly went through the document. This is still DetNet
provider centric analysis. Whereas, our proposal is for
user-to-network interface and it scales. One possible approach could
be to add one more subsection in 5.2 to talk about gaps with respect
to user-interface with scalability and dynamic changes.
[Quan]Thanks for your suggestion. Yes, I did not consider user-to-network interface and the gaps. 
And I plan to update a new version for this draft before 118.
Are you interested to collaborate with me and provide some texts such as a subsection in 5.2?


> Hope more discussion and collaborate with you about this topic! Thanks!
>[KM] Indeed. See my suggestion above.

[Quan] Another comment about the section 5.4 is that the traffic control specification is carried in hop-by-hop option.
The metadata includes the bouned latency spec and delay variation spec which is specific requirement for this packet.
And I am not sure that the two  per-hop specs can be computed in controller along the path. 
From the queuing mechanims, the metadata should be carried may be end-to-end jitter or per-hop maximum delay.
If the metadata should be queuing-specific?I also think about that. Hope to discuss with you.Thanks.


>Thanks!
-Kiran
> 
> 
> 
> 
> 
> 
> Best Regards,
> 
> 
> Quan
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> * 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] (mailto:[e-mail])_______________________________________________ detnet mailing list
> 
> 
> 
> 
> 
> 
>