Re: Genart last call review of draft-ietf-detnet-architecture-08

[János Farkas <janos.farkas@xxxxxxxxxxxx>]

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,