Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

["Black, David" <[e-mail]>]

Looking at this from a Transport (Area) viewpoint, I have a few mostly editorial comments:

-- Section 3.1

   o  Minimum and maximum end-to-end latency from source to destination;
      timely delivery and jitter avoidance derive from these constraints

"jitter avoidance" -> "limits on jitter"
as jitter cannot be entirely avoided.

   o  Probability of loss of a packet, under various assumptions as to
      the operational states of the nodes and links.  A derived property
      is whether it is acceptable to deliver a duplicate packet, which
      is an inherent risk in highly reliable and/or broadcast transmissions

"derived" does not seem to be the right word in "derived property" and
the whole second sentence seems off.   Suggest:

   o  Probability of loss of a packet, under various assumptions as to
      the operational states of the nodes and links.  If packet replication
      is used to reduce the probability of packet loss, then a related
      property is the probability (may be zero) of delivery of a duplicate
      packet.  Duplicate packet delivery
      is an inherent risk in highly reliable and/or broadcast transmissions.

-- Section 3.2

Text in 3.1 lists three techniques used by DetNet to provide QoS, but
section 3.2 (Mechanisms to achieve DetNet QoS) has five subsections.
An introductory paragraph in 3.2 (before 3.2.1) to explain how the five
mechanisms relate to the three techniques would be helpful.  As 3.2.3 on
jitter reduction is related to 3.2.1 on congestion protection, it might
help to swap the order of 3.2.2 and 3.2.3 so that the congestion
protection material is contiguous.

-- Section 4.1.1, after Figure 2

   The layers are, from top to bottom:

Not exactly - the list that follows does not contain an entry per layer.  Suggest

   The functionality shown in Figure 2 is:

and I would move OAM out of the list to its own paragraph at the end of
Section 4.1.1, as OAM is not shown in Figure 2.

-- Section 4.3.2 Source guarantees

Section title seems off, as nothing is being guaranteed to the source.
Would "Source transmission behavior" or Source transmission requirements"
be clearer?

   The source promises that these limits will not be exceeded.

I don't understand "promises" - who/what is the recipient of the promise, and 
how is the promise made?  Suggest:

   The source is required not to exceed these limits in order to obtain DetNet service.

-- Section 4.3.3 Incomplete Networks

   as
   extra buffering, and thus extra latency, must be allocated at points
   downstream from the non-DetNet intermediate node for a DetNet flow.

I don't think "extra latency" is being "allocated" - in addition, jitter should be
mentioned.   Suggest:

   as
   extra buffering must be allocated at points
   downstream from the non-DetNet intermediate node for a DetNet flow.
   This extra buffering may increase latency and/or jitter.

-- Section 4.10.  Scaling to larger networks

   The DetNet data plane, in
   order to support larger numbers of DetNet flows, must support the
   aggregation of DetNet flows into tunnels, , which themselves can be
   viewed by the transit nodes' data planes largely as individual DetNet
   flows.

That sentence makes two points:
  a) Flow aggregation is required for scaling.
  b) That flow aggregation has to employ tunnels.

The first point is supported by the text in this section, but the second point
does not appear to have supporting text.  It appears that tunnels are necessary
because: 
	- Each aggregated flow has to be a DetNet flow, and hence has to have
		its own 	DetNet flow ID.
	- The DetNet flow IDs of the flows that comprise an aggregated
		flow have to be carried through the aggregated flow in
		order to correctly demux to those original DetNet flows
		at the downstream end of flow aggregation.
A sentence or two should be added to explain this.

Thanks, --David
p.s.  I see that I'm already listed in the Acknowledgements section - that is appreciated.

> -----Original Message-----
> From: detnet [mailto:[e-mail]] On Behalf Of Lou Berger
> Sent: Friday, May 11, 2018 5:44 PM
> To: DetNet WG
> Cc: DetNet Chairs
> Subject: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05
> 
> All,
> 
> This starts a two-week working group last call on
> draft-ietf-detnet-architecture-05
> 
> The working group last call ends on May 25.
> Please send your comments to the detnet mailing list.
> 
> 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,
> DetNet Chairs
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet