Re: [Detnet] Congestion Protection name change

[Lou Berger <[e-mail]>]

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