Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-bounded-latency-02

From: "Zhangjiayi (Jiayi)" <[email-masked]>
Date: Thu, 18 Feb 2021 07:17:30 +0000

Hi Ethan,

Many thanks for your review and feedback. 
Next version will be corrected regarding to the two typos.

Best regards,
Jiayi

-----邮件原件-----
发件人: detnet [mailto:[email-masked]] 代表 Ethan Grossman
发送时间: 2021年2月10日 5:19 AM
收件人: 'Lou Berger' <[email-masked]>; 'DetNet WG' <[email-masked]>
主题: Re: [Detnet] WG Last Call: draft-ietf-detnet-bounded-latency-02

I have watched the evolution of this draft and I find it to be a very important contribution to DetNet. It appears to be very close to publication-ready, although I can't vouch for the technical details. 

Typos: I think there are two typos in this sentence: 
  In the cosidered queuing model, there are four types of flows,
   namely, control-data traffic (CDT), class A, class B, and best effort
   (BE) in decreasing order of priority.  Flows of classes A and B are
   together referred to AVB flows.
1) cosidered s/b considered
2) "referred to AVB flows" s/b "referred to as AVB flows" (right? If not, please somehow clarify, e.g. if "referred" has a different meaning) 

<Jiayi> Yes, it s/b "referred to as"

Thanks to Jean-Yves, Norm, and the other authors for this draft. 
Ethan.

-----Original Message-----
From: detnet <[email-masked]> On Behalf Of Lou Berger
Sent: Friday, February 5, 2021 5:30 AM
To: DetNet WG <[email-masked]>
Subject: [Detnet] WG Last Call: draft-ietf-detnet-bounded-latency-02

All,

This starts working group last call on draft-ietf-detnet-bounded-latency-02
https://datatracker.ietf.org/doc/draft-ietf-detnet-bounded-latency/

The working group last call ends on February 19th.
Please send your comments to the working group mailing list.

Please note, there was an IPR disclosure against this document submitted on January 14, 2021, see https://datatracker.ietf.org/ipr/4581/
While this disclosure came very late in the document life cycle, it appears the filing was also relatively recent (2019-10-16) and after the pre adoption IP call:
https://mailarchive.ietf.org/arch/msg/detnet/1mwYdadDzTLudcuH5T5O7R_KlDs

Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
Lou (DetNet Co-Chair & doc Shepherd)

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: Dangjuanna <[email-masked]>
Date: Thu, 18 Feb 2021 07:27:02 +0000

Dear All,

I've read carefully this draft version of the draft and support progressing it to the publication as the Informational RFC.

I attach great importance to the CFQ mechanism in Chapter 6.6  which can effectively decrease even eliminate the jitter problems to achieve the better E2E bounded latency assurance ,  and think it should be flexibly applied to Layer 2 or Layer 3. Currently CFQ with two buffers has been mostly discussed, but, from the aspect of improving the bandwidth utilization and getting better bounded latency aspect, CFQ with more than two buffer is one better kind of approaches to deploy in Detnet network. So I think the deployment, mechanism and packet format related to  CQF with more buffers need to be standardized in future.

So I suggest to enrich several non-blocking comments for the author's consideration as follows.

- For a large DT, CQF with more buffers can be used(Current words). Due to the variation of DT, a time interval in T_c cannot be used to send packets in this class; otherwise the receiving node cannot distinguish which cycle the packets belong with. As the results, the bandwidth utilization is limited especially when T_c is small. Using explicit cycle labels in packets can help resolves this ambiguity, so that bandwidth utilization and small T_c can be simultaneously achieved. The mechanism, packet format and per-hop behavior related to explicit cycle labels need to be further studied and standardized.

Regards,

Joanna

> Please note, there was an IPR disclosure against this document

> submitted on January 14, 2021, see https://datatracker.ietf.org/ipr/4581/

> While this disclosure came very late in the document life cycle,

> it appears the filing was also relatively recent (2019-10-16) and

> after the pre adoption IP call:

> Positive comments, e.g., "I've reviewed this document

> and believe it is ready for publication", are welcome!

> [email-masked]<mailto:[email-masked]>

---

From: "Zhangjiayi (Jiayi)" <[email-masked]>
Date: Thu, 18 Feb 2021 07:57:39 +0000

Hi Greg,

Many thanks for your review and feedback.
Proposal regarding your comments is as below.  I will check with the co-authors then update the draft.

Best regards,
Jiayi

发件人: detnet [mailto:[email-masked]] 代表 Greg Mirsky
发送时间: 2021年2月13日 4:58 AM
收件人: Lou Berger <[email-masked]>
抄送: DetNet WG <[email-masked]>
主题: Re: [Detnet] WG Last Call: draft-ietf-detnet-bounded-latency-02

Dear All,
I've read the current version of the draft and support progressing it to the publication as the Informational RFC.
I have several non-blocking comments and questions for the author's consideration:

  *   In Abstract and Introduction "server" and "central server" referenced. Could it be used to identify an SDN controller or orchestrator? If that is the case or close, perhaps a more direct terminology can be used.
<Jiayi>  Thank you for rising this question. The “server”, “central server” relates to the controller plane functions, that may receive registration of DetNet flows, do resource reservation,  and configure to DetNet nodes. If I understand right, theyalso refers to the function of SDN controller or orchestrator. Then, the term “controller” might be more direct. (Please let me know your idea, if you have suggestion in the terminology here)

  *   Perhaps s/un-provisioning/de-provisioning/?
<Jiayi> Next version will be updated with “de-provisioning” .

  *   It's been quite a long time since I've seen a network device being referenced as "bridge". If there's no difference modeling different types of networking devices in Section 3.2, perhaps "typically, bridges or routers" can be omitted.
<Jiayi> Thank you for this suggestion. Here bridge is mentioned because this draft refers to some layer-2 queuing or scheduling techniques defined in IEEE 802.1 TSN, where bridge is always referred. Since detnet focus on Layer-3, to omit "typically, bridges or routers" would be more clear to readers.

  *   And in the same sentence, a part of the reference model is described as "a wired link". Could that be some other media, e.g., wireless?
<Jiayi> Thank you for this suggestion. It is no need to limit the link as wired link, and in next paragraph it mentioned that link delay could be variable. I think to delete “wired” would be better.

  *   you may choose to use a single term from "DetNet unaware", "DetNet non-aware", and "non-DetNet"
<Jiayi> Thanks. We will use non-DetNet

  *   the statement in the second paragraph's  first sentence appears very assertive:
   In general, when passing through a non-DetNet island, the island
   causes delay variation in excess of what would be caused by DetNet
   nodes.
I agree that under some conditions such a domain might cause higher delay variation but I am not sure that is always the case.
<Jiayi> Yes, the delay variation caused by non-DetNet domain may “sometimes” happen. I propose to revise this paragraph to be less assertive, as: “In general → Sometimes”, “DetNet flow is lumpier → DetNet flow might be lumpier”, etc.

  *   Further in that paragraph, is stated that "... can still be calculated and met if and only if the following are true" though the second bullet appears as a conditional "An ingress conditioning function (Section 4.3) may be required ...". I am not sure it is clear when that second bullet is true - if the conditioning function is required or if it is not needed.
<Jiayi> The idea that latency upper-bound could be calculated relies on two parts:  traffic has TSpec (like maximum burst size and average rate, or examples in Sec 6), and service can be model. After a non-DetNet domain, where both traffic and service can hardly be modeled, the re-entered traffic can hardly be described. From this point of view, I think it would be necessary that conditioning the flow when it traverses a non-DetNet domain, in case these flows deteriorate the other existing DetNet flows, as well as the re-entered flow itself cannot be calculated with  delay bound because its lack of TSpec.
Regards,
Greg

On Fri, Feb 5, 2021 at 5:30 AM Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
All,

Thank you,