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:12 +0100, Stewart Bryant wrote:
> 
> 
> > On 8 Sep 2020, at 16:09, Magnus Westerlund via Datatracker <[e-mail]
> > > wrote:
> > 
> > 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.
> 
> It seems to me that this is getting into the realms of in-time and on-time
> delivery which is outside the scope  of this work. Indeed it is quite a
> significant increase in the technology to address that which needs to be
> thought through very carefully rather than added on the fly.

I think a potential solution here without specifying things to much is to at
least make clear that there are no support for the timeliness aspect in this
version. As currently specified if you are using reordering buffer you have no
way of providing a bounded delay unless you have knowledge of the minimal packet
transmission rate and that following some particular schedule so that you can
calculate what worst case latency may be incurred. You likely have statistical
better boundaries, but to my understanding there are no mechanism in this
document that can ensure bounded delay on packets that are not lost. 

> 
> At this stage we should accept that the design mitigates the loss
> characteristics of the network and leave the more advanced work such as in
> network latency management to future work.

I have no problem with this, I just think the document needs to come straight
with its actual capabilities. 

Cheers

Magnus Westerlund 


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