[Detnet] 答复: RE: Comments on (1) async and (2) queuing (draft-liu-detnet-large-scale-requirements)

["Yangfan(Fan,IP Standards)" <[e-mail]>]

Hi Peng,

Thank you for your quick reply. Please see inline started with Fan.


发件人: Peng Liu [mailto:[e-mail]]
发送时间: 2022年7月26日 22:59
收件人: Yangfan(Fan,IP Standards) <[e-mail]>; balazs.a.varga <[e-mail]>
抄送: detnet <[e-mail]>; draft-liu-detnet-large-scale-requirements <[e-mail]>
主题: Re: RE: [Detnet] Comments on (1) async and (2) queuing (draft-liu-detnet-large-scale-requirements)

Hi Fan,

Thanks for your comments, please see inline.

Regards,
Peng
________________________________
[e-mail]<mailto:[e-mail]>

From: Yangfan(Fan,IP Standards)<mailto:[e-mail]>
Date: 2022-07-25 17:18
To: [e-mail]<mailto:[e-mail]>; balazs.a.varga<mailto:[e-mail]>
CC: detnet<mailto:[e-mail]>; draft-liu-detnet-large-scale-requirements<mailto:[e-mail]>
Subject: RE: [Detnet] Comments on (1) async and (2) queuing (draft-liu-detnet-large-scale-requirements)
Hi Peng and Bala’zs,

Please allow me to chime in the discussions to section 5.2.

Firstly, the essence of carrying the metadata in data plane is to help achieve the bounded latency, not to convey or specify the queuing methods. Secondly, DetNet has no limitation on the underlying mechanisms to provide bounded latency, and queuing is one of the potential approaches. Regarding this metadata, IMHO a generalized name would be more appropriate to fit.
[PL] After discussing with Balazs and the co authors, we'd like to change it as "Information used  by Functions ensuring Deterministic Latency". Though the original name did not refer to any specific name or method of queuing, just for the metadata that might be used by it. We'd like not to limit in it, so please check whether the proposed change is acceptable for you.
Fan: thank you for reaching out in WG, and the new name is acceptable to me.


Although it’s a bit early to discuss the solutions, I can’t help to point out there have already been several I-Ds proposed. IMHO there are two groups, one is the metadata defined for each individual mechanism, another is the uniform format for multiple mechanisms. It is important to have some consensus on the understanding of metadata before jump into the proposals.
[PL] We think it would be more reasonable to leave that to solution(s) to explain why and what info would be useful.
Fan: I agree, the discussion is not in scope of the requirement draft. I would start a new thread for further discussion. Thanks again.


My 2 cents

Best,
Fan



From: detnet [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Wednesday, July 20, 2022 3:15 PM
To: balazs.a.varga <[e-mail]<mailto:[e-mail]>>
Cc: detnet <[e-mail]<mailto:[e-mail]>>; draft-liu-detnet-large-scale-requirements <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Detnet] Comments on (1) async and (2) queuing (draft-liu-detnet-large-scale-requirements)

Dear Balazs,

Thanks for your comments.

For Section 4.1.1, the text is more like your first understanding that 'the requirement is that the DetNet network must the interaction across time domains, so that time domains are synchronized."
It illustrated a requirement but not suggest any of the solutions. In the later text of this section,  there were some methods mentioned to meet the requirement, e.g. by compensating the time shift at the border. It just to prevent the requirement to be too vague. And we did not  think about them as"sync-as-a-service", but it might be a good direction to go.
If needed we can rewording the sentence as “The mechanism adopted by a large-scale deterministic network MUST be prepared to cope with non-synced TSN domains.”

For Section 5.2, the text did not imply to directly carry a name or type-id of queueing mechanism. You are right it is about metadata carrying to facilitate the different queueing or scheduling configured on intermediate nodes.
The ultimate goal is to achieve the e2e bounded latency, however the intention here is to say there can be various metadata to help achieving that.
To make the endpoint insert the e2e latency requirement is one of the possible mechanisms to me. There can be other ways, some new proposed drafts to detnet covered them (for example, tagging the cycle if cycle based queuing is used, allow the intermediate nodes to update the residence or remaining time if time deadline like queuing is used, etc). We would like the requirement document  to provide the space for all the potential mechanisms. Then each solution document should describe why a metadata should be carried and how it is added and used at each hop (or at the source) and ideally how that metadata helps which queuing or scheduling mechanism to achieving bounded latency (or other benefit, e.g. bounded jitter? Higher throughput? at the same level of bounded latency)
To remove the ambiguity earlier mentioned and at the same time not to make the metadata too narrowly scoped, how about we rename section 5.2 as “5.2.  Support Queuing Specific Metadata”. At the same time, it does not imply if there would be one or more metadata, or in one or more formats. That will be left to solutions for future discussion in the working group. I will also try to reformulate the 5.2 text a bit to better reflect the intention as illustrated in this email if you are ok with the title change and the way to explain.

Thanks again!
Peng & co authors
________________________________
[e-mail]<mailto:[e-mail]>

From: Balázs Varga A<mailto:[e-mail]>
Date: 2022-07-19 23:07
To: [e-mail]<mailto:[e-mail]>
CC: [e-mail]<mailto:[e-mail]>
Subject: Comments on (1) async and (2) queuing (draft-liu-detnet-large-scale-requirements)
Hi Authors,

I have two questions for clarification on your draft:

- Q1: Section “4.1.1.  Support Asynchronous Clocks Across Domains”
I have some difficulties to interpret the requirement as it is formulated.
Text says:
‘’ The mechanism adopted by a large-scale deterministic network MUST support
   the interaction across time domains, so that time domains are synchronized.”
My first understanding was that the requirement is that the DetNet network must
be prepared to cope with non-synced TSN domains. However at the second read
I have interpreted the text, that the DetNet domain provides something like a
“sync-as-a-service” to ensure that the TSN domains can be synchronized.

Could You clarify your intention (and maybe reformulate)?


- Q2: Section “5.2.  Support Queuing Related Information”
I am not sure that requiring the encoding of queuing information is the right direction
in a requirements document. I would argue for a more general formulation of the
requirement. The real target here is to provide metadata, that can help to achieve
the bounded LATENCY requirement. DetNet flow endpoints are more aware of the
latency requirement of a flow, than the queuing method used by the nodes along the
forwarding path.

What do You think about generalizing this section under the title “5.2.  Support Latency
Related Information”? One possible implementation option for that can be to add explicit
queuing information, but many other methods exists and described in various DetNet
documents.


Thanks & Cheers
Bala’zs