Re: [Detnet] Congestion Protection name change

["Pascal Thubert (pthubert)" <[e-mail]>]

Management looks like control plane, Lou, don’t you think?
David’s flow protection also indicates the interesting security properties that we are effectively bringing in...


Regards,

Pascal

> Le 11 déc. 2018 à 15:45, Lou Berger <[e-mail]> a écrit :
> 
> Balázs,
> 
> In some systems that work on  more than just queue management is needed, so I personally feel pretty strongly that we should not include the word queue. How about:
> 
> 'flow management'
> 
> Lou
> 
> 
> 
> ----------
>> On December 11, 2018 2:21:19 AM Balázs Varga A <[e-mail]> wrote:
>> 
>> Hi,
>> 
>> "queuing loss avoidance".
>> 
>> I am partly with You. I think the to include the term "flow" is a good idea.
>> David has right, here we are focusing on flows.
>> 
>> However I have problems with the "protection" part of the term, due to other
>> terminology we have already defined, namely service protection (e.g., PREOF).
>> I think for many people "DetNet" + "protection" = "PREOF".
>> 
>> As Janos wrote:
>>> We wanted to have a brief collective term for the mechanisms used
>>> to avoid queuing related packet loss (including buffer overflow etc.).
>> and Pascal extended:
>> - and at the same time we want to fulfill the latency requirement of the flow.
>> 
>> So, let's lists the functions we intend to describe with the term:
>> - selecting queuing method used and the queue used by the flow
>> - properly configuring queue parameters (e.g., egress speed, queue size, etc.),
>> based on latency and (zero) loss requirements for the flow/hop
>> 
>> A possible way to put all these pieces together:
>> "flow queuing regulation " or "flow queuing management"
>> 
>> Any thoughts?
>> 
>> Cheers
>> Bala'zs
>> 
>> -----Original Message-----
>> From: Pascal Thubert (pthubert) <[e-mail]>
>> Sent: Tuesday, December 11, 2018 5:21 AM
>> To: Black, David <[e-mail]>; Janos Farkas <[e-mail]>; Lou Berger <[e-mail]>
>> Cc: [e-mail]; [e-mail]
>> Subject: RE: [Detnet] Congestion Protection name change
>> 
>> "Flow Protection" looks good to me too...
>> 
>>> -----Original Message-----
>>> From: Black, David <[e-mail]>
>>> Sent: mardi 11 décembre 2018 05:40
>>> To: János Farkas <[e-mail]>; Lou Berger
>>> <[e-mail]>
>>> Cc: [e-mail]; [e-mail]
>>> Subject: RE: [Detnet] Congestion Protection name change
>>> 
>>> > >>     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
>> _______________________________________________
>> detnet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/detnet
> 
>