Re: [ippm] Roman Danyliw's No Objection on draft-ietf-ippm-pam-08: (with COMMENT)

[Alexander L Clemm <[e-mail]>]

Hi,

Roman, thank you for your questions and suggestions; Greg, thank you for 
for your responses.

I actually disagree with one of the resolutions, as explained inline, 
<ALEX>.  Specifically, I believe that the original text in 3.1 should be 
reinstated as the new one is not only not quite correct but would 
introduce additional issues.

Thanks

--- Alex

On 11/17/2023 12:56 AM, Greg Mirsky wrote:
> Hi Roman,
> thank you for your questions and suggestions. Please find my notes 
> in-lined below tagged GIM>>. Attached, please find the new working 
> version (Gmail believes that diff contains a virus ;(. )
>
> Regards,
> Greg
>
> On Thu, Nov 16, 2023 at 12:08 PM Roman Danyliw via Datatracker 
> <[e-mail]> wrote:
>
>     Roman Danyliw has entered the following ballot position for
>     draft-ietf-ippm-pam-08: No Objection
>
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut
>     this
>     introductory paragraph, however.)
>
>
>     Please refer to
>     https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>
>     for more information about how to handle DISCUSS and COMMENT
>     positions.
>
>
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-ippm-pam/
>
>
>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>     ** Section 3.1.  Consider defining or providing an explanation of
>     “optimal
>     level threshold” and “critical threshold” in the definitions of VI
>     and SVI.
>     I’m assuming that these are two configured threshold levels.
>
> GIM>> You are right. We planned that both thresholds are configured, 
> i.e., pre-defined, as noted in the document. Both reflect what can be 
> described as "an acceptable deviation from an ideal performance 
> metric". The optimal level may be used by a service provider to detect 
> performance degradation, while the critical level reflects the 
> requirements of the service customer. Would adding the following 
> sentence make it clearer:
> OLD TEXT:
>    The monitoring of performance parameters to determine the quality of
>    an interval is performed between the elements of the network that are
>    referred to for the SLO corresponding to the performance parameter.
>    Mechanisms of setting levels of a threshold of an SLO are outside the
>    scope of this document.
> NEW TEXT:
>    The monitoring of performance parameters to determine the quality of
>    an interval is performed between the elements of the network that are
>    referred to for the SLO corresponding to the performance parameter.
>    The optimal level threshold may be used by a service provider to
>    detect performance degradation, while the critical level threshold
>    reflects the requirements of the service customer.  Mechanisms of
>    setting levels of a threshold of an SLO are outside the scope of this
>    document.

<ALEX> Actually, I do not agree with this change.  In particular, I 
would take issue with the term "optimal level threshold".  What 
constitutes a Violated Interval is determined by the SLO.  It is the 
service level objective that, when breached, will cause a corresponding 
interval to be violated.

Now, SVI has a notion of higher severity - and what constitutes that is 
again up to the network provider to define.  But there is no notion of 
optimality.  (Nor is there, in fact, a notion of criticality - it's SVI, 
not CVI.)

I therefore find the new text to be misleading and believe the original 
text should be reinstated.  If we believe that additional clarification 
is needed, we could add another sentence that indicates that the 
configuration of a threshold which, when breached during an interval, 
will cause a violation to be registered for that interface, is 
determined per the definition of the SLO and configured accordingly.

</ALEX>

>
>     ** Section 3.1.
>        Beyond accounting for violated intervals, it is sometimes
>     beneficial
>        to maintain counts of packets for which a performance threshold is
>        violated.
>
>     No question of the utility of counting packets. However, shouldn’t
>     there be a
>     count of flows too?  Section 1 said “This specification introduces
>     a new set of
>     metrics, Precision Availability Metrics (PAM), aimed at capturing
>     end-to-end
>     service levels for a flow, specifically the degree to which flows
>     comply with
>     the SLOs that are in effect.”
>
> GIM>> Thank you for the question and highlighted text. PAM is intended 
> to characterize a single flow, and it seems to me that the use of 
> plural is confusing. I propose the update as follows:
> OLD TEXT:
>    This specification introduces a new set of metrics, Precision
>    Availability Metrics (PAM), aimed at capturing end-to-end service
>    levels for a flow, specifically the degree to which flows comply with
>    the SLOs that are in effect.
> NEW TEXT:
>    This specification introduces a new set of metrics, Precision
>    Availability Metrics (PAM), aimed at capturing end-to-end service
>    levels for a flow, specifically the degree to which the flow complies
>    with the SLOs that are in effect.
> I hope that this update clarifies the scope of PAM.
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm