Re: [PMOL] [ippm] Soliciting comments on GMPLS performance metrics draft in CCAMP

[Al Morton <acmorton at att.com>]

At 04:44 AM 5/29/2008, Weiqiang Sun wrote:

> The authors would now like to
> solicit comments among the performance metric experts, as this document
> contains notations that are commonly seen in IPPM and BMWG. The authors
> believe that your expertise can help us further improve this document,
> with regard to the definition of the metrics and the structure as well.
> Please send your comments directly to the authors, or, to the CCAMP
> working group mail list
> (ccamp at ops.ietf.org). We do
> appreciate your input.

As I've said in the past, this draft is an excellent start,
and because it adopts the metric template used in bmwg and ippm,
it's an easy read. Thanks for doing that part.

more below,
Al

General comments:
-----------------
There is a taxonomy of possible outcomes for set-up protocols.
Each set-up attempt will have one of the following outcomes:

1. Success
2. Failure
3. Incorrect Set-up (wrong destination)

The same basic outcomes apply to release attempts.

In the current text, the set-up time metrics cover the 
Successful outcome (they could be called Successful *.* Setup
Time).

When a setup attempt fails, the setup time is Undefined. Stop there.
Please remove the "informally infinite" phrase between 
parentheses, because it places the failure outcome on the
same dimension as success. As I've pointed out above, 
the 3 outcomes are mutually exclusive.  I know this text came 
from IPPM RFCs, but this is a case where you should not follow
that precedent, IMHO.  For more nit-picking background, read
http://tools.ietf.org/id/draft-morton-ippm-reporting-metrics-05.txt

Back to the Failure Outcome.  I can imagine that there will
be
technologies for which a metric on Setup Failure Ratio may be 
more important than the Successful setup time - I may not care
if the setup takes 1 second or 10 seconds, but the 50% failure
ratio is annoying...

So, I propose to add metrics to cover the Failure outcome,
defined as a count of failures=Undefined setup times divided by the
total attempts. This would be a single outcome for a singleton
metric and a ratio for metrics with multiple LSP setups.
(I saw the metric in 12.4, it doesn't quite have the right wording
or emphasis - this metric should be a part of all setup and release
scenarios).

Adding metrics to cover the Incorrect setup/release outcome
would complete the taxonomy.  I can accept that the Incorrect
outcome may be quite rare in practice, but having the metric 
defined and ready is a reasonable use of resources. You can
note that these outcomes may be rare in some technologies as 
part of the discussion.

Specific Comments:
------------------
(You can generalize these to all applicable sections)

3.3  Metric Parameters

  o  ID0, the ingress LSR ID

  o  ID1, the egress LSR ID

You should use these ID#s in the definition of the metric.

  o  T, a time

I've found that the two word description of a parameter is 
not always sufficient for me.  I suggest:

  o  T, a time when the setup is attempted

I suggest to add a parameter, for clarity:

  o  WAITTIME, the maximum waiting time for successful
setup

and mention this parameter in the sections where discussed, 
like 3.5 and 3.6.

----------

13. Discussion

The control-plane-only nature of these metrics should be clear(er)
in the Introduction/Scope.

Question:
How important is it to have data-plane verification of the 
apparent control-plane success/failure/incorrect performance?








_______________________________________________
PMOL mailing list
PMOL at ietf.org
https://www.ietf.org/mailman/listinfo/pmol