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

[Balázs Varga A <[e-mail]>]

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. 

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]