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

[János Farkas <[e-mail]>]

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