Re: [Gen-art] Genart last call review of draft-ietf-detnet-architecture-08

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

Hi Joel,

Thank you very much for your review!

Please find below in-line responses and how we plan to update the draft 
to resolve your comments.

Best regards,
Janos


On 9/22/2018 2:59 AM, Joel Halpern wrote:
> Reviewer: Joel Halpern
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-detnet-architecture-08
> Reviewer: Joel Halpern
> Review Date: 2018-09-20
> IETF LC End Date: 2018-10-03
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This document is ready for publication as a Proposed Standard
>
> I presume that the status was selected so as to avoid the need for downrefs
> when other Detnet documents normatively reference this one?
>
> Major issues: N/A
>
> Minor issues:
>      Section 3.1 states that worst case delay for priority queueing is
>      unbounded.  That does not match my understanding.  I know that DelayBound
>      DSCP behavior tightly (although, I think, not as tightly  as Detnet) limits
>      both the worst case delay and the delay variation.
Strict priority is not good enough for DetNet. A high priority packet 
may need to wait until the transmission of a lower priority packet is 
finished at an outbound port, which can cause too much uncertainties in 
the network.

>
>      It seems very odd that section 3.2.1.1 says that DetNet flows can not be
>      throttled when earlier text says that DetNet flows do have a maximum
>      bandwidth.  Buried in section 4.3.2 I find that what is meant by throttled
>      is not "enforcing a rate limit", but rather "sending congestion
>      notification to cause the source to slow down."  I think the wording about
>      "can not be throttled" both in 3.2.1.1 and 4.3.2 should be adjusted for
>      clarity.
The text will be updated to clarify.

Section 3.2.1.1:

OLD:
The primary means by which DetNet achieves its QoS assurances is to
reduce, or even completely eliminate, congestion within a node as a
cause of packet loss. Given that a DetNet flow cannot be throttled,
this can be achieved only by the provision of sufficient buffer
storage at each hop through the network to ensure that no packets are
dropped due to a lack of buffer storage.

NEW:
The primary means by which DetNet achieves its QoS assurances is to
reduce, or even completely eliminate, congestion within a node as a
cause of packet loss. This can be achieved only by the provision of
sufficient buffer storage at each hop through the network to ensure
that no packets are dropped due to a lack of buffer storage. Note that
a DetNet flow cannot be throttled, i.e., its transmission rate cannot be
reduced via explicit congestion notification.


Section 4.3.2:

OLD:
There is no provision in DetNet for throttling DetNet flows (reducing
end-to-end transmission rate via any explicit congestion
notification); the assumption is that a DetNet flow, to be useful,
must be delivered in its entirety.

NEW:
There is no provision in DetNet for throttling DetNet flows, i.e.,
the transmission rate cannot be reduced via explicit congestion
notification. The assumption is that a DetNet flow, to be useful,
must be delivered in its entirety.

>      3.2.1.1 also reads oddly in that it seems to recommend providing
>      significant buffering, when the need for and use of such buffers is a major
>      source of jitter.

The next paragraph in 3.2.1.1 explains that the buffers have to be 
adequately designed, which keeps under control the delay and jitter that 
can be caused by buffering:

"Ensuring adequate buffering requires, in turn, that the source, and
every DetNet node along the path to the destination (or nearly every
node, see Section 4.3.3) be careful to regulate its output to not
exceed the data rate for any DetNet flow, except for brief periods
when making up for interfering traffic. Any packet sent ahead of its
time potentially adds to the number of buffers required by the next
hop DetNet node and may thus exceed the resources allocated for a
particular DetNet flow."



>      In section 4.1.2, I realized that the Detnet Transit node terminology had
>      mildly confused me.  The text says "DetNet enabled nodes are interconnected
>      via transit nodes (e.g., LSRs) which support DetNet, but are not DetNet
>      service aware."  Reading this, and the definitions in section 2.1, it
>      appears that a Detnet Transit node is a node that is providing transport
>      behavior that detnet needs, but is not actually modified for detnet.
Based on last call comments: 
https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, the 
phrase "DetNet enabled nodes" is removed from the document and it has 
been made clear what type of DetNet node is meant:
The text is updated to:

    A "Deterministic Network" will be composed of DetNet enabled end
    systems, DetNet edge nodes, DetNet relay nodes and collectively
    deliver DetNet services.  DetNet relay and edge nodes are
    interconnected via DetNet transit nodes (e.g., LSRs) which support
    DetNet, but are not DetNet service aware.



>      Section 4.4.2 talks about per flow per node state.  It would be good to
>      have a forward reference to section 4.9 about scaling to larger networks.
Forward reference will be added.

> Nits/editorial comments:
>       It would be good if there were some explanation for the 75% maximum number
>       in section 3.3.1.  That there is some limit seems intuitive.  What value
>       that limit has is not so obvious.
75% is been removed based on last call comments: 
https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html.

>      Section 4.7.3 introduces an example using Ethernet Mulicast destiantions as
>      part of labeling.  There is no earlier explanation of the use of an
>      Ethernet MAC Multicast destination, and the text does not seem to require
>      that the traffic be actually multicast.  Hence the reader is liable to be
>      confused by the reference to multicast.  I rate this only a nit as it seems
>      clear that this is an example whose details are presumably explained in
>      another document.    Still, it would help to clarify the example.
>
>
Multicast MAC address is removed based on last call comments: 
https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html,