Re: [Detnet] Congestion Protection name change

["Black, David" <[e-mail]>]

> >>     Congestion protection operates by allocating resources along the path
> >>     of a DetNet flow, e.g., buffer space or link bandwidth.  Congestion
> >>     protection greatly reduces, or even eliminates entirely, packet loss
> >>     due to output packet congestion within the network, but it can only
> >>     be supplied to a DetNet flow that is limited at the source to a
> >>     maximum packet size and transmission rate.  

> >> We wanted to have a brief collective term for the mechanisms used to
> >> avoid queuing related packet loss (including buffer overflow etc.).

Perhaps "flow protection" as it protects individual flows and is configured/administered/managed at flow granularity??

The use of the word "resource" proposed below seems easy to mis-read as involving resources beyond the flow-by-flow scope of this functionality.

Thanks, --David


> -----Original Message-----
> From: detnet [mailto:[e-mail]] On Behalf Of János Farkas
> Sent: Monday, December 10, 2018 12:59 PM
> To: Lou Berger
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Detnet] Congestion Protection name change
> 
> 
> [EXTERNAL EMAIL]
> 
> I'm of course open to other alternatives. I'm interested to avoid the
> confusion; just proposed an initial idea.
> I'm afraid we won't find the ideal term, but it would be good to have a
> good enough one.
> 
> On 12/10/2018 3:47 PM, Pascal Thubert (pthubert) wrote:
> > The problem János is that we do not only avoid loss. We also control
> latency. So "queuing loss" is too limitation.
> > We are protecting the resources that are necessary, or providing
> guarantees that they are available. To provide the service.
> > Maybe "service guarantees" could be good?
> > Pascal
> I know, and it is also there in the document:
> 
> "   Congestion protection addresses two of the DetNet QoS requirements:
>     latency and packet loss.  Given that DetNet nodes have a finite
>     amount of buffer space, congestion protection necessarily results in
>     a maximum end-to-end latency.  It also addresses the largest
>     contribution to packet loss, which is buffer congestion."
> 
> also:
> "   The low-level mechanisms described in Section 4.5 provide the
>     necessary regulation of transmissions by an end system or DetNet node
>     to provide congestion protection.  The allocation of the bandwidth
>     and buffers for a DetNet flow requires provisioning.  A DetNet node
>     may have other resources requiring allocation and/or scheduling, that
>     might otherwise be over-subscribed and trigger the rejection of a
>     reservation."
> 
> In other words, we need adequate queuing mechanism with appropriate
> queue management plus resource allocation.
> 
> On 12/10/2018 6:15 PM, Lou Berger wrote:
> > Fwiw in the te world, we normally call this "resource allocation". As
> > a contributor, I'd be comfortable with that term or "resource
> > management".
> 
> I'd prefer "resource management" out of these two because I can talk
> into it that it is the combination of "resource allocation" and queue
> management".
> 
> Thanks,
> Janos
> 
> 
> >
> > Lou
> >
> >
> >
> > ----------
> > On December 10, 2018 9:30:20 AM János Farkas
> > <[e-mail]> wrote:
> >
> >> Hi,
> >>
> >> As I understand, there is confusion around two DetNet terms.
> >> We are removing "transport".
> >>
> >> The other one is "congestion" and "congestion protection".
> >>
> >> Brief description of congestion protection in Section 3.1:
> >>
> >>     Congestion protection operates by allocating resources along the
> >> path
> >>     of a DetNet flow, e.g., buffer space or link bandwidth. Congestion
> >>     protection greatly reduces, or even eliminates entirely, packet loss
> >>     due to output packet congestion within the network, but it can only
> >>     be supplied to a DetNet flow that is limited at the source to a
> >>     maximum packet size and transmission rate.  Note that congestion
> >>     protection provided via congestion detection and notification is
> >>     explicitly excluded from consideration in DetNet, as it serves a
> >>     different set of applications.
> >>
> >>     Congestion protection addresses two of the DetNet QoS requirements:
> >>     latency and packet loss.  Given that DetNet nodes have a finite
> >>     amount of buffer space, congestion protection necessarily results in
> >>     a maximum end-to-end latency.  It also addresses the largest
> >>     contribution to packet loss, which is buffer congestion.
> >>
> >> Detailed description is in Section 3.2.1.
> >>
> >> We wanted to have a brief collective term for the mechanisms used to
> >> avoid queuing related packet loss (including buffer overflow etc.).
> >>
> >> Based on the discussions, we should have a term that does not include
> >> "congestion".
> >> ("Service Protection" is another DetNet term, hence we may consider a
> >> term without "protection" to minimize confusion.)
> >>
> >> I suggest to replace "congestion protection" with "queuing loss
> >> avoidance".
> >>
> >> After agreeing in the terminology cahnge (if any), the text has to be
> >> updated accordingly.
> >>
> >> What do you think?
> >>
> >> Best regards,
> >> Janos
> >>
> >>
> >> On 11/20/2018 1:11 PM, Lou Berger wrote:
> >>> Michael,
> >>>
> >>> I think we're getting somewhere and identifying where we have
> >>> disconnects and what may (and what may not) need to change in the
> >>> document.  My takeaways are:
> >>>
> >>> - The document needs a good 'scrub' of the congestion related
> >>> references to ensure that the document only makes statements on
> what
> >>> is actually done within a DetNet and the relationship with transport
> >>> protocols that use detnet (which are in fact outside the scope of the
> >>> DetNet WG).  I'll work with the authors and WG on this -- I see this
> >>> change as important, but editorial in nature.
> >>>
> >>> - We have a perception issue with at least one member of the TSV area
> >>> on the meaning and more importantly, implication, of the term "DetNet
> >>> *Transport* sub-layer".  While I don't disagree that a good portion of
> >>> the IETF thinks transport protocol (UDP/TCP) when they hear
> >>> "transport" there are plenty others, particularly in the routing area,
> >>> who understand that "transport" can refer to Transport Networks.  And
> >>> Transport Network is a well understood general industry term. The IETF
> >>> even has a bunch of RFCs that relate to Transport networks. This
> >>> said, I think it reasonable to go back to the DetNet WG and discuss
> >>> changing the name of the "DetNet Transport sub-layer"  to avoid the
> >>> word "transport".  -- BTW we made a parallel change in the TEAS WG
> >>> when producing RFC8453.
> >>>
> >>> See below for detail response in-line.
> >>>
> >>> On 11/19/2018 5:15 PM, Scharf, Michael wrote:
> >>>> Lou,
> >>>>
> >>>>> --
> >>>>> I wanted to take a step back from the multiple discussions that were
> >>>>> spawned by your review -- from a doc shepherd perspective, and see
> >>>>> where
> >>>>> we are.   I know that the authors have sent a -09 version that
> >>>>> addresses
> >>>>> some, but not all issues.
> >>>>>
> >>>>>   From the exchanges I've seen, I think the key remaining issues are
> >>>>> related to:
> >>>>>
> >>>>> (a) possibly introduction of congestion in the general internet if
> >>>>> packets were somehow to escape a detnet domain.  The source of
> this
> >>>>> congestion would be inelastic traffic using DetNet or due to
> >>>>> congestion
> >>>>> loss that is masked by PREOF.
> >>>> These are two major issues that need to be addressed. Note that it
> >>>> may not be sufficient just to add a section on operational and
> >>>> deployment considerations. Also the existing text in the document
> >>>> will need to get aligned to normative guidance on how to avoid a
> >>>> congestion collapse.
> >>>>
> >>>> In -09, one example would be Section 3.1. "Primary goals defining the
> >>>> DetNet QoS"
> >>>>
> >>>>     Congestion protection operates by allocating resources along the
> >>>> path
> >>>>     of a DetNet flow, e.g., buffer space or link bandwidth. Congestion
> >>>>     protection greatly reduces, or even eliminates entirely, packet
> >>>> loss
> >>>>     due to output packet congestion within the network, but it can
> >>>> only
> >>>>     be supplied to a DetNet flow that is limited at the source to a
> >>>>     maximum packet size and transmission rate.  Note that congestion
> >>>>     protection provided via congestion detection and notification is
> >>>>     explicitly excluded from consideration in DetNet, as it serves a
> >>>>     different set of applications.
> >>>
> >>>> At least the last sentence would contradict a better discussion of
> >>>> congestion in the document. For instance, it could just be removed.
> >>>> In any case, the current wording in the last sentence is not correct,
> >>>> as the IETF term for what is described in the last sentence is
> >>>> "congestion control".
> >>>>
> >>>> Another example would be  Section 3.2.1.1. "Eliminate congestion loss"
> >>>>       The primary means by which DetNet achieves its QoS assurances
> >>>> is to
> >>>>     reduce, or even completely eliminate, congestion within a DetNet
> >>>> node
> >>>>     as a cause of packet loss.  This can be achieved only by the
> >>>>     provision of sufficient buffer storage at each node 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.
> >>>>
> >>>> This section IMHO has to include a discussion of what happens in the
> >>>> (not expected) case that packets get dropped or that ECN marks are
> >>>> received. It is understood that this would not happen in normal
> >>>> operation of a DetNet network, but I believe just considering the
> >>>> error-free operation of a DetNet network is not sufficient for this
> >>>> document. At least for the risk of traffic that may escape from a
> >>>> DetNet network is inherently not sufficient to assume that the DetNet
> >>>> network is always error-free.
> >>>
> >>> I think these are examples of text that needs to be cleanup up and to
> >>> delineate what is done with a DetNet.
> >>>
> >>>
> >>>> As a result, addressing my concerns will most likely require editing
> >>>> several parts of the document.
> >>>>
> >>>> In addition, I'd like to emphasize that my review comment "It is
> >>>> surprising that there is hardly any discussion on network robustness
> >>>> and safety"
> >>>
> >>> I have no idea what you mean by safety here.  Can you elaborate.
> >>>
> >>>
> >>>> covers more than just inelastic traffic that escapes from a DetNet
> >>>> network and masking of packet loss. Given that DetNet traffic may be
> >>>> extremely critical traffic, I really wonder why the document doesn't
> >>>> emphasize more the required robustness against failures *inside* the
> >>>> DetNet network as well as counter-measures. But this is something the
> >>>> WG needs to decide. As TSV-ART reviewer, I will be fine if the
> >>>> document clearly describes how the impact of failures will be
> >>>> isolated inside the DetNet network and will not put the general
> >>>> Internet at risk.
> >>>
> >>> I agree - I think, the document should be clear on it's scope and
> >>> relationship to general internet usage.
> >>>
> >>>
> >>>>
> >>>>> (b) The use of the term 'transport' in DetNet to refer to what is
> >>>>> basically a Traffic Engineered sub-network layer, such as is provided
> >>>>> with MPLS-TE or Optical Transport Networks.
> >>>> In the Internet architecture, the term 'transport' refers to Internet
> >>>> transport protocols. I doubt that the document can avoid discussing
> >>>> the implications of and interactions with Internet transport
> >>>> protocols such as UDP or TCP. As a result, I disagree that the
> >>>> document can use the term 'transport' to refer to traffic engineered
> >>>> sub-network layers.
> >>>
> >>> I think this is covered by my comment above.
> >>>
> >>>
> >>>>  From a TSV-ART point of view, the document can either only use the
> >>>> term "transport" for Internet transport protocols and use another
> >>>> term for sub-network layers (as handled in the *routing* area of the
> >>>> IETF), or the document has to clearly distinguish between the
> >>>> Internet transport layer and other uses of the term "transport" and
> >>>> explain the overlap. I believe the former would be less confusing,
> >>>> but I will leave it up to the TSV ADs to discuss terminology overlap
> >>>> in the IESG. As TSV-ART reviewer I insist that the document uses the
> >>>> terms "transport layer" and "transport protocol" only when referring
> >>>> to the Internet transport layer.
> >>>
> >>> I'm personally okay with a name change and even willing to push this
> >>> discussion within the WG, but as said above, "Transport Network" is a
> >>> generally understood industry term that is also used in RFCs -- so
> >>> we'll have to see what where WG consensus ends up.
> >>>
> >>>>
> >>>>> Do you have any other issues that that are critical to be addressed
> >>>>> before this work moves forward?  If so which?
> >>>> Regarding Section 4.4 I have already deferred the discussion to the
> >>>> IESG. The TSV-ART review comment is that the IESG needs to carefully
> >>>> look at the concepts, terminology, and references in section 4.4.
> >>>>
> >>>> Regarding my other comments, I acknowledge that -09 is a step
> >>>> forward. But given the cross-dependencies e.g. regarding terminology
> >>>> and definitions, I will need to read the text completely once there
> >>>> is a proposal how to address my review. As noted in my review, I
> >>>> believe the document must use terminology clearly and consistently.
> >>>> As example, a statement in -09 such as "Network nodes supporting
> >>>> DetNet flows have to implement some of the DetNet capabilities (not
> >>>> necessarily all) in order to treat DetNet flows such that their QoS
> >>>> requirements are met" is IMHO too vague. But in such cases it depends
> >>>> whether there is precise normative guidance elsewhere. And this
> >>>> requires looking at the text as a whole.
> >>>
> >>> I think the next steps lie with me and the WG.  We'll let you know
> >>> once there is a new version.  Of course, you can also contribute to
> >>> the WG discussion on the topic.
> >>>
> >>> Thanks,
> >>>
> >>> Lou
> >>>
> >>>>
> >>>> Best regards
> >>>>
> >>>> Michael
> >>>>
> >>>>
> >>>>
> >>>>> Thank you,
> >>>>>
> >>>>> Lou
> >>>>>
> >>>>> On 9/28/2018 6:24 PM, Michael Scharf wrote:
> >>>>>> Reviewer: Michael Scharf
> >>>>>> Review result: Ready with Issues
> >>>>>>
> >>>>>> The document "Deterministic Networking Architecture"
> >>>>>> (draft-ietf-detnet-architecture-08) defines an overall framework for
> >>>>>> Deterministic Networking.
> >>>>>>
> >>>>>> As TSV-ART reviewer, I believe that this document has issues as
> >>>>> detailed below.
> >>>>>> Michael
> >>>>>>
> >>>>>> Major issues:
> >>>>>>
> >>>>>> * It seems that DetNet cannot easily be deployed in the Internet
> >>>>> without
> >>>>>> additional means. Thus, for a baseline document, one could expect
> >>>>> some
> >>>>>> explanation on the requirements of deploying DetNet in a network.
> >>>>> DetNet
> >>>>>> basically requires support in (almost) all network devices
> >>>>> transporting DetNet
> >>>>>> traffic. That assumption should be explicitly spelt out early in the
> >>>>> document,
> >>>>>> e.g., in the introduction. There also needs to be an explicit
> >>>>> discussion of the
> >>>>>> implications if not the whole network is aware of or supports
> >>>>>> DetNet.
> >>>>> There is
> >>>>>> some text in Section 4.2.2 and Section 4.3.3, but I believe
> >>>>> additional explicit
> >>>>>> discussion is needed at a prominant place. For instance, can use of
> >>>>> DetNet do
> >>>>>> harm to parts of a network not supporting DetNet? As a side note,
> >>>>> when TCPM
> >>>>>> published RFC 8257, the following disclaimer was added: "DCTCP, as
> >>>>> described in
> >>>>>> this specification, is applicable to deployments in controlled
> >>>>> environments
> >>>>>> like data centers, but it must not be deployed over the public
> >>>>> Internet without
> >>>>>> additional measures." I wonder if a similar disclaimer is needed for
> >>>>> DetNet. If
> >>>>>> there is an implicit assumption that DetNet will  be used in
> >>>>> homogenous
> >>>>>> environments with mostly DetNet-aware devices within the same
> >>>>> organization,
> >>>>>> such an assumption should be made explicit.
> >>>>>>
> >>>>>> * It is surprising that there is hardly any discussion on network
> >>>>> robustness
> >>>>>> and safety; this probably also relates to security. For instance,
> >>>>>> misconfiguration or errors of functions performing packet
> >>>>>> replication
> >>>>> could
> >>>>>> severely and permantly congest a network and cause harm. How
> does
> >>>>>> the
> >>>>> DetNet
> >>>>>> architecture ensure that a network stays fully operational e.g. if
> >>>>> the topology
> >>>>>> changes or there are equipment failures? Probably this can be
> solved
> >>>>> by
> >>>>>> implementations (e.g., dynamic control plane), but why are
> >>>>> corresponding
> >>>>>> requirements not spelt out? Section 3.3.2 speculates that filters
> >>>>>> and
> >>>>> policers
> >>>>>> can help, and that may be true, but that probably still assumes
> >>>>> consistently
> >>>>>> and correctly configured (and well-behaving) devices. And Section
> >>>>> 3.3.2 is
> >>>>>> vague and mentions a "infinite variety of possible failures" without
> >>>>> stating
> >>>>>> any requirements or recommendations. There may be further
> solutions,
> >>>>> such as
> >>>>>> circuit breakers and the like. Why are such topics not discussed?
> >>>>>>
> >>>>>> * Somewhat related, the document only looks at impact of failures
> to
> >>>>> the QoS of
> >>>>>> DetNet traffic. What is missing is a discussion how to protect non-
> >>>>> DetNet parts
> >>>>>> of a network from any harm caused by DetNet mechanisms.
> Solutions to
> >>>>> this
> >>>>>> probably exist. But why is the impact on non-DetNet traffic
> >>>>>> (e.g., in
> >>>>> case of
> >>>>>> topology changes or failures of DetNet functions) not discussed at
> >>>>> all in the
> >>>>>> document?
> >>>>>>
> >>>>>> * Regarding security, an architecture like DetNet probably requires
> >>>>> that only
> >>>>>> authenticated and authorized end systems have access to the data
> >>>>> plane. The
> >>>>>> security considerations only briefly mention the control aspect
> >>>>>> ("the
> >>>>>> authentication and authorization of the controlling systems").
> >>>>>>
> >>>>>> * For an architecture document, the lack of clarity and consistency
> >>>>> regarding
> >>>>>> terminology is concerning. This specifically applies to the case of
> >>>>> incomplete
> >>>>>> networks (as per Section 4.2.2 and 4.3.3) that include "DetNet-
> >>>>> unaware nodes".
> >>>>>> The document introduces terms such as "DetNet intermediate
> nodes"
> >>>>>> but
> >>>>> then
> >>>>>> repeatedly uses generic terms such as "node" or "hop" that may
> >>>>> include
> >>>>>> DetNet-unaware nodes. For instance, for incomplete networks, a
> >>>>> sentence such as
> >>>>>> "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"
> >>>>>> seems to only apply to "DetNet transit nodes" but not
> >>>>>> "DetNet-unaware
> >>>>> nodes".
> >>>>>> Similar ambiguity exist for other use of the terms "hop" and "node",
> >>>>> which may
> >>>>>> or may not include DetNet-unaware nodes. It is unclear why the
> >>>>> document does
> >>>>>> not consistently use the terminology introduced in Section 2.1 in
> >>>>>> all
> >>>>> sections
> >>>>>> and clearly distinguishes cases with and without DetNet support.
> >>>>>>
> >>>>>> * Section 4.4 refers to RFC 7426, which is an informational RFC on
> >>>>> IRTF stream,
> >>>>>> and the document uses the concepts introduced there (e.g.,
> >>>>>> "planes").
> >>>>> This is
> >>>>>> very confusing. First, an IETF Proposed Standard should probably
> >>>>> refer to
> >>>>>> documents having IETF consensus. An example would be RFC 7491,
> >>>>>> albeit
> >>>>> there is
> >>>>>> other related work as well, e.g., in the TEAS WG. Second, Section
> >>>>>> 4.4
> >>>>> is by and
> >>>>>> large decoupled from the rest of the document and not specific to
> >>>>> DetNet.
> >>>>>> Neither do other sections of the document refer to the concepts
> >>>>> introduced in
> >>>>>> Section 4.4, nor does Section 4.4 use the DetNet terminology or
> >>>>> discuss
> >>>>>> applicability to DetNet. Section 4.4 even mentions explicitly at the
> >>>>> end that
> >>>>>> it discusses aspects that are orthogonal to the DetNet architecture.
> >>>>> It is not
> >>>>>> at all clear why Section 4.4 is in this document. Section 4.4 could
> >>>>> be removed
> >>>>>> from the document without impacting the rest of the document.
> >>>>>>
> >>>>>> Minor issues:
> >>>>>>
> >>>>>> * Terminology "DetNet transport layer"
> >>>>>>
> >>>>>>     The term "transport layer" has a well-defined meaning in the
> >>>>>> IETF,
> >>>>> e.g.
> >>>>>>     originating from RFC 1122. While "transport" and e.g. "transport
> >>>>> network" is
> >>>>>>     used in the IETF for different technologies in different
> >>>>>> areas, I
> >>>>> think the
> >>>>>>     term "transport layer" is typically understood to refer to
> >>>>> transport
> >>>>>>     protocols such as TCP and UDP. As such, I personally find the
> >>>>>> term
> >>>>> "DetNet
> >>>>>>     transport layer" misleading and confusing. The confusion is easy
> >>>>> to see e.g.
> >>>>>>     in Figure 4, where UDP (which is a transport protocol as per RFC
> >>>>> 1122) sits
> >>>>>>     on top of "transport".
> >>>>>>
> >>>>>>     Based on the document it also may be solution/implementation
> >>>>> specific whether
> >>>>>>     the "DetNet transport layer" is actually a separate protocol
> >>>>>> layer
> >>>>> compared
> >>>>>>     to the "DetNet service layer". Thus it is not clear to me why
> >>>>>> the
> >>>>> word
> >>>>>>     "layer" has to be used, specifically in combination "transport
> >>>>> layer".
> >>>>>>     To me as, the word "transport layer" (and "transport protocol")
> >>>>> should be
> >>>>>>     used for protocols defined in TSV area, consistent with RFC
> >>>>>> 1122.
> >>>>> But this is
> >>>>>>     probably a question to be sorted out by the IESG.
> >>>>>>
> >>>>>> * Page 9
> >>>>>>
> >>>>>>      A DetNet node may have other resources requiring allocation
> >>>>> and/or
> >>>>>>      scheduling,
> >>>>>>
> >>>>>>     This is just one of several examples for inconsistent use of
> >>>>> terminology.
> >>>>>>     What is a "DetNet node"? That term is not introduced in Section
> >>>>> 2.1
> >>>>>> * Page 14
> >>>>>>
> >>>>>>      A DetNet network supports the dedication of a high proportion
> >>>>> (e.g.
> >>>>>>      75%) of the network bandwidth to DetNet flows.
> >>>>>>
> >>>>>>     The 75% value is not reasoned. What prevents using 99% of the
> >>>>> bandwidth for
> >>>>>>     DetNet traffic?
> >>>>>>
> >>>>>> * Page 15: Figure 2
> >>>>>>
> >>>>>>     If the term "transport layer" cannot be avoided, the labels in
> >>>>> this figure
> >>>>>>     should at least be expanded to "DetNet transport layer".
> >>>>>>
> >>>>>> * Page 18: Figure 4
> >>>>>>
> >>>>>>     As already mentioned earlier, Figure 4 is confusing. UDP is a
> >>>>> transport
> >>>>>>     protocol. If the term "transport" cannot be avoided, the
> >>>>>> labels in
> >>>>> this
> >>>>>>     figure should at least be expanded to "DetNet transport".
> >>>>>>
> >>>>>> * Page 23
> >>>>>>
> >>>>>>      If the source transmits less data than this limit
> >>>>>>      allows, the unused resource such as link bandwidth can be made
> >>>>>>      available by the system to non-DetNet packets.
> >>>>>>
> >>>>>>     Could there be additional requirements on the use of unused
> >>>>> resources by
> >>>>>>     non-DetNet packets, e.g., regarding preemption? I am just
> >>>>> wondering... If
> >>>>>>     that was possible, a statement like "... can be made
> >>>>>> available by
> >>>>> the system
> >>>>>>     to non-DetNet packets as long as all guarantees are fulfilled"
> >>>>> would be on
> >>>>>>     the safe side, no?
> >>>>>>
> >>>>>> * Page 27:
> >>>>>>
> >>>>>>      DetNet achieves congestion protection and bounded delivery
> >>>>> latency by
> >>>>>>      reserving bandwidth and buffer resources at every hop along the
> >>>>> path
> >>>>>>      of the DetNet flow.
> >>>>>>
> >>>>>>     Why does this sentence use the word "hop"? As far as I
> >>>>>> understand,
> >>>>> in DetNet
> >>>>>>     bandwidth and buffer resources are reserved in each DetNet
> >>>>> intermediate node.
> >>>>>>     If there were hops over IP routers not being DetNet intermediate
> >>>>> nodes, no
> >>>>>>     resources would be reserved there. As per Section 4.3.3, it is
> >>>>> possible to
> >>>>>>     deploy DetNet this way. And obviously there can be resource
> >>>>> bottlenecks below
> >>>>>>     IP, on devices that are not routers... So does "hop" here
> >>>>>> refer to
> >>>>> IP router
> >>>>>>     hops or also to devices not processing IP (or IP/MPLS)?
> >>>>>>
> >>>>>> * Page 27:
> >>>>>>
> >>>>>>      Standard queuing and transmission selection algorithms allow a
> >>>>>>      central controller to compute the latency contribution of each
> >>>>>>      transit node to the end-to-end latency, ...
> >>>>>>
> >>>>>>     The text does not explain why a _central_ controller is
> >>>>>> needed for
> >>>>> this
> >>>>>>     computation. Why would a distributed control plane not be
> >>>>>> able to
> >>>>> realize
> >>>>>>     this computation. Isn't this implementation-specific?
> >>>>>>
> >>>>>> * Page 32
> >>>>>>
> >>>>>>     To somebody who is not deeply familiar with DetNet, it is
> >>>>> impossible to parse
> >>>>>>     the description of the examples in Section 4.7.3. For instance,
> >>>>> "VID +
> >>>>>>     multicast MAC address" is not introduced. I think this example
> >>>>> must be
> >>>>>>     expaned with additional context and explanation to be useful to
> >>>>> readers.
> >>>>>> * Page 34
> >>>>>>
> >>>>>>      There are three classes of information that a central
> >>>>>> controller
> >>>>> or
> >>>>>>      distributed control plane needs to know that can only be
> >>>>>> obtained
> >>>>>>      from the end systems and/or nodes in the network.
> >>>>>>
> >>>>>>     Wouldn't it be sufficient to state "Provisioning of DetNet
> >>>>> requires knowledge
> >>>>>>     about ...". Does it matter in this context whether the
> >>>>> provisioning is done
> >>>>>>     by a central controller or a distributed control plane? For
> >>>>> instance, could
> >>>>>>     the same paragraph also apply to a network that uses _multiple_
> >>>>> central
> >>>>>>     controllers, or hybrid combinations of central controllers and
> >>>>> distributed
> >>>>>>     control planes? In general, an architecture document should be
> >>>>> agnostic to
> >>>>>>     implementation aspects unless there is a specific need. In this
> >>>>> specific
> >>>>>>     case, I fail to see a need to discuss the realization of the
> >>>>> control plane of
> >>>>>>     a network.
> >>>>>>
> >>>>>> Editorial nits:
> >>>>>>
> >>>>>> * Page 9:
> >>>>>>
> >>>>>>      The low-level mechanisms described in Section 4.5 provide the
> >>>>>>      necessary regulation of transmissions by an end system or
> >>>>>>      intermediate node to provide congestion protection. The
> >>>>> allocation
> >>>>>>      of the bandwidth and buffers for a DetNet flow requires
> >>>>> provisioning
> >>>>>>      A DetNet node may have other resources requiring allocation
> >>>>> and/or
> >>>>>>      scheduling, that might otherwise be over-subscribed and trigger
> >>>>> the
> >>>>>>      rejection of a reservation.
> >>>>>>
> >>>>>>     Probably a full stop is missing after "provisioning".
> >>>>>>
> >>>>>> * Page 11: "... along separate (disjoint non-SRLG) paths ..."
> >>>>>>
> >>>>>>     I find this confusing. I would understand e.g. "along separate
> >>>>>>     (SRLG-disjoint) paths".
> >>>>>>
> >>>>>> * Page 34:
> >>>>>>
> >>>>>>      When using a peer-
> >>>>>>      to-peer control plane, some of this information may be required
> >>>>> by a
> >>>>>>      system's neighbors in the network.
> >>>>>>
> >>>>>>     Would "acquired" be a better term?
> >>>>>>
> >>>>>> * Page 34:
> >>>>>>
> >>>>>>      o  The identity of the system's neighbors, and the
> >>>>> characteristics of
> >>>>>>         the link(s) between the systems, including the length (in
> >>>>>>         nanoseconds) of the link(s).
> >>>>>>
> >>>>>>     "Latency" or "delay" would probably be a better terms if the
> >>>>>> value
> >>>>> is
> >>>>>>     measured in nanoseconds.
> >>>>>>
> >>>>>> * Page 35:
> >>>>>>
> >>>>>>      DetNet is provides a Quality of Service (QoS), and as such,
> >>>>>> does
> >>>>> not
> >>>>>>      directly raise any new privacy considerations.
> >>>>>>
> >>>>>>     Broken sentence
> >>>>>>
> >>>>>> * Please expand acronyms on first use (e.g., OTN)
> >>>>>>
> >>>>>>
> >>>> _______________________________________________
> >>>> detnet mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/detnet
> >>
> >> _______________________________________________
> >> detnet mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/detnet
> >
> >
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet