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

From: Martin Duke via Datatracker <[email-masked]>
Date: Mon, 04 Apr 2022 09:06:27 -0700

Martin Duke 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:
----------------------------------------------------------------------

I don't understand this sentence in the introduction:

"It disregards the in-band packets that can be part of the stream such as OAM
and necessary re-transmissions"

Are you referring to retransmissions of user data? If so, that sounds like an
important consideration for latency bounds!

Thanks to Yoshi for the TSVART review.

Nits:

(2) s/PROEF/PREOF

(6.6) s/is the same cycle/in the same cycle (or maybe I just don't understand
this sentence?)

---

From: Mohammadpour Ehsan <[email-masked]>
Date: Wed, 6 Apr 2022 20:44:48 +0000

Dear Martin,

Thank you very much for your comments!

In DetNet networks, congestion losses are avoided as a primary goal of DetNet (by allocating proper buffer space through flow path). Moreover, replication mechanisms intend to recover possible non-congestion losses, e.g., due to link failure. Therefore, we expect that packet losses are either avoided or recovered and hence most applications do not need to perform re-transmission. However, if there is a packet loss in a network and the corresponding application wants to re-transmit, a re-transmitted packet is counted as a new packet for conformance with the T-SPEC of the corresponding DetNet flow. In this case, the Bounded Latency I.D. provides delay-bound computations for the re-transmitted packet.
Besides, in-band packets such as OAM are part of a DetNet flow and should be accounted in the T-SPEC of the flow when computing the delay bounds.

We have noticed that this sentence is out-of-place in this document and causes confusion and hence decided to remove it in the new version.

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 4 Apr 2022, at 20:36, Martin Duke via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

Nits:

(2) s/PROEF/PREOF

---

From: Martin Duke <[email-masked]>
Date: Wed, 6 Apr 2022 13:46:03 -0700

sounds good to me.

On Wed, Apr 6, 2022 at 1:44 PM Mohammadpour Ehsan <
[email-masked]> wrote:

> In DetNet networks, congestion losses are avoided as a primary goal of
> DetNet (by allocating proper buffer space through flow path). Moreover,
> replication mechanisms intend to recover possible non-congestion losses,
> e.g., due to link failure. Therefore, we expect that packet losses are
> either avoided or recovered and hence most applications do not need to
> perform re-transmission. However, if there is a packet loss in a network
> and the corresponding application wants to re-transmit, a re-transmitted
> packet is counted as a new packet for conformance with the T-SPEC of the
> corresponding DetNet flow. In this case, the Bounded Latency I.D. provides
> delay-bound computations for the re-transmitted packet.
> Besides, in-band packets such as OAM are part of a DetNet flow and should
> be accounted in the T-SPEC of the flow when computing the delay bounds.
>
> We have noticed that this sentence is out-of-place in this document and
> causes confusion and hence decided to remove it in the new version.
>
>
> Best,
> Ehsan
>
>
>
> --
> Ehsan Mohammadpour
> On 4 Apr 2022, at 20:36, Martin Duke via Datatracker <[email-masked]>
> wrote:
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/