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

[Lou Berger <[e-mail]>]

Magnus,

I agree with Janos here, I think this should be addressed in the traffic 
specification.  This said, I think it completely reasonable to add a 
statement in this document to that effect so this interaction isn't 
missed by the implementer.

How about adding the following to the end of the last paragraph in 
section 4.2.2.3:

    The latency impact on the system resources needed to support a
    specific DetNet flow will need to be evaluated by the controller plane
    based on that flow's traffic specification.  An example traffic 
specification
    that can be used with MPLS with Traffic Engineering (MPLS-TE) can be
    found in [RFC2212].

Does this address your concern?

Lou

On 9/10/2020 9:26 AM, 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.
>
> 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.
>
> 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.
>
> Regards,
> Janos
>
>
>
> -----Original Message-----
> From: Magnus Westerlund <[e-mail]>
> Sent: Thursday, September 10, 2020 10:19 AM
> To: 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)
>
> On Wed, 2020-09-09 at 20:34 +0000, Janos Farkas wrote:
>> Hi Magnus,
>>
>> I think the parameter you are looking for is there in section
>> 4.2.2.3. Packet Ordering Function Processing (
>> https://tools.ietf.org/id/draft-ietf-detnet-mpls-11.html#pof-requireme
>> nts), just encoded a different way; in particular in the number of
>> packets:
>> “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.”
>>
>> Ultimately, the latency requirements of flows have to be met. The
>> maximum packet size of a DetNet flow is known, see item c)
>> MaxPayloadSize in
>> https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-1
>> 0#section-5.5
>>   and max-payload-size in
>> https://tools.ietf.org/html/draft-ietf-detnet-yang-07.
>> So, maximum POF buffer size to be applied for a flow can be
>> determined; can be converted to time and taken into account during
>> latency engineering of a DetNet network; thus bounded latency can be provided.
> So given that the buffer is specified in either bytes or simply packets to be buffered will result in that the POF buffering time becomes packet flow dependent and not bounded in time. So if you make the calculation for a DETNET flow thinking it will send 500 packets per second evenly spaced. Then the a buffer of 5 packets would represent an upper limit 1/100th of second. If then the flow sends only 100 packet per second then suddendly the 5-packet buffering would represent 1/20th of a second. Thus defining it in packets or size doesn't work, the upper buffering time needs to be defined in time to provide a bounded latency.
>
>> I fully agree with you that this needs to be taken into account.
>> Together with what the set of documents that specify DetNet provide, I
>> think it is fine what we have in the MPLS data plane draft. When it
>> comes to configuration - as you pointed out - I think the job we need
>> to do is to pay attention to do it right in the YANG draft, which is still under development.
>  From my perspective I think this document needs to correctly document the requirement to bound in time the POF and having a configuration. The actual detail of the configuration is fine to leave to another document.
>
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>