Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS)

[Uma Chunduri <[e-mail]>]

Mostly agree with the suggestion below. One comment in-lie.

--
Uma C.

On Wed, Sep 9, 2020 at 11:13 AM Toerless Eckert <[e-mail]> wrote:

> On Wed, Sep 09, 2020 at 11:39:20AM -0400, Lou Berger wrote:
> > The  doc currently reads (asterisks indicate the sentence under
> discussion):
> >
> >    1.  Introduction
> >
> >    Deterministic Networking (DetNet) is a service that can be offered by
> >    a network to DetNet flows.  *DetNet provides these flows with
> >    extremely low packet loss rates and assured maximum end-to-end
> >    delivery latency.*  General background and concepts of DetNet can be
> >    found in [RFC8655].
>
> Suggest:
>
>      Deterministic Networking (DetNet) is a service that can be offered by
>      a network to DetNet flows.  The DetNet MPLS Data Plane for DetNet
> uses point-to-point
>      LSP to transport DetNet Flows. The DetNet MPLS Data Plane DetNet
> flows with
>      extremely low packet loss rates because of PREOF (see below). The
> DetNet
>      MPLS Data Plane can be combined with pre-existing or future
> Per-Hop-Behavior (PHB)
>      to provide bounded latency and zero congestion loss.
>

[Uma]: The last sentence should be dropped. As that is not possible for
MPLS dataplane (not many TC bits left) without further enhancements in the
packet fields (CW or otherwise).


>
> The bounded jitter is somewhat questionable to claim for the DetNet MPLS
> Data Plane from this document: I don't know if for example IntServ/GS or
> TSN/ATS would claim to provide bounded jitter: Their jitter is between
> physcial
> propagation latency and maximum guaranteed latency... Thats kinda "free"
> jitter
> without any additional work. Mechanisms that provide further constraints
> on jitter
> such as some of the TSN options or the proposed cyclic queuing (Large Scale
> Deterministic Networking) would require additional packet header fields to
> work,
> which are not provided by this DetNet MPLS Data Plane.
> .. maybe i am overlooking something here.
>
> > The sentence in question was copied from the draft version of RFC8655,
> which
> > now reads slightly differently:
> >
> >    ... which provides a capability for the delivery of
> >    data flows with extremely low packet loss rates and bounded end-to-
> >    end delivery latency.
> >
> > I suggest either (a) updating the draft to match the RFC text or (b)
> > dropping it altogether and let the reference to RFC8655 stand alone.
>
> The architecture is aspirational and to a good extend vague and makes
> claims
> not substantiated by spec today. The bar to repeat such claims in an actual
> protocol spec like subject one should be somewhat higher.
>
> Cheers
>     Toerless
>
> > Lou
> >
> > On 9/9/2020 11:20 AM, Toerless Eckert wrote:
> > > On Wed, Sep 09, 2020 at 01:50:34PM +0000, Bal?zs Varga A wrote:
> > > > Hi Toerless,
> > > >
> > > > Many thanks for the comments. One remark:
> > > > - I disagree with your statement "DetNet like any other IP/MPLS
> network with per-flow forwarding provides"
> > > > Just as an example, PREOF functions are not available in current
> MPLS networks.
> > > PREOF is not subject of the sentence part in question. My concern is
> only about:
> > >
> > > ... DetNet provides zero congestion loss and bounded latency and jitter
> > >
> > > Of course, now you mention it: The MPLS forwarding plane of this spec
> does
> > > support PEROF, but the sentence only talks about "DetNet", for which at
> > > large in my assesment this is not true (no current PREOF for IPv4/IPv6
> AFAIK).
> > >
> > > Aka: also for the part of PREOF its better to re-scope the sentence to
> talk only
> > > the MPLS forwarding plane of this document instead of (unnecessarily?)
> make
> > > claims about DetNet at large.
> > >
> > > Cheers
> > >      Toerless
> > >
> > > > Thanks
> > > > Bala'zs
> > > >
> > > > -----Original Message-----
> > > > From: Toerless Eckert <[e-mail]>
> > > > Sent: Tuesday, September 8, 2020 9:13 PM
> > > > To: Magnus Westerlund <[e-mail]>
> > > > Cc: The IESG <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> > > > Subject: Re: [Detnet] Magnus Westerlund's Discuss on
> draft-ietf-detnet-mpls-11: (with DISCUSS)
> > > >
> > > > Thanks Magnus, *:
> > > >
> > > > Related to your comments, i would like to raise a concern about the
> initial sentence in the spec:
> > > >
> > > > ...DetNet provides zero congestion loss and bounded latency and
> jitter.
> > > >
> > > > To me, this is overselling what DetNet actually "provides" or that
> uniquely distinguishes DetNet from other solutions. It sounds as if DetNet
> provides a novel solution whereas in reality it just allows to adopt
> existing or new solutions.
> > > >
> > > > With the definitions DetNet has done today, any IP or MPLS network
> where end-to-end flows can be identified as e.g.: an IP 5-tuple or an LSP
> identifier and that manages to figure out how to implement or
> operationalize one of the solutions for bounded latency such as a PHB in
> support of rfc2212.
> > > >
> > > > Aka: one could equally write:
> > > >
> > > > ...DetNet like any other IP/MPLS network with per-flow forwarding
> provides zero congestion loss and bounded latency and jitter.
> > > >
> > > > Which would be equally true and equally misleading.
> > > >
> > > > So, here is proposed IMHO more technically correct text to replace
> the IMHO misleading "marketing" sentence segment:
> > > >
> > > > ...DetNet MPLS sets up point-to-point LSPs end-to-end across DetNet
> domains.
> > > >
> > > > Because of this, DetNet MPLS can integrate with pre-existing and/or
> future Per-Hop-Behavior
> > > > (PHB) (such one derived from RFC2212) that can provide per-flow
> (e.g.: LSP) bounded latency, bounded jitter and no congestion loss, as long
> as such a PHB does not require additional network packet header information
> beside the flow/LSP identification.
> > > >
> > > > Cheers
> > > >      Toerless
> > > >
> > > > On Tue, Sep 08, 2020 at 08:09:21AM -0700, Magnus Westerlund via
> Datatracker wrote:
> > > > > Magnus Westerlund has entered the following ballot position for
> > > > > draft-ietf-detnet-mpls-11: Discuss
> > > > >
> > > > > When responding, please keep the subject line intact and reply to
> all
> > > > > email addresses included in the To and CC lines. (Feel free to cut
> > > > > this introductory paragraph, however.)
> > > > >
> > > > >
> > > > > Please refer to
> > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > > for more information about IESG DISCUSS and COMMENT positions.
> > > > >
> > > > >
> > > > > The document, along with other ballot positions, can be found here:
> > > > > https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls/
> > > > >
> > > > >
> > > > >
> > > > >
> ----------------------------------------------------------------------
> > > > > DISCUSS:
> > > > >
> ----------------------------------------------------------------------
> > > > >
> > > > > I like to thank the TSV-ART reviewer for helping me consider one
> > > > > aspect of the issue I see needing some discussion for this
> document.
> > > > >
> > > > > This relates to Section 4.2.2.2. and 4.2.2.3.
> > > > >
> > > > > So both of these section discuss the use of the sequence number for
> > > > > removing packet duplicates and handling reorder. As the text
> discusses
> > > > > there can be a configured limit for how deep the buffer and state
> are
> > > > > for performing these operations. We all know that the
> implementation
> > > > > of this will have a practical limit in both buffer space for
> > > > > reordering as well as state for tracking which sequence numbers
> that
> > > > > have been forwarded. I think that should be more clearly expressed
> in
> > > > > the document that these practical limits exists. Thus, the
> > > > > implementations will have tracking and determination of what are
> new packets (increasing sequence number within a window higher than
> previous largest seen.
> > > > > And consider sequence number form currently highest seen and a bit
> > > > > backwards as older packets. Thus how this is implemented will
> impact
> > > > > how this acts in cases of disruptions of the packet flow. Thus, I
> > > > > wonder if there is actually need to be  a bit more specific in how
> > > > > classification should be done. Especially if the wrap-around of the
> > > > > sequence number space approaches a small multiple of round trip
> times for the path which is likely for the 16-bit space.
> > > > >
> > > > > Then  sections fails to discuss how the duplication removal, the
> > > > > reordering buffering and bound latency interacts and affet each
> other.
> > > > > So if the latency is bounded then the reordering has an hard time
> > > > > limit for the maximum delay. If there is a boundary for reordering
> > > > > then there are no point in de-duplicating packets that will not be
> > > > > forwarded due to the reordering. And even if there are no bounded
> > > > > latency the reordering buffer size will still impact the depth of
> > > > > de-duplication. These practical limits will also be limitations on
> the guarantees that can be provided.
> > > > >
> > > > > Thus, from my perspective there is need for more text on the
> > > > > requirements of the implementation of these functions and their
> > > > > interactions of creating limitations.
> > > > >
> > > > > Another point on 4.2.2.2:
> > > > >
> > > > > When configured, the
> > > > >     implementation MUST track the sequence number contained in
> received
> > > > >     d-CWs and MUST ensure that duplicate (replicated) instances of
> a
> > > > >     particular sequence number are discarded.
> > > > >
> > > > > That second MUST I think is possible to meet given that one discard
> > > > > all packets outside of the current window where one have
> information
> > > > > if a packet sequence number have been forwarded or not. Given that
> a
> > > > > very late packet beyond the amount of state for the flow likely
> anyway
> > > > > have little utility that is likely the right choice. However, I
> think
> > > > > it needs to be made explicit that this is okay.
> > > > >
> > > > > In Section 4.2.2.3:
> > > > >
> > > > >   When configured, the
> > > > >     implementation MUST track the sequence number contained in
> received
> > > > >     d-CWs and MUST ensure that packets are processed in the order
> > > > >     indicated in the received d-CW sequence number field, which
> may not
> > > > >     be in the order the packets are received.
> > > > >
> > > > > I think this part needs to be explicit that packets that are to
> fare
> > > > > out of order for the implementation to handle will/shall be
> dropped.
> > > > >
> > > > >     Note that an implementation MAY wish to constrain the maximum
> number
> > > > >     of out of order packets that can be processed, on
> platform-wide or
> > > > >     per flow basis.  Some implementations MAY support the
> provisioning of
> > > > >     this number on either a platform-wide or per flow basis.  The
> number
> > > > >     of out of order packets that can be processed also impacts the
> > > > >     latency of a flow.
> > > > >
> > > > > If there exists a latency requirement then that will interact with
> > > > > this when it comes to reordering. In fact a significant issue here
> is
> > > > > that if the packet flow is not periodic at a steady pace the
> maximum
> > > > > latency in the reordering buffers based on packet sequence numbers
> can
> > > > > not be ensured. Instead some form of time limit needs to exist
> also.
> > > > > If that time limit is only local then there exists a risk that over
> > > > > multiple reordering buffers if multiple independent service labels
> are
> > > > > used the jitter and latency becomes cumulative. If the goal is to
> > > > > avoid this then the individual packets would need to carry a time
> > > > > stamp to ensure that from ingress of the service label path until
> the egress a maximum latency is added.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > detnet mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/detnet
> > > > --
> > > > ---
> > > > [e-mail]
>
> --
> ---
> [e-mail]
>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet
>