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

[Toerless Eckert <[e-mail]>]

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. 

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]