Subject: [Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-bounded-latency-09: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 05 Apr 2022 02:51:06 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-detnet-bounded-latency-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-bounded-latency/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. It was a fascinating read and
most of the text is easy to understand. Good job ! Could even end up as
educational material ;-)

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to:

- Lou Berger for the shepherd's write-up including the absence of
implementations

- Ralf Weber for his IETF last call INT directorate review at:
https://datatracker.ietf.org/doc/review-ietf-detnet-bounded-latency-08-intdir-lc-weber-2022-02-06/.
Ralf's review was acted upon by Mohammadpour Ehsan ;-)

I hope that this helps to improve the document,

Regards,

-éric

Please note that I am not a DetNet expert, hence some comments are possibly not
relevant. The use of "regulator" instead of "shaper" was also surprising to me
;-) There may even be a semantic difference between a shaper and a regulator
that I have to learn.

More generally, the document is about a bound on the latency, but would it be
possible to compute an aggregate latency curve, which could also be interesting?

## Abstract

The document goes beyond "it provides a methodology to compute end-to-end
latency" as it describes how admission control is important and gives formulas
to compute the latency bounds in many technologies. The content is great but
the abstract should reflect the actual content.

## Section 1

"DetNet flows are characterized by" is followed by only 2 characteristics of
DetNet and does not mention low packet loss. Even if this I-D is about latency,
why not adding "notably" in the text ?

## Section 2

As noted by other ADs, either the acronym "PROEF" or its expansion is wrong ;-)

## Section 3.1.1

Perhaps some examples of "static latency" could be added to ease the reading ?
E.g., does it include serialisation and propagation times ?

Have the authors considered the use of "constant" rather than "static" ?

## Section 3.2

Does DetNet support some link having some flow control / congestion at layer-2
or layer-1 ?

Are there any DetNet relay able to start forwarding packet after receiving just
a couple of bytes of the frame w/o having to wait for the full frame reception
? Similarly, should the deserialisation delay be taken into account ? Or any
congestion inside a relay node (e.g., contention to a backplane bus)

## Section 4.1

Is "end-to-end delay" defined in DetNet architecture ? I.e., is it from first
bit out from the source to the last bit received by the destination ? Or other
variation ? Or the difference is so small that it does not care ?

## Section 4.4

Sorry couldn't resist in suggesting to rename "DetNet-unaware island" into
"DetNet-unaware swamp" ;-) (comment to be ignored of course)

## Section 5

Should some assumptions be listed ? E.g., no packet
replication/generation/encapsulation/discard by the relay node ?

## Section 6.1

Is the list at the end of this section exhaustive ? If so, then why not adding
"IP protocol (e.g., UDP or TCP)" ? Else, please let's be clear that it is not
exhaustive.

# NITS

AFAIK, XML2RFCv3 has features for mathematical formulas that could be used for
this document to increase readability.

Usually, "e.g." is followed by a coma. Same for "i.e.".

## Section 1

Multiple lists in the section would benefit from a correct markup to put one
bullet per line.

In "It disregards the in-band packets", and accept all my apologies for not
being a native English speaker, but "disregards" sounds really negative.

## Section 6.3

s/Time Aware Shaper/Time-Aware Shaper/ ?

---

From: Mohammadpour Ehsan <[email-masked]>
Date: Wed, 6 Apr 2022 21:41:37 +0000

Dear Éric,

Thank you very much for your comments. Please find below my responses.

"regulator" is the "shaper" defined in RFC2475. In time-sensitive networks, a common referred mechanisms is “credit-based shaper”, which does not perform as a shaper defined in RFC2475. Moreover, the term "regulator” has been used frequently in the literature especially with the emergence of "interleaved regulators”. Hence to avoid possible confusion regarding the term “shaper", we decided to use “regulator”,

I am not sure that I understand the term “aggregate latency curve”. Do you mean latency bounds on an aggregate of flows sharing a queue?

## Abstract

As mentioned in the last line of the abstract:
"The methodology can be used by the management and control planes and by resource reservation algorithms to provide bounded latency and zero congestion loss for the DetNet service”,
the focus of Bounded Latency I.D. is not admission control; however, it gives some guidelines on how it can be used in the admission control without jumping into details. Section 6.4.2 gives an example on this for a specific mechanism.

## Section 1

In the new version, we change the sentence to:

"As explained in [RFC8655<https://www.ietf.org/archive/id/draft-ietf-detnet-bounded-latency-09.html#RFC8655>], DetNet flows are notably characterized by…"

## Section 2

It is typo and should have been “PREOF”. It is corrected in the new version.

## Section 3.1.1

Here, “static” refers to “latency calculation”, meaning that the latency calculation is done statically. We believe that a hyphen is necessary. In the new version, we change it “static latency-calculation”. The same has applied in “dynamic latency-calculation”.

## Section 3.2

In this document, a DetNet relay node is characterized as a service curve, which is used for delay bound computation. Therefore, any implementation-specific detail, e.g., fast-forwarding, serialization, deserialization, is included in the service curve. The methodology presented in this document holds independent of such implementation-specific details.

## Section 4.1

To the best of our knowledge, the exact definition of “end-to-end delay” is not present in the DetNet architecture RFC8655. In our document, we refer to the “end-to-end delay” as start of transmission of a packet from source (or DetNet ingress node) until its full reception at destination (or DetNet egress node), i.e., from first bit out from the source (or DetNet ingress node) to the last bit received by the destination (or DetNet egress node).

## Section 4.4

The term “island” has been used in some other RFCs within a similar context:

RFC9055 (Deterministic Networking Security Considerations): “DetNet islands”
RFC8578 (Deterministic Networking Use Cases): "Layer 2 Islands"

## Section 5

In the new version, we made the assumptions clear for the computed bound.

## Section 6.1

No, it is not an exhaustive list. It is corrected in the new version.

# NITS

Thanks for the suggestion. Are you referring to RFC7991?

It is corrected in the new version.

## Section 1

It is modified in the new version.

Corrected in the new version!

## Section 6.3

Corrected!

Best,
Ehsan

--
Ehsan Mohammadpour
PhD candidate at Swiss Federal Institute of Technology (EPFL)
EPFL EDIC PhD student representative
IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne, Switzerland
https://people.epfl.ch/ehsan.mohammadpour

On 5 Apr 2022, at 14:21, Éric Vyncke via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

Special thanks to:

Regards,

-éric

## Abstract

## Section 1

## Section 2

## Section 3.1.1

## Section 3.2

## Section 4.1

## Section 4.4

## Section 5

## Section 6.1

# NITS

## Section 1

## Section 6.3

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 12 Apr 2022 15:46:29 +0000

Hello Ehsan,

Thank you for your reply, my previous email was mainly about non-blocking points but I appreciate that you took time to reply.

Additional comments indicated by EV> (else all the rest is fine)

Regards

-éric

From: Mohammadpour Ehsan <[email-masked]>
Date: Wednesday, 6 April 2022 at 23:42
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, DetNet Chairs <[email-masked]>, DetNet WG <[email-masked]>, Lou Berger <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-detnet-bounded-latency-09: (with COMMENT)

Dear Éric,

EV> Thank you

EV> rather than a single point (the top bound), I was alluding to have more like a probability distribution of the latency

## Abstract

## Section 1

EV> sounds better ;-)

## Section 2

## Section 3.1.1

EV> up to the authors

## Section 3.2

EV> ack

## Section 4.1

## Section 4.4

## Section 5

EV> thanks

## Section 6.1

# NITS

EV> or using UTF-8 for unicode characters

## Section 1

## Section 6.3

Best,
Ehsan

Special thanks to:

Regards,

-éric

## Abstract

## Section 1

## Section 2

## Section 3.1.1

## Section 3.2

## Section 4.1

## Section 4.4

## Section 5

## Section 6.1

# NITS

## Section 1

## Section 6.3