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

From: Al Morton <[email-masked]>
Date: Thu, 05 Jun 2008 15:21:14 -0400

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
([email-masked]). 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?

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