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

[Magnus Westerlund <[e-mail]>]

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]
----------------------------------------------------------------------