[Cats] Re: draft-ietf-cats-metric-definition-13 early Perfmetrdir review

[韦举重 <[e-mail]>]

Hi Kehan,


Thanks for your work on this draft. I have two clarification questions regarding the pre-negotiated aggregation and normalization functions for Level 1 and Level 2 metrics in Section 7.1.


First, is this pre-negotiated set intended to be one single set shared for all services, or will a separate set of aggregation and normalization functions be negotiated per individual service?


Second, who is responsible for coordinating and performing this negotiation in practice?


Could you please clarify these points and add the explanations to the draft?


Best regards,
Juzhong Wei













 
------------------ Original ------------------
From: &nbsp;"Kehan&nbsp;Yao"<[e-mail]&gt;;
Date: &nbsp;Wed, Oct 21, 2026 00:53 AM
To: &nbsp;"Giuseppe Fioccola"<[e-mail]&gt;; 
Cc: &nbsp;"[e-mail]"<[e-mail]&gt;; "cats"<[e-mail]&gt;; "[e-mail]"<[e-mail]&gt;; 
Subject: &nbsp;[Cats] Re: draft-ietf-cats-metric-definition-13 early Perfmetrdir review

&nbsp;

Hi Giuseppe,

Thanks for your careful review. I've just uploaded a revision of the document to address your comments.&nbsp;
To summarize:
* I've added RFC7799 to refer to different measurement methods.&nbsp;
*&nbsp;A new "Measurement Method" field has been added.
*&nbsp;RFC 5644 has been added for reference.
* A thorough revision of the metric registry entries and their corresponding measurement methods in section 6 according to your suggestions.&nbsp;
* I've also added some examples to show how to apply normalization functions and aggregation functions in the appendix B.&nbsp;


Please see the attached links to make sure if there are any further issues.&nbsp;

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-cats-metric-definition/

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-cats-metric-definition-14&nbsp;&nbsp;&nbsp;



Best regards,Kehan



Giuseppe Fioccola <[e-mail]&gt; 于2026年10月17日周六 00:33写道：

   
Hi Kehan,
 
Thank you for considering my suggestions.
 
Please see inline [GF]
 
&nbsp;
 
Regards,
 
&nbsp;
 
Giuseppe
 
&nbsp;
  
From: Kehan Yao <[e-mail]&gt; 
 Sent: Thursday, October 15, 2026 7:23 AM
 To: Giuseppe Fioccola <[e-mail]&gt;
 Cc: [e-mail]; [e-mail]; [e-mail]
 Subject: Re: [Cats] draft-ietf-cats-metric-definition-13 early Perfmetrdir review
 
 
&nbsp;
   
Hi Giuseppe,
 
 Thank you very much for your valuable review from the PERFMETRDIR point of view. Your suggestions are extremely constructive and point out the critical aspects required to improve the clarity of our document. Please see my reply inline below.
 
 Best regards,
 
  
Kehan
 
 
&nbsp;
   
Giuseppe Fioccola via Datatracker <[e-mail]&gt; 于2026年10月15日周四 01:44写道：
 
  
Document: draft-ietf-cats-metric-definition
 Title: CATS Metrics Definition
 Reviewer: Giuseppe Fioccola
 Review result: Not Ready
 
 This document focuses on compute and communication metrics for Computing-Aware
 Traffic Steering (CATS). It introduces three levels of abstraction: Level 0
 (Raw metrics), Level 1 (Metrics combined into categories), Level 2 (A single
 normalized metric).
 
 &gt;From a PERFMETRDIR point of view, the document does not standardize performance
 metrics but it specifies higher-level representations. However, I think that
 the document is not ready since the description of the metric registry entries
 of section 6 should be improved. Here are some suggestions for your
 consideration:
 
 - Section 3.2 introduces Level 0 Raw Metrics. I would also mention the network
 performance metrics, which are described in RFC 7799.
   
[KY] Sure.&nbsp; Some examples are already listed under level 0 communication metrics, but I will explicitly refer to RFC 7799 in the next revision.&nbsp;
 
&nbsp;
 
[GF]: Ok, good!
 
  
&nbsp;
 
  
- In section 4.1, I would add the metrics type (if the information is
 available), based on the classification of RFC 7799. The distinction between
 active, passive and hybrid metrics can be a relevant property.
   
&nbsp;[KY] We will consider adding a new "Measurement Method" field to reflect the measurement property of the metrics.
 
&nbsp;
 
[GF]: Agree, I think it can be a relevant information to include.
 
  
&nbsp;
 
  
- In section 4.2.1, you could also refer to RFC 5644 in addition to RFC 5835.
   
[KY] Sure. Thanks for introducing this citation. We will add it.&nbsp;
 
&nbsp;
 
[GF]: Ok!
 
  
&nbsp;
 
  
- Section 6 defines the registry entries but I have some concerns about the
 current explanation and more details are needed. The naming rule includes the
 Measurement Method (sections 6.1.3, 6.2.3, 6.3.3, 6.4.3 6.5.3), but it is not
 fully described. For example, it is not clear to me what the term Passive
 refers to, is it based on the definitions of RFC 7799 and RFC 10014?
   
[KY]&nbsp;Although the draft does not explicitly cite RFC 7799, the authors have evaluated the applicability of different measurement methods within the CATS metric framework (referencing RFC 8912).&nbsp;Our initial understanding  of the measurement methods of CATS metrics are as follows:
 
 
• For Level 0 Metrics (Raw Metrics): We believe that all three measurement methods defined in RFC 7799 - Active, Passive, and Hybrid - can coexist depending on how the raw computing or communication metrics are collected.
 • For Level 1 and Level 2 Metrics: Since these metrics are derived and calculated through aggregation or normalization functions, we currently label them as "Passive" in Section 6 registry entries. Our rationale was that the generation of these higher-level  scores is a purely mathematical calculation that does not inject any dedicated active probe packet streams.
  
&nbsp;
 
  
But now, when I double check, I am also exploring an alternative possibility where we extend current performance measurement protocols to embed Level 1 and Level 2 metrics into generated probe packet streams and convey them to CATS components  like the C-PS. This measurement approach would be conceptually similar to the Hybrid Type I method outlined in RFC 7799.
 
 We would highly appreciate your expert view on whether the above interpretation of "Passive" or "Hybrid" aligns well with the PERFMETRDIR consensus, or if we should refine the wording to avoid semantic conflation with RFC 7799’s definitions.
 
&nbsp;
 
[GF]: I think that it would be better to include these definitions in the context of Level 0, Level 1 and Level 2 metrics. In case of Level 0, the classification can be the same as RFC 7799. For Level 1 and Level 2, the property should  be inherited, even if we aggregate the data, but it also depends on the Level 0 metric type. Anyway, I suggest to include the formal definitions of the terminology used in this document, considering that you are introducing new levels of abstraction. This  can help to avoid confusion with the same terms used for performance measurements.
 
  
&nbsp;
 
  
- I would also add additional examples for the metrics. Appendix A only
 includes Level 0 Metric Examples.
   
[KY] Since this document only registers Level 1 and Level 2 metrics, Level 0 metrics are not defined and registered. Level 0 metric examples are shown in the appendix, while the examples of Level 1 and Level 2 metrics are already described  in section 4.&nbsp;&nbsp;
 
&nbsp;
 
[GF]: I meant that the examples in section 4 are a bit abstract, and it would be useful for a reader to have at least an actual example to show how the aggregation and the normalization can be employed with the level 0 metric examples.
 
&nbsp;
 
  

 
 _______________________________________________
 Cats mailing list -- [e-mail]
 To unsubscribe send an email to  [e-mail]