Subject: [xrblock] Fwd: [ippm] Performance Metrics Registry: new draft

From: Benoit Claise <[email-masked]>
Date: Wed, 17 Jul 2013 10:58:20 +0200

Dear all,

You're feedback is welcome regarding this draft.

Regards, Benoit

-------- Original Message --------
Subject: 	[ippm] Performance Metrics Registry: new draft
Date: 	Mon, 15 Jul 2013 18:10:48 +0200
From: 	Benoit Claise <[email-masked]>
To: 	IETF IPPM WG <[email-masked]>

Dear all,

Let me introduce
http://datatracker.ietf.org/doc/draft-claise-ippm-perf-metric-registry/
This draft creates of a new IANA registry, for performance metrics that
follows the RFC6390 template.
And, let's not forget that the IPPM charter mentions: "Metric
definitions will follow the template given in RFC 6390."

Thanks Brian for giving me 10 min to present this draft.

Regards, Benoit.

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

---

From: Qin Wu <[email-masked]>
Date: Mon, 22 Jul 2013 09:50:10 +0000

Hi, Benoit:
I think it is useful to provide such performance metrics registry. In most cases, we uses the metrics defined somewhere rather than defining new metrics.
Unfortunately not everyone who writes the PM related draft knows the distinction between using metrics and defining metrics.
Three comments I have:
a. Is performance metrics registry provided for the metrics defined within IETF or metrics defined somewhere else in other SDO?
If the metrics are defined in other SDO, IETF will not provide registry, am I right?
b. Is performance metrics registry provided for the existing metrics defined in IETF existing RFCs or any other new metrics defined in the new IETF RFCs or any drafts that are in RFC Queue?
If you define performance metrics registry for the existing ones? How do you identify them when RFC6390 template hasn't been applied to them?
c. what procedure should I follow if I identify additional set of permanence metrics beyond that is given in the section 4? It is not clear in the draft.

Regards!
-Qin
From: [email-masked] [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Wednesday, July 17, 2013 4:58 PM
To: [email-masked]
Subject: [xrblock] Fwd: [ippm] Performance Metrics Registry: new draft

Dear all,

Regards, Benoit

-------- Original Message --------
Subject:

[ippm] Performance Metrics Registry: new draft

Date:

Mon, 15 Jul 2013 18:10:48 +0200

From:

Benoit Claise <[email-masked]><mailto:[email-masked]>

To:

IETF IPPM WG <[email-masked]><mailto:[email-masked]>

Dear all,

Let me introduce

Regards, Benoit.

ippm mailing list

[email-masked]<mailto:[email-masked]>

---

From: Varun Singh <[email-masked]>
Date: Tue, 23 Jul 2013 02:54:36 +0300

Hi,

This is more of comment on the Metric names listed in Section 4.1

Should the metric names listed in the registry be unique or not?

"Threshold in RTP" appears twice.

In this particular case, the first one relates to the threshold Gmin
for bust/gap

loss and the second points to burst/gap discard. Perhaps these metric names

should have Burst/Gap Loss or Burst/Gap Discard appended to the respective

metric names for them to appear unique.

Another example is "Total RTP packets expected in bursts" is this defined twice?

once each in the bust/gap loss and discard documents. Probably one definition

should suffice?

Cheers,

Varun

On Wed, Jul 17, 2013 at 11:58 AM, Benoit Claise <[email-masked]> wrote:

> -------- Original Message --------  Subject: [ippm] Performance Metrics
> Registry: new draft  Date: Mon, 15 Jul 2013 18:10:48 +0200  From: Benoit
> Claise <[email-masked]> <[email-masked]>  To: IETF IPPM WG
> <[email-masked]> <[email-masked]>
>
> Dear all,
>
> Let me introduce http://datatracker.ietf.org/doc/draft-claise-ippm-perf-metric-registry/
> ippm mailing [email-masked]://www.ietf.org/mailman/listinfo/ippm
>
>
>
>
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock
>
>

-- 
http://www.netlab.tkk.fi/~varun/

---

From: Benoit Claise <[email-masked]>
Date: Wed, 31 Jul 2013 09:53:21 +0200

Hi Qin,
>
> Hi, Benoit:
>
> I think it is useful to provide such performance metrics registry. In 
> most cases, we uses the metrics defined somewhere rather than defining 
> new metrics.
>
> Unfortunately not everyone who writes the PM related draft knows the 
> distinction between using metrics and defining metrics.
>
> Three comments I have:
>
> a. Is performance metrics registry provided for the metrics defined 
> within IETF or metrics defined somewhere else in other SDO?
>
Good question: to be discussed.
>
> b. Is performance metrics registry provided for the existing metrics 
> defined in IETF existing RFCs or any other new metrics defined in the 
> new IETF RFCs or any drafts that are in RFC Queue?
>
> If you define performance metrics registry for the existing ones? How 
> do you identify them when RFC6390 template hasn't been applied to them?
>
We will be discussing this point in IPPM today.
Having an IPPM registry will be required.
>
> c. what procedure should I follow if I identify additional set of 
> permanence metrics beyond that is given in the section 4? It is not 
> clear in the draft.
>
What do you propose?

Regards, Benoit
>
> Regards!
>
> -Qin
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Benoit Claise
> *Sent:* Wednesday, July 17, 2013 4:58 PM
> *To:* [email-masked]
> *Subject:* [xrblock] Fwd: [ippm] Performance Metrics Registry: new draft
>
> Dear all,
>
> *Subject: *
> *Date: *
> *From: *
> Benoit Claise <[email-masked]> <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> IETF IPPM WG <[email-masked]> <mailto:[email-masked]>
>
> Dear all,
>   
> Let me introduce
> [email-masked]  <mailto:[email-masked]>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 31 Jul 2013 10:01:51 +0200

Hi Varun,

That's a very good point, and proves the point that a registry is required.
I believe that the names should/must be unique.
See inline

> "Threshold in RTP"appears twice.
> In this particular case, the first one relates to the threshold Gmin for bust/gap
We still have time to change

    Threshold in RTP:
    [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard  <http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry-00#ref-I-D.ietf-xrblock-rtcp-xr-burst-gap-discard>],appendix A  <http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry-00#appendix-A>

Should we initiate an action?
> once each in the bust/gap loss and discard documents. Probably one definition
These two are identical.
We overlooked that during the review (because we didn't have a registry 
to start with)
Is there something we should correct now in 
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard 
<http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry-00#ref-I-D.ietf-xrblock-rtcp-xr-burst-gap-discard>]?

    Total RTP packets expected in bursts:
    [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard  <http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry-00#ref-I-D.ietf-xrblock-rtcp-xr-burst-gap-discard>],appendix A  <http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry-00#appendix-A>

Regards, Benoit

>
> Cheers,
> Varun
>
>
>
>
> On Wed, Jul 17, 2013 at 11:58 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dear all,
>
>     From: 	Benoit Claise <[email-masked]> <mailto:[email-masked]>
>     To: 	IETF IPPM WG <[email-masked]> <mailto:[email-masked]>
>
>
>
>     Dear all,
>
>     Let me introduce
>     [email-masked] <mailto:[email-masked]>
> http://www.netlab.tkk.fi/~varun/ <http://www.netlab.tkk.fi/%7Evarun/>

---

From: Varun Singh <[email-masked]>
Date: Wed, 31 Jul 2013 11:26:17 +0200

Hi Benoit,

Comments inline.

Regards,
Varun

----
http://www.netlab.tkk.fi/~varun

On 31.7.2013, at 10.03, Benoit Claise <[email-masked]> wrote:

 Hi Varun,

 Hi,

   Threshold in RTP:
   [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard
<http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry-00#ref-I-D.ietf-xrblock-rtcp-xr-burst-gap-discard>],
appendix A <http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry-00#appendix-A>

Yes, at least the burst gap discard should be updated.

Do you have any suggestions on how to fix the burst/gap loss either in the
registry? Or in the RFC.

    Another example is "Total RTP packets expected in bursts" is this
defined twice?

should suffice?

  These two are identical.
We overlooked that during the review (because we didn't have a registry to
start with)
Is there something we should correct now in [
I-D.ietf-xrblock-rtcp-xr-burst-gap-discard<http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry-00#ref-I-D.ietf-xrblock-rtcp-xr-burst-gap-discard>
]?

   Total RTP packets expected in bursts:
   [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard
<http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry-00#ref-I-D.ietf-xrblock-rtcp-xr-burst-gap-discard>],
appendix A <http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry-00#appendix-A>

Then this should be removed from the draft.

Regards, Benoit

   Cheers,

Varun

---

From: Qin Wu <[email-masked]>
Date: Wed, 31 Jul 2013 17:08:45 +0000

[Qin]:
I think first you should identify performance metrics as much as possible, so it may take a long time to finish this draft.
Secondly, would it make sense to add a statement to say:
“
Other Performance Metrics that is identified should be reported to Performance measurement Directorate and can be added in future documents as the need
arises.
”

Regards, Benoit

Regards!
-Qin
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Wednesday, July 17, 2013 4:58 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [xrblock] Fwd: [ippm] Performance Metrics Registry: new draft

Dear all,

Regards, Benoit

-------- Original Message --------
Subject:

Date:

From:

To:

Dear all,

Let me introduce

Regards, Benoit.

ippm mailing list

---

From: Qin Wu <[email-masked]>
Date: Wed, 31 Jul 2013 18:08:34 +0000

[Qin]:

Regards, Benoit

Regards!
-Qin

Dear all,

Regards, Benoit

-------- Original Message --------
Subject:

Date:

From:

To:

Dear all,

Let me introduce

Regards, Benoit.

ippm mailing list