Re: [ippm] New Version Notification for draft-mhmcsfh-ippm-pam-03.txt

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

Hello Peter,

thank you for your feedback and your interest in this work!

Please find my responses inline, <ALEX>

--- Alex (as coauthor)

On 11/24/2022 7:01 AM, Peter Thompson wrote:
> Dear Greg at el,
>
> I think this a very interesting direction of work and I support the idea of creating metrics for service availability. I have some questions:
>
> 1) Definition of a ’service’
>
> There is an implicit identification of a ’service’ with a particular flow of packets. However, if we think of, e.g., a bearer service, this is a *capability* to deliver packets regardless of whether any packets are currently flowing. It seems odd to record a service as ‘available’ only when it is being actively used! Also, a higher-level service may have units of information exchange that are not individual packets, and the notion of whether it is ‘available’ may go beyond whether packets are being exchanged with sufficient reliability.

<ALEX>I guess the question is, if there is a service and noone uses it, 
would anyone notice the difference?

Violated Intervals are currently defined a intervals during which at 
least one of the performance parameters degraded below its pre-defined 
threshold objective.  You are correct that this could be defined to 
include time intervals during which the capability to provide the 
service per the objective would be compromised. (Or this could even be 
defined as a separate metric - violated interval vs capability-violated 
interval or such.)  One question would be how to actually measure / 
observe this, and how it would be used.  From a practical perspective, I 
am not sure if this would actually be useful, hence this was indeed 
defined with actual degradation (versus "potential degradation if it 
were to be used" in mind.  However, it is certainly debatable to include 
also the sheer capability; are there some specific scenarios that you 
are thinking of for which you believe this should be included?

</ALEX>

>
> 2) Flow being measured
>
> When we speak of a ‘violated packet’ are we thinking of measuring *all* packets in a flow or just a subset (e.g. a co-incident stream of test packets)? Using a test packet stream has advantages:
> - Packets can include transmission times and sequence numbers, making measurement of delay and loss much easier
> - measurements continue even when there is no active service flow

<ALEX> The draft here focuses just on the metrics themselves.  How to 
conduct measurements is something that is good to have in the back of 
the mind but this question is outside the scope of the draft.  As for 
active vs passive measurements, the usual tradeoffs apply.  For the 
important category of precision accounting use cases, what is of 
importance is the actual precision availability of the services actually 
delivered.  Test packets won't cut it there and the metrics will need to 
be maintained for actual production traffic.  Where high-precision 
services (with stringent requirements) are involved, accuracy will be 
very important, i.e. relying on sampling of extrapolating from test 
traffic will not be sufficient.  (Active measurements might of course be 
used to test for the availability of the sheer capability, per your 
earlier point.)

</ALEX>

>
> 3) Service availability transition
>
> A service is moved to the ‘unavailable’ state if ten consecutive SVIs are detected - shouldn’t this number be a configurable parameter? Could it be N of M in a rolling window? (If only every tenth interval was unviolated this ’10 consecutive’ test would fail but the service wouldn’t be very good!)

<ALEX> I am sure that this point will receive further discussion.  You 
are correct that anything involving thresholds is potentially 
subjective, subject to policy, preferences, configuration.   Personally, 
I consider this a somewhat "secondary" consideration, but one that 
deserves to be included in the discussion.  One tradeoff to consider is 
that the need for such configuration introduces a certain degree of 
complexity, and raises secondary considerations (for example, how to 
know which configuration parameters were actually in effect when a 
certain state was reached or how a change in configuration should affect 
an existing state that was reached per the configuration that had been 
in effect earlier).  All these things can be defined but at the same 
should not be distracting to the primary purpose of the draft.

</ALEX>

>
> Peter Thompson, Chief Technical Officer Predictable Network Solutions Ltd., +44 (0)333.340.7713 • Twitter: @PNSolLtd
>
> PS this is my first post to this list, so I apologise in advance for any infelicities of format or etiquette!
>
>
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm