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

From: János Farkas <[email-masked]>
Date: Sat, 2 Mar 2019 22:03:48 +0100

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

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 7 Mar 2019 16:41:05 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi Suresh,

Please see in-line:

* Section 3.2.1.1.

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.

   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.

* Section 3.2.3.

* Section 3.3.1.

   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.

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?:

* Section 4.3.2.

OLD:

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.

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

Thank you,
Janos

---

From: János Farkas <[email-masked]>
Date: Sat, 9 Mar 2019 23:36:39 +0100

Thank you Suresh,
Janos

On 3/7/2019 5:41 PM, Suresh Krishnan wrote:
>> On Mar 2, 2019, at 4:03 PM, János Farkas <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Suresh,
>>
>>> Please refer to 
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> 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.
>>>
>> 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.
>>
>> have stringent QoS requirements. There may be non-DetNet flows that 
>> are not best-effort, but have some QoS requirements, although, less 
>> under duplicate elimination as well, and they are leveled in the 
>> figure. Would merging the two sentences help?: