[Detnet] Alissa Cooper's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)

Alissa Cooper <alissa@cooperw.in> Wed, 20 February 2019 14:54 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: detnet@ietf.org
Delivered-To: detnet@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C97130E8E; Wed, 20 Feb 2019 06:54:38 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-detnet-architecture@ietf.org, Lou Berger <lberger@labn.net>, detnet-chairs@ietf.org, lberger@labn.net, detnet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155067447797.31337.768983002923056061.idtracker@ietfa.amsl.com>
Date: Wed, 20 Feb 2019 06:54:37 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/V8mkyNiIDyRvfxRIZ6CjZBWttZU>
Subject: [Detnet] Alissa Cooper's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2019 14:54:43 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-detnet-architecture-11: Discuss

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

= Section 6 =

"DetNet is provides a Quality of Service (QoS), and as such, does not
   directly raise any new privacy considerations."

This seems like a false statement given the possibility that DetNet may require
novel flow IDs and OAM tags that create additional identification and
correlation risk beyond existing fields used to support QoS today.


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

I support Benjamin's DISCUSS.

I agree with others that this document should be informational.

= Section 3.1 =

"There are, of course, simpler methods available (and employed, today)
   to achieve levels of latency and packet loss that are satisfactory
   for many applications."

I think this paragraph would make more sense if it said "specific levels of
latency and packet loss for particular applications." A lot of applications
have satisfactory performance without any of the methods/techniques described.

"Prioritization and over-provisioning is one
   such technique."

It seems these are two techniques, not one.

= Section 3.2.1.2 =

s/sensitive/time-sensitive/

I can't parse this sentence:

'In general, users are encouraged to use, instead of, "do this when you
   get the packet," a combination of:

   o  Sub-microsecond time synchronization among all source and
      destination end systems, and

   o  Time-of-execution fields in the application packets.'

= Section 3.2.2.2 =

s/ Either of these functions/ Any of these functions/

"Providing sequencing information to the packets of a DetNet
      compound flow.  This may be done by adding a sequence number or
      time stamp as part of DetNet, or may be inherent in the packet,
      e.g., in a higher layer protocol, or associated to other physical
      properties such as the precise time (and radio channel) of
      reception of the packet."

How do multiple connected DetNet nodes know which fields they are supposed to
use as the packet sequence number?

= Section 3.3.1 =

"the highest-priority non-DetNet packet is also ensured a worst-case latency."
--> Did you mean "ensured less than or equal to a worst-case latency"?

= Section 4.3.2 =

If applications need to be altered to be run over DetNet, or if they need to be
DetNet-aware, it would be useful to state that explicitly up front somewhere in
this document. This is sort of implied in this section but it's not clear.

= Section 6 =

"However, the requirement for every (or almost every) node along the
   path of a DetNet flow to identify DetNet flows may present an
   additional attack surface for privacy, should the DetNet paradigm be
   found useful in broader environments."

I'm not sure what is meant by "broader environments." Is the implication that
flow identification doesn't present a privacy risk within a single
administrative domain? I don't think that is always true.