Re: [Detnet] Suresh Krishnan's No Objection on draft-ietf-detnet-architecture-11: (with COMMENT)

[Suresh Krishnan <[e-mail]>]

Thanks for the text changes János. They look good to me.

Regards
Suresh

On Mar 2, 2019, at 4:03 PM, János Farkas <[e-mail]<mailto:[e-mail]>> wrote:

Hi Suresh,

Thank you for your review!

Please see in-line:

On 2/21/2019 3:11 PM, Suresh Krishnan wrote:
Suresh Krishnan has entered the following ballot position for
draft-ietf-detnet-architecture-11: 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/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/



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

* Section 3.2.1.1.

Given that we also know some of the downsides as well of large buffers, I think
a pointer to some background might be warranted here. I would recommend a basic
reference to something like

Bufferbloat: Dark Buffers in the Internet, Communications of the ACM, January
2012,
Add reference with new sentence at the end of the paragraph: "Note that large buffers have some issues, see, e.g., [BUFFERBLOAT]."


* Section 3.2.2.2.

It is not obvious to me how the POF cannot be the last operation at the
receiver. Can you clarify? Also, do intermediate nodes apply the POF? I can see
the need for them to do PRF and PEFs but I am not sure applying the POF at
intermediate nodes can necessarily help the low latency and low jitter goals.

   The order in which a DetNet node applies PEF, POF, and PRF to a
   DetNet flow is implementation specific.
The intention here is not to bound any specific order of the PREOF functions within a device, or not even bound which device implements which function. There can be complex network set-ups created. Furthermore, different implementations may have different pros and cons with respect to the order of PREOF functions. As pointed out, this is mainly valid for PRF and PEF; however, the same leave it open approach can be carried on all of the PREOF functions including POF.

Would it help to replace the sentence with?:
  The order in which a DetNet node applies PEF, POF, and PRF to a
   DetNet flow is left open for implementations.


* Section 3.2.3.

RFC7426 does not contain much specific information about explicit route setup.
Is there a particular section you want to point to. If not, I don't think this
reference is of much use. RFC8453 is listed twice.
Delete RFC7426 and one of the RFC8453s.


* Section 3.3.1.

Not sure why this is a requirement but I do wish to note that there are no such
worst-case latency guarantees for best effort traffic (aka non-Detnet) in
current networks. Can you clarify?

   o  DetNet flows can be shaped or scheduled, in order to ensure that
      the highest-priority non-DetNet packet is also ensured a worst-
      case latency.
This is to protect the QoS of non-DetNet flows if needed.DetNet flows have stringent QoS requirements. There may be non-DetNet flows that are not best-effort, but have some QoS requirements, although, less stringent than that of the DetNet flows.



* Section 4.1.1.

This text "Peers with Duplicate elimination." seems to be completely out of
place under the "Packet sequencing" heading below Figure 2. Copy and paste
error?
Packet sequencing peers with duplicate elimination. It is explained under duplicate elimination as well, and they are leveled in the figure. Would merging the two sentences help?:
           As part of DetNet service protection, supplies the sequence
           number for packet replication and elimination (Section 3.4),
           thus peers with Duplicate elimination.


* Section 4.3.2.

I found the expression "number of bit times" confusing. I have understood "bit
time" to mean the amount of time taken to emit a bit from a network interface.
Based on that definition, this expression does not make sense. Is there a
better reference/definition of what you mean?
Would it help to rewrite?:

OLD:
   These parameters, together with knowledge of the protocol stack used
   (and thus the size of the various headers added to a packet), limit
   the number of bit times per observation interval that the DetNet flow
   can occupy the physical medium.

NEW:
   These parameters, together with knowledge of the protocol stack used
   (and thus the size of the various headers added to a packet), provide the
   bandwidth that is needed for the the DetNet flow.



* Section 4.5.

There might be some other recent IETF defined mechanisms that might be relevant
to mention here as well. e.g. RFC8289 (Codel), RFC8033 (PIE) etc.

Add RFC8289 and RFC8033 with a new sentence as the penultimate sentence of the section:
"Further techniques are defined by the IETF, e.g., [RFC8289] and [RFC8033]."



* Section 4.7.2.

While IPv6 does offer a mechanism to add/remove a flow id (flow label) not sure
what kind of mapping you were thinking for IPv4. If this is not possible, I
think a note to that effect might be useful here.
Flow identification details for IP data plane are described in draft-ietf-detnet-dp-sol-ip. Would it help to add the following introductory text to Section 4.7?:
"This section discusses what needs to be done at technology borders including Ethernet as one of the technologies. Flow identification details for MPLS and IP data planes are described in [I-D.ietf-detnet-dp-sol-mpls] and [I-D.ietf-detnet-dp-sol-ip], respectively."


* Sections 5 and 6

I also support Alissa and Benjamin's DISCUSSes (on privacy and security) and
would like to see them addressed.



Thank you,
Janos