Re: [Detnet] Congestion Protection name change

["qiangli (D)" <[e-mail]>]

I am afraid flow-grained operations will face with scalability problem, and flow-protection may limit some tunnel like or other possible solutions. How about using "DetNet packet loss control layer" to replace current " service sub-layer", similarly using "DetNet delay control layer" to replace current "transport sub-layer"? Just a suggestion ;-)

Best regards,

Cristina QIANG

-----Original Message-----
From: detnet [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, December 11, 2018 12:21 PM
To: Black, David <[e-mail]>; János 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