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

From: Paul Wouters via Datatracker <[email-masked]>
Date: Thu, 07 Apr 2022 05:31:10 -0700

Paul Wouters 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:
----------------------------------------------------------------------

Well written document. I have some comments that can be answered or ignored as
the authors see fit.

   If an already-established DetNet flow would be pushed beyond its latency
   requirements by the new DetNet flow, then the new DetNet flow can be
   refused, or some other suitable action taken.

This seems like a great power and should come with great responsibility. If
being a member of a DetNet is voluntary, that seems fine. But if such
membership is forced on the enduser, the concerns of RFC 8890 come into play.

[BennettDelay]

This seems to be a broken reference in section 4.2.2

   As illustrated by numerous
   implementation examples, some of the "Layer 3" mechanisms described
   in documents such as [RFC7806] are often integrated, in an
   implementation, with the "Layer 2" mechanisms also implemented in the
   same node.

But shepherds write up said:

   While there seems to be interest in this specification from multiple
   vendors, there are no publicly known implementations of this
   specification.

Which leaves me wondering what "implementation examples" refers to.

The security considerations mostly (and rightly so) point to RFC 9055 and RFC
8655. Although those seem to mostly focus on attacks against DetNet and there
is no mention of abuse by the DetNet. For example, if a mobile phone is
considered to be within a DetNet, the enduser has no real choice but to be part
of this. If a common service like a speedtest service the user can run to
evaluate their internet connection is also within or linked to a DetNet, it can
present the user a very false sense of low latency and network speed by simply
reserving an excessive amount of network between the endusers and the speedtest
service. This leads to a more generic concern of DetNet placing us in the "user
vs network" debate on who should have a say in how packets flow, which is
clearly not a problem this document needs or can address.

---

From: Mohammadpour Ehsan <[email-masked]>
Date: Fri, 8 Apr 2022 14:45:56 +0000

Dear Paul,

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

DetNet is not best effort and using the DetNet services requires resource reservation and allocation. As soon as a flow is admitted by DetNet, resources are reserved to guarantee the requirements of the flow. If I understood correctly, what you mean by “member of DetNet" is “admitted to DetNet" (please correct me if it is wrong). In this case, a member of DetNet is guaranteed a DetNet service and is not refused.
Here, by “new DetNet flow”, we mean “new DetNet flow request". It will be modified in the next version of the draft.

[BennettDelay]

I have double-checked the reference and it worked. Perhaps it was temporary out?

RFC7806 listed a number of such mechanisms and references their implementations such as:
https://dl.acm.org/doi/10.1145/63039.63045
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=502236&tag=1

Or IEEE ATS (referred in this draft as [IEEE8021Qcr]):
https://1.ieee802.org/tsn/802-1qcr/
Rate-controlled static-priority queueing: https://ieeexplore.ieee.org/document/253355

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 7 Apr 2022, at 17:01, Paul Wouters via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

[BennettDelay]