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

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

Thank you Suresh,
Janos

On 3/7/2019 5:41 PM, Suresh Krishnan wrote:
> 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
>