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

[Magnus Westerlund <[e-mail]>]

Hi,

Okay, will clear my discuss based on the proposed changes. This is based on that
you will want these functions as black boxes that are implementation dependent.
However, the new text do inidcate the bare minimal requirements on the control
plane to achieve the service. So I think the working group will have some work
to do to figure out what knobs or information elements you need in the control
plane to make this work so that bound delay also when the traffic flow operates
at packet rates and bandwidths below the maximum according to any traffic
specification. 

Please consider if you need to adjust the abstract and introduction to correctly
represent what is provided. 

Cheers

Magnus

On Mon, 2020-09-14 at 13:38 +0000, Balázs Varga A wrote:
> Hi,
> 
> DetNet networks need strong control of network resources. The MPLS 
> data plane draft specifies the DetNet specific encapsulation and the 
> role of DetNet functions (e.g., PREOF for the DetNet service 
> sub-layer). There can be multiple implementation variants of PEF and 
> POF functions, based on various algorithms, however, they are 
> out-of-scope of in this document.
>   
> In order to address the raised concerns the following change is 
> proposed. Text to be added to the end of “4.2.2.3.  Packet Ordering 
> Function Processing”:
> --- NEW TEXT
>        DetNet uses flow-specific requirements (e.g., maximum
>        number of out-of-order packets, maximum latency of the flow) for
>        configuration of POF-related buffers.  POF implementation details
>        are out-of-scope in this document. POF configuration parameters
>        – determined by the controller plane – are implementation specific.
>        In case a PEF is combined with POF, then their configurations need 
>        to be coordinated to ensure the combined functionality.
> 
> Cheers
> Bala'zs
> 
> -----Original Message-----
> From: Lou Berger <[e-mail]> 
> Sent: Thursday, September 10, 2020 7:15 PM
> To: Magnus Westerlund <[e-mail]>; Janos Farkas <
> [e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> ; [e-mail]; [e-mail]
> Subject: Re: Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-11: (with
> DISCUSS)
> 
> Magnus,
> 
> I agree that minimum sized frames are needed as well.  Please see the text I
> proposed in my last message and note that the reference traffic specification
> (RFC2212) includes a minimum policed unit (m), and the maximum   datagram size
> (M).
> 
> Lou
> 
> On 9/10/2020 11:31 AM, Magnus Westerlund wrote:
> > On Thu, 2020-09-10 at 13:26 +0000, Janos Farkas wrote:
> > > Hi Magnus,
> > > 
> > > I think we have the very same goal: make DetNet work; avoid any bugs.
> > > 
> > > I may be wrong, but as far as I know, multiple methods could be used 
> > > for buffer dimensioning, e.g.: bytes, number of packets, time; and if 
> > > a good job is done, then one can be converted to another.
> > > 
> > > I think we can make DetNet work if the POF buffer size is given in 
> > > number of packets if we do a good job with the traffic specification.
> > > The flow information model draft (
> > > https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-
> > > 10#section-5.5
> > > ) provides the following:
> > > 
> > >     TrafficSpecification has the following attributes:
> > > 
> > >     a.  Interval: the period of time in which the traffic specification
> > >         is specified.
> > > 
> > >     b.  MaxPacketsPerInterval: the maximum number of packets that the
> > >         Ingress will transmit in one Interval.
> > > 
> > >     c.  MaxPayloadSize: the maximum payload size that the Ingress will
> > >         transmit.
> > > 
> > > 
> > > Thus, my interpretation of your point is that the 
> > > TrafficSpecification is not good enough to make the conversion between
> > > time and number of packets.
> > 
> > Exactly, this specification is good when one like ensure capability 
> > can handle the traffic by specifying the maxmimum kind of resource the flow
> > will consume.
> > But it doesn't work for calculate a bounded delay as by lowering the 
> > number of packets per second actually sent, the actual latency 
> > increases in the POF if it is configured only on number of packets. To 
> > bound latency based on number of packets, in that case you have to 
> > enforce that the flow have a minimal packet interval.
> > 
> > > My preference is to leave number of packets for POF int the MPLS data 
> > > plane draft and make it sure that the TrafficSpecification provides 
> > > all the parameters needed for engineering to convert between number 
> > > of packets and time.
> > 
> > So the number of packets is a relevant aspect, but as the dataplane 
> > draft states it is the combination of time and packets that bounds the POF
> > function.
> > 
> > I have no opinion if the TrafficSpecification is the right place to 
> > put this configuration boundary. It is really not a traffic flow 
> > property, it is more a configuration of the network from my 
> > perspecitive. And given a bound latency requirement from the Detnet 
> > flow the POF buffer depth may be different depending on what path through
> > the MPLS network one uses.
> > 
> > > Please let us know if we have overlooked anything with regards to the 
> > > TrafficSpecification and such conversion is not possible. If there is 
> > > any issue with the TrafficSpecification, then I think we should fix it.
> > > 
> > 
> > To be clear i don't want to tell the WG how to do its work. I have 
> > noted what I consider a serious short comming, one that I think needs 
> > to be solved. I am happy to discuss it and the proposed way forward.
> > 
> > 
> > Cheers
> > 
> > Magnus Westerlund
> > 
> > 
> > ----------------------------------------------------------------------
> > Networks, Ericsson Research
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  [phone]
> > Torshamnsgatan 23           | Mobile [phone]
> > SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> > ----------------------------------------------------------------------
> > 
> > 
-- 
Cheers

Magnus Westerlund 


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