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

[Toerless Eckert <[e-mail]>]

RFC8655 makes claims that can still not be substantiated with actual specification
work from DetNet: There is no PREOF for IPv4/IPv4. AFAIK, there is no IETF PHB
specification for any of the possible bounded latency options that _could_ be inherited
from e.g.: TSN.  The only bounded latency RFC2212 is not even referenced in either
RFC8655 nor this subject draft. 

If this draft intends to repeat unsubstantiated marketing claims then it should be fair
game to criticize them. Especially because its completely irrelevant what "DetNet"
at large may or may not do. The relevant facts are those that apply to the content
of the document.

"DetNet provides" should be reserved to actual work from DetNet. I do not see any 
spec work from DetNet for bounded latency / no congestion loss. See above. If 
"DetNet can be used in conjunction with <third-party/TSN-IntServ-work>", thats fine,
but thats not what is written. I think that is false advertisement.

A lot of people who d not understand the technology are going to read the RFCs
and think DetNet is magically solving problems that it is not. Because of these
sentences. 

I proposed better text that hopefully technically correct describes what
the MPLS data plane achieves. I have seen no comment about that proposed text.
I think technical accuracy and truth in advertisement in not too much to ask.

Cheers
    Toerless

On Wed, Sep 09, 2020 at 05:24:27PM +0000, Bal?zs Varga A wrote:
> Hi All,
> Many thanks for the suggestions.
> I will update the draft to match rfc8655.
> Cheers
> Bala'zs
> 
> -----Original Message-----
> From: Loa Andersson <[e-mail]> 
> Sent: Wednesday, September 9, 2020 6:10 PM
> To: Stewart Bryant <[e-mail]>; Lou Berger <[e-mail]>
> Cc: Magnus Westerlund <[e-mail]>; [e-mail]; Toerless Eckert <[e-mail]>; Balázs Varga A <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS)
> 
> All,
> 
> While I won't cry if this is dropped, I'm a little bit more than a bit concerned that every time we try to state what we can expect of a DetNet service we seem to stumble on the finish line.
> 
> If it works for MPLS and is updated to match RFC 8655, I'd say we leave it in.
> 
> /Loa
> 
> On 09/09/2020 23:59, Stewart Bryant wrote:
> > I think it has to be dropped, because as the work stands I cannot see that we have a way of bounding the latency.
> > 
> > I know that we are talking about MPLS, but of course we need to look at all of the data plane drafts in this respect.
> > 
> > - Stewart
> > 
> > 
> > 
> >> On 9 Sep 2020, at 16:39, Lou Berger <[e-mail]> 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].
> >>
> >> 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.
> >>
> >> 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]
> > 
> > _______________________________________________
> > detnet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/detnet
> > 
> 
> -- 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Bronze Dragon Consulting             phone: [phone]

-- 
---
[e-mail]