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

[Magnus Westerlund <[e-mail]>]

On Tue, 2020-09-08 at 17:21 +0100, Stewart Bryant wrote:
> 
> 
> > On 8 Sep 2020, at 16:09, Magnus Westerlund via Datatracker <[e-mail]
> > > wrote:
> > 
> > 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.
> 
> The text seems to line up well with the work that we did on pseudowire
> sequence numbers and we have had no reports from implementors or operators
> that we need to increase the text and provide implementation guidance.
> 
> I am always worried about overprescribing the operation of such systems since
> it is easy to rule out legitimate implementation optimisations, or
> inadvertently prevent the use of the technology in some way that we have not
> yet considered but which would be valid.

So, I think any issues would only really show up when your close to the
boundaries of how many packets are in flight. And with current technolghy and
link rates the 28-bit sequence number supports rates for DETNET flows into the
terrabit range if I calcualted correctly unless the path is very long (>>100
ms). The 16-bit field has much more restriction and could be pushed into
wrapping on the time scales packets has some chance of later showing up. Likely
the application are not pushing that amount of bits, but I want to bet on that.
This might be used in particla physic or simiarl field which produces stupendous
amount of data that needs to be processed in order. 

> 
> I would argue that the buffer sizing, constraints and management is more
> properly a discussion between the vendor and the operator.

The issue I see here from an interoperability stand point is if the
configuration option for example buffer depth needs to be set differently due to
how the buffering and processing is done for different vendor. That is not great
for interoperbility or ease of management for the operator. 

> 
> On latency we are not in this design providing precision latency management,
> just best effort mitigation of the natural latency of the network. This may
> change if we introduce queue management or other services, but I do not think
> we are there yet, and suspect that once we get to latency management we will
> need more metadata in the packet.

I think this comes back to the previous email. The document is not properly
expressing the limitation in what actual properties it can ensure. And when it
comes to latency the theoretical boundaries appears to be much worse than what
the practical ones likely are for the wast majority. 
 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------