Subject: Re: [ippm] some questions on draft-ietf-ippm-ioam-data-04

From: "Ramesh Sivakolundu (sramesh)" <[email-masked]>
Date: Tue, 4 Dec 2018 18:43:53 +0000

The intent behind these two parameters is to get the percentage usage or actual usage in units defined by the devices in the network. The size of queue and buffer is dependent upon the implementation of the device and those details are left up to the device and the collector of the telemetry data to share. One approach is to use a YANG model to describe the device details to the collector out of band.

-Ramesh

On 12/3/18, 6:03 PM, "ippm on behalf of Tianran Zhou" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Authors,
    
    I am reading this draft and feel some queue related description is not clear to me.
    
    1. queue depth:  4-octet unsigned integer field.  This field indicates
          the current length of the egress interface queue of the interface
          from where the packet is forwarded out.  The queue depth is
          expressed as the current number of memory buffers used by the
          queue (a packet may consume one or more memory buffers, depending
          on its size).
    
    The size of memory buffer varies from different chips. Typical chips use 512 bytes for one memory buffer, but some other chip use 256, or so.
    So for one packet, it may consume different number of memory buffers in different devices. I am afraid this will impact the analytics application, since it do not know what this number really means for the congestion/queue utilization.
    
    To some extent, do you think the total queue length/occupancy ratio worth recording? So that the analytics application know the occupation rate. But this is also hard, because many chips use shared buffer, that means each queue does not have a fixed length.
    
    2. buffer occupancy:  4-octet unsigned integer field.  This field
          indicates the current status of the buffer occupancy.  The buffer
          occupancy is expressed as the current number of memory buffers
          used by the set of queues that share a common buffer pool.
    
    Could you explain how to use this data? What's the use case that make this data field valuable?
    
    Thanks,
    Tianran
    
    _______________________________________________
    ippm mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/ippm

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 5 Dec 2018 02:04:31 +0000

Hi Ramesh,

Thank you very much for your reply.
Please see inline.

Cheers,
Tianran

> -----Original Message-----
> From: Ramesh Sivakolundu (sramesh) [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2018 2:44 AM
> To: Tianran Zhou <[email-masked]>; [email-masked]; Frank Brockners
> (fbrockne) <[email-masked]>; Shwetha Bhandari (shwethab)
> <[email-masked]>
> Cc: Zengyanfang <[email-masked]>
> Subject: Re: [ippm] some questions on draft-ietf-ippm-ioam-data-04
> 
> The intent behind these two parameters is to get the percentage usage or actual
> usage in units defined by the devices in the network. 

This is still not clear to me. When we propose a TLV in one protocol, we always provide use cases to show how useful it is. With these two parameters, do you also have use cases?

> The size of queue and
> buffer is dependent upon the implementation of the device and those details
> are left up to the device and the collector of the telemetry data to share.
> One approach is to use a YANG model to describe the device details to the
> collector out of band.

This is fine to me, but this will make the application/system complex.

> -Ramesh
> 
> 
> On 12/3/18, 6:03 PM, "ippm on behalf of Tianran Zhou" <[email-masked]
> on behalf of [email-masked]> wrote:
> 
>     Hi Authors,
> 
>     The size of memory buffer varies from different chips. Typical chips use
> 512 bytes for one memory buffer, but some other chip use 256, or so.
>     So for one packet, it may consume different number of memory buffers in
> different devices. I am afraid this will impact the analytics application,
> since it do not know what this number really means for the congestion/queue
> utilization.
> 
>     To some extent, do you think the total queue length/occupancy ratio worth
> recording? So that the analytics application know the occupation rate. But
> this is also hard, because many chips use shared buffer, that means each queue
> does not have a fixed length.
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 4 Dec 2018 18:50:15 -0800

Hi Ramesh,
you've said that both or one of these parameters may be used to convey
percentage of buffers in use by the queue. Is my understanding of your
explanation is correct? If that is right, how integer can effectively
represent percentage? What accuracy of such use you expect?

Regards,
Greg

On Tue, Dec 4, 2018, 10:44 Ramesh Sivakolundu (sramesh) <[email-masked]
wrote:

> The intent behind these two parameters is to get the percentage usage or
> actual usage in units defined by the devices in the network. The size of
> queue and buffer is dependent upon the implementation of the device and
> those details are left up to the device and the collector of the telemetry
> data to share. One approach is to use a YANG model to describe the device
> details to the collector out of band.
>
> -Ramesh
>
>
> On 12/3/18, 6:03 PM, "ippm on behalf of Tianran Zhou" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Hi Authors,
>
>     The size of memory buffer varies from different chips. Typical chips
> use 512 bytes for one memory buffer, but some other chip use 256, or so.
>     So for one packet, it may consume different number of memory buffers
> in different devices. I am afraid this will impact the analytics
> application, since it do not know what this number really means for the
> congestion/queue utilization.
>
>     To some extent, do you think the total queue length/occupancy ratio
> worth recording? So that the analytics application know the occupation
> rate. But this is also hard, because many chips use shared buffer, that
> means each queue does not have a fixed length.
>

---

From: "Ramesh Sivakolundu (sramesh)" <[email-masked]>
Date: Wed, 5 Dec 2018 18:34:02 +0000

Hi Greg,

With 32 bits of data, the semantics can be defined as 8-bits of queue or buffer ID and 24 bits of occupancy value. With 24 bits, you can get a decent accuracy.

-Ramesh

From: Greg Mirsky <[email-masked]>
Date: Tuesday, December 4, 2018 at 6:50 PM
To: "Ramesh Sivakolundu (sramesh)" <[email-masked]>
Cc: Tianran Zhou <[email-masked]>, IETF IPPM WG <[email-masked]>, "Frank Brockners (fbrockne)" <[email-masked]>, "Shwetha Bhandari (shwethab)" <[email-masked]>, Zengyanfang <[email-masked]>
Subject: Re: [ippm] some questions on draft-ietf-ippm-ioam-data-04

Hi Ramesh,
you've said that both or one of these parameters may be used to convey percentage of buffers in use by the queue. Is my understanding of your explanation is correct? If that is right, how integer can effectively represent percentage? What accuracy of such use you expect?

Regards,
Greg

On Tue, Dec 4, 2018, 10:44 Ramesh Sivakolundu (sramesh) <[email-masked]<mailto:[email-masked]> wrote:
The intent behind these two parameters is to get the percentage usage or actual usage in units defined by the devices in the network. The size of queue and buffer is dependent upon the implementation of the device and those details are left up to the device and the collector of the telemetry data to share. One approach is to use a YANG model to describe the device details to the collector out of band.

-Ramesh

On 12/3/18, 6:03 PM, "ippm on behalf of Tianran Zhou" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Hi Authors,

    Thanks,
    Tianran

    _______________________________________________
    ippm mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: "Ramesh Sivakolundu (sramesh)" <[email-masked]>
Date: Wed, 5 Dec 2018 18:34:59 +0000

I concur. Use case needs to be added to the draft document.

-Ramesh

On 12/4/18, 6:04 PM, "Tianran Zhou" <[email-masked]> wrote:

    Hi Ramesh,

    Cheers,
    Tianran

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 7 Dec 2018 01:11:42 +0000

Thanks. Look forward to the update.

Cheers,
Tianran
> Sent: Thursday, December 06, 2018 2:35 AM
>     This is still not clear to me. When we propose a TLV in one protocol,
> we always provide use cases to show how useful it is. With these two parameters,
> do you also have use cases?
> 
>     > The size of queue and
>     >     I am reading this draft and feel some queue related description
> is not
>     > clear to me.
>     >
> in
> worth
>     >     Could you explain how to use this data? What's the use case that
> make
>     > this data field valuable?
>     >
>     >     Thanks,
>     >     Tianran
>     >