Subject: [PMOL] FW: [xrblock] WGLC for xrblock-rtcp-xr-discard-rle-metrics
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Date: Thu, 31 May 2012 11:45:13 +0200
List-Id: Performance Metrics Directorate list <pmol.ietf.org>

Another WGLC for a metrics I-D in XRBLOCK. 

Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Shida Schubert
Sent: Thursday, May 31, 2012 10:44 AM
To: xrblock
Cc: [email-masked]
Subject: [xrblock] WGLC for xrblock-rtcp-xr-discard-rle-metrics

This is an announcement of a 2 weeks XRBLOCK WG last call on 
"Report Block for Run Length Encodings of Discarded Packets" prior
to requesting publication of the document as a proposed standard. 

Please send your comments, including nits, to the list by the

 14th of June

If you read the draft and you see no issues, concerns, or nits, please
express the fact that you have no issue progressing the draft on the
list as well. 

The latest version can be found here:

http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-rle-metric
s-03

Regards

Shida as co-chair
_______________________________________________
xrblock mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xrblock

Date: Fri, 25 May 2012 07:43:40 -0400
To: Qin Wu <[email-masked]>, "Charles Eckel (eckelcu)" <[email-masked]>, "Carlos Pignataro (cpignata)" <[email-masked]>, [email-masked]
From: Al Morton <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [PMOL] [xrblock] WGLC for Packet Delay Variation MetricReporting

Thanks Qin, that should do it.
Al

At 11:32 PM 5/24/2012, Qin Wu wrote:
>You are right, the Y.1540 has already got alignment with RFC5481 in 
>the update.
>and use RFC5481 as the reference.
>So I propose the following change to the section 3.3, 3rd paragraph

From: Qin Wu <[email-masked]>
To: "Charles Eckel (eckelcu)" <[email-masked]>, "Carlos Pignataro (cpignata)" <[email-masked]>, <[email-masked]>, Al Morton <[email-masked]>
Date: Fri, 25 May 2012 11:32:36 +0800
Cc: [email-masked], [email-masked]
Subject: Re: [PMOL] [xrblock] WGLC for Packet Delay Variation MetricReporting

Date: Thu, 24 May 2012 08:31:02 -0400
To: Qin Wu <[email-masked]>, "Charles Eckel (eckelcu)" <[email-masked]>, "Carlos Pignataro (cpignata)" <[email-masked]>, [email-masked]
From: Al Morton <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [PMOL] [xrblock] WGLC for Packet Delay Variation MetricReporting

Qin,

I'm sorry, but it's still completely misleading to talk about
the first packet as a reference packet in your text,
(even though you say mention it may not be the reference).
The first packet is not used as a reference because it sets an arbitrary
delay as the reference for the delay variation distribution,
and other problems follow.

I suggest that you make a stronger reference to RFC 5481
in this section, and remove the confusing text.

Al

At 12:59 AM 5/24/2012, Qin Wu wrote:
>Hi, Al:
>I agree with your comments. Based on RFC5481 and the newly updated 
>Y.1541 in March,2011,
>the reference packet transfer delay should be chosen as the delay of 
>the reference packet with minimum
>delay.
>Therefore I proposed the following change in the section 3.3, 3rd 
>paragraph to get consistent with RFC5481 and Y.1541.
>OLD TEXT:
>"
>    2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay
>    variation with respect to the time of arrival of the first packet of
>    the connection.  In an RTP context, the two "points" are at the
>    sender (the synchronization source which applies RTP timestamps) and
>    at the receiver.  The value of this metric for the packet with index
>    j is identical to the quantity D(i,j) defined in Section 6.4.1 of
>    [RFC3550] if the packet index i is set equal to 1, that is, the
>    reference packet for the metric is the first packet of the
>    connection. ...
>"
>NEW TEXT:
>"
>    2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay
>    variation with respect to a defined reference packet transfer delay
>     . One example of such reference packet is the first packet of 
> the connection.
>     Note that the reference IP packet transfer delay is the delay of the
>     reference packet with minimum
>     delay [RFC5481] and  may be not the first packet delay of
>     the connection.
>  In an RTP context, the two "points" are at the
>    sender (the synchronization source which applies RTP timestamps) and
>    at the receiver.  The value of this metric for the packet with index
>    j is identical to the quantity D(i,j) defined in Section 6.4.1 of
>    [RFC3550]. If the packet index i is set equal to 1, that is, the
>    reference packet for the metric is the first packet of the
>    connection.  ....
>"
>Also the reference to Y.1541 will be updated.
>
>Regards!
>-Qin
>----- Original Message -----
>From: "Charles Eckel (eckelcu)" <[email-masked]>
>To: "Al Morton" <[email-masked]>; "Carlos Pignataro (cpignata)" 
><[email-masked]>; <[email-masked]>
>Cc: <[email-masked]>; <[email-masked]>
>Sent: Thursday, May 24, 2012 1:08 AM
>Subject: Re: [xrblock] [PMOL] WGLC for Packet Delay Variation MetricReporting
>
>
> > Hi Al,
> >
> > Thank you for your comments. I have added the XRBLOCK alias so folks
> > there can benefit from them.
> > Carlos, thanks for volunteering to review as well. When you do, please
> > include [email-masked] in your list of recipients.
> >
> > Cheers,
> > Charles
> >
> >> -----Original Message-----
> >> From: Al Morton [mailto:[email-masked]]
> >> Sent: Sunday, May 20, 2012 6:22 AM
> >> To: Carlos Pignataro (cpignata); Charles Eckel (eckelcu); shida@ntt-
> >> at.com
> >> Cc: Romascanu, Dan (Dan); [email-masked]
> >> Subject: Re: [PMOL] [xrblock] WGLC for Packet Delay Variation Metric
> >> Reporting
> >>
> >> Charles and Shida,
> >>
> >> I gave this a brief look myself, and add the following comment:
> >>
> >>
> >>
> >> 3.3. Guidance on use of PDV metrics
> >>
> >>    This subsection provides informative guidance on when it
> > might
> >> be
> >>    appropriate to use each of the PDV metric types.
> >> ...
> >>    2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute
> > packet
> >> delay
> >>    variation with respect to the time of arrival of the first
> >> packet of
> >>    the connection.  In an RTP context, the two "points" are at
> >> the
> >>    sender (the synchronization source which applies RTP
> >> timestamps) and
> >>    at the receiver.  The value of this metric for the packet
> > with
> >> index
> >>    j is identical to the quantity D(i,j) defined in Section
> > 6.4.1
> >> of
> >>    [RFC3550] if the packet index i is set equal to 1, that is,
> >> the
> >>    reference packet for the metric is the first packet of the
> >>    connection.  The metric includes the effect of the frequency
> >> offsets
> >>    of clocks in both the sender and receiver end systems, so it
> >> is
> >>    useful mainly in network where synchronisation is
> > distributed.
> >> As
> >>    well as measuring packet delay variation in such networks, it
> >> may be
> >>    used to ensure that synchronisation is effective, for example
> >> where
> >>    the network carries ISDN data traffic over RTP [RFC4040].
> > The
> >> metric
> >>    is likely to be useful in networks which use fixed de-jitter
> >>    buffering, because it may be used to determine the length of
> >> the
> >>    required de-jitter buffer, or to determine if network
> >> performance has
> >>    deteriorated such that existing de-jitter buffers are too
> >> small to
> >>    accommodate the observed delay variation.
> >>
> >> While
> >>    "...The value of this metric for the packet with index
> >>    j is identical to the quantity D(i,j) defined in Section 6.4.1 of
> >>    [RFC3550] if the packet index i is set equal to 1, that is, the
> >>    reference packet for the metric is the first packet of the
> >>    connection."
> >> is true, it's not a particularly relevant comparison.
> >> The reference packet "i" is not the first packet in either
> >> the 3550 or the Y.1540 definition - this should be noted,
> >> at least. Also, the reference to Y.1540 is not up to date,
> >> a newer version is available.
> >>
> >> This section should probably reference
> >> http://tools.ietf.org/html/rfc5481
> > <http://tools.ietf.org/html/rfc5481>
> >> which includes all the metrics mentioned in section 3.3
> >> and provides more complete guidance.
> >>
> >> Al
> >>
> >> At 08:57 AM 5/20/2012, Al Morton wrote:
> >>
> >>
> >> Charles and Shida,
> >>
> >> Dan Romascanu suggested that the Performance Metrics Directorate
> >> take a look at this draft, in addition to his WGLC review.
> >>
> >> Carlos' comment is below (Thanks for your comment, Carlos).
> >>
> >> Al
> >> PMDir admin
> >>
> >>
> >> At 06:01 PM 5/19/2012, Carlos Pignataro wrote:
> >>
> >>
> >>
> >> On May 16, 2012, at 8:44 PM, Al Morton wrote:
> >>
> >>
> >>
> >> At 12:22 PM 5/16/2012, Romascanu, Dan (Dan)
> > wrote:
> >>
> >>
> >> I reviewed it and sent my comments a few
> > days
> >> ago to the XRBLOCK list -
> >> http://www.ietf.org/mail-
> >> archive/web/xrblock/current/msg00511.html 
> <http://www.ietf.org/mail->> archive/web/xrblock/current/msg00511.html> , I
> >> apologize for not copying PMOL.
> >>
> >>
> >> Thanks Dan, no need to apologize, just trying to
> > keep
> >> track.
> >>
> >>
> >>
> >> Note that this I-D refers only to
> >> reporting formats, while for metrics
> > definition
> >> they are referring
> >>
> > http://tools.ietf.org/html/draft-ietf-avtcore-
> >> monarch-04 <http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04>
> > .
> >>
> >>
> >> Anyone volunteer to review this one?
> >>
> >>
> >> I cannot volunteer to review this one this next two
> > weeks.
> >> However I wanted to point out that, when the XRBLOCK refers to rev -04
> >> of the Monitoring Architecture document, the current rev is -13.
> >> These are the changes, non trivial amount:
> >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-
> >> monarch-13.txt&url1=draft-ietf-avtcore-monarch-04.txt
> >> 
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch->> 
> 13.txt&url1=draft-ietf-avtcore-monarch-04.txt>
> >>
> >> Thanks,
> >>
> >> -- Carlos.
> >>
> >>
> >>
> >> Al
> >>
> >> _______________________________________________
> >> PMOL mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/pmol
> >> <https://www.ietf.org/mailman/listinfo/pmol>
> >
> > _______________________________________________
> > xrblock mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/xrblock

From: Qin Wu <[email-masked]>
To: "Charles Eckel (eckelcu)" <[email-masked]>, Al Morton <[email-masked]>, "Carlos Pignataro (cpignata)" <[email-masked]>,  <[email-masked]>
Date: Thu, 24 May 2012 12:59:32 +0800
Cc: [email-masked], [email-masked]
Subject: Re: [PMOL] [xrblock] WGLC for Packet Delay Variation MetricReporting

Content-class: urn:content-classes:message
Date: Wed, 23 May 2012 10:08:54 -0700
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: "Al Morton" <[email-masked]>, "Carlos Pignataro (cpignata)" <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [PMOL] [xrblock] WGLC for Packet Delay Variation Metric Reporting

Hi Al,

Thank you for your comments. I have added the XRBLOCK alias so folks
there can benefit from them.
Carlos, thanks for volunteering to review as well. When you do, please
include [email-masked] in your list of recipients.

Cheers,
Charles

> -----Original Message-----
> From: Al Morton [mailto:[email-masked]]
> Sent: Sunday, May 20, 2012 6:22 AM
> To: Carlos Pignataro (cpignata); Charles Eckel (eckelcu); shida@ntt-
> at.com
> Cc: Romascanu, Dan (Dan); [email-masked]
> Subject: Re: [PMOL] [xrblock] WGLC for Packet Delay Variation Metric
> Reporting
> 
> Charles and Shida,
> 
> I gave this a brief look myself, and add the following comment:
> 
> 
> 
> 	3.3. Guidance on use of PDV metrics
> 
> 	   This subsection provides informative guidance on when it
might
> be
> 	   appropriate to use each of the PDV metric types.
> 	...
> 	   2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute
packet
> delay
> 	   variation with respect to the time of arrival of the first
> packet of
> 	   the connection.  In an RTP context, the two "points" are at
> the
> 	   sender (the synchronization source which applies RTP
> timestamps) and
> 	   at the receiver.  The value of this metric for the packet
with
> index
> 	   j is identical to the quantity D(i,j) defined in Section
6.4.1
> of
> 	   [RFC3550] if the packet index i is set equal to 1, that is,
> the
> 	   reference packet for the metric is the first packet of the
> 	   connection.  The metric includes the effect of the frequency
> offsets
> 	   of clocks in both the sender and receiver end systems, so it
> is
> 	   useful mainly in network where synchronisation is
distributed.
> As
> 	   well as measuring packet delay variation in such networks, it
> may be
> 	   used to ensure that synchronisation is effective, for example
> where
> 	   the network carries ISDN data traffic over RTP [RFC4040].
The
> metric
> 	   is likely to be useful in networks which use fixed de-jitter
> 	   buffering, because it may be used to determine the length of
> the
> 	   required de-jitter buffer, or to determine if network
> performance has
> 	   deteriorated such that existing de-jitter buffers are too
> small to
> 	   accommodate the observed delay variation.
> 
> While
>    "...The value of this metric for the packet with index
>    j is identical to the quantity D(i,j) defined in Section 6.4.1 of
>    [RFC3550] if the packet index i is set equal to 1, that is, the
>    reference packet for the metric is the first packet of the
>    connection."
> is true, it's not a particularly relevant comparison.
> The reference packet "i" is not the first packet in either
> the 3550 or the Y.1540 definition - this should be noted,
> at least. Also, the reference to Y.1540 is not up to date,
> a newer version is available.
> 
> This section should probably reference
> http://tools.ietf.org/html/rfc5481
<http://tools.ietf.org/html/rfc5481>
> which includes all the metrics mentioned in section 3.3
> and provides more complete guidance.
> 
> Al
> 
> At 08:57 AM 5/20/2012, Al Morton wrote:
> 
> 
> 	Charles and Shida,
> 
> 	Dan Romascanu suggested that the Performance Metrics Directorate
> 	take a look at this draft, in addition to his WGLC review.
> 
> 	Carlos' comment is below (Thanks for your comment, Carlos).
> 
> 	Al
> 	PMDir admin
> 
> 
> 	At 06:01 PM 5/19/2012, Carlos Pignataro wrote:
> 
> 
> 
> 		On May 16, 2012, at 8:44 PM, Al Morton wrote:
> 
> 
> 
> 			At 12:22 PM 5/16/2012, Romascanu, Dan (Dan)
wrote:
> 
> 
> 				I reviewed it and sent my comments a few
days
> ago to the XRBLOCK list -
> 				http://www.ietf.org/mail-
> archive/web/xrblock/current/msg00511.html <http://www.ietf.org/mail-
> archive/web/xrblock/current/msg00511.html> , I
> 				apologize for not copying PMOL.
> 
> 
> 			Thanks Dan, no need to apologize, just trying to
keep
> track.
> 
> 
> 
> 				Note that this I-D refers only to
> 				reporting formats, while for metrics
definition
> they are referring
>
http://tools.ietf.org/html/draft-ietf-avtcore-
> monarch-04 <http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04>
.
> 
> 
> 			Anyone volunteer to review this one?
> 
> 
> 		I cannot volunteer to review this one this next two
weeks.
> However I wanted to point out that, when the XRBLOCK refers to rev -04
> of the Monitoring Architecture document, the current rev is -13.
> 		These are the changes, non trivial amount:
> 		http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-
> monarch-13.txt&url1=draft-ietf-avtcore-monarch-04.txt
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-
> 13.txt&url1=draft-ietf-avtcore-monarch-04.txt>
> 
> 		Thanks,
> 
> 		-- Carlos.
> 
> 
> 
> 			Al
> 
> 			_______________________________________________
> 			PMOL mailing list
> 			[email-masked]
> 			https://www.ietf.org/mailman/listinfo/pmol
> <https://www.ietf.org/mailman/listinfo/pmol>

Content-class: urn:content-classes:message
Date: Tue, 22 May 2012 10:58:00 +0200
From: "Jan Novak (janovak)" <[email-masked]>
To: "Aamer Akhter (aakhter)" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: [PMOL] Comments on draft-akhter-opsawg-perfmon-ipfix-02

Hi Amer,

I have reviewed your draft draft-akhter-opsawg-perfmon-ipfix-02.txt.

There seems to be a lot of text overlap with your methodology
document - section 1,3, 4 could probably be abbreviated or omitted
leaving the document just with raw IPFIX IE specifications or just
add the IE specification as sub-sections or a new section into
the first document ?? 

Section 2 uses definitions from RFC5610 - I think those you use there
are defined in RFC5102 as DataTypeSemantic, units and range while
RFC5610 specifies how this information should be exported - here
you are defining the IE itself so you should use the definitions
from RFC5102

Also the methodology documents already speaks in terms of IPFIX
IEs while you are trying to specify some performance metrics - the
methodology could have names and an exact definitions of the metric
and then a reference which IE represents the particular metric

RFC5102 section 2.1 specifies a template for IEs with a MUST
so the MUST entries should be literally followed in your IEs spec
- namely name, elementID, description, dataType and status.

RFC5102 section 2.1 specifies MAY entries for the template - like
DataTypeSemantic, units, name - might be preferable to follow the
naming as well

You interchanged ElementId with name - ElementId should be the
numerical ID of the particular IE, while name of the IE is actually
missing

Instead of using Observation Point - wouldn't be the scope of the
element
appropriate ?? Or if not then scope should be actually added - are the 
metrics (like perfPacketLoss) applicable to all the traffic seen
by the UUT (or more specifically passing through the Observation
Point) or to just individual flows ?? This should also be part of the
particular metric definition.

Will your IEs be enterprise IEs or IANA ones ??

Section 4.1.2 - Units packets ??

Section 4.1.3 - there is a mis-match between the definition and the
range 
- it should be limited to 0 - 100 + a value when the rate is unknown
This definition is also missing in section 4.1.3 of your methodology

Sections 4.3.1, 4.3.2 - the values are just numbers/ids so units
shouldn't be octets but "none" ??

The IPFIX guys here have had few discussions regarding IE definitions
explosions with all the needs like this - have you thought using RFC6313
now
(structured data) ??

I am not sure I would use RFC2321 as a reference work :-).
huic-ipfix-sipfix is not a work in progress - the ID expired 3 years
ago.
ie-doctors is a WG doc version 2 now -
draft-ietf-ipfix-ie-doctors-02.txt
pmol-metrics-framework is RFC 6390

The document would benefit from running it through spell checker.

Rgds, Jan

The climate of Edinburgh is such that the weak succumb young .... 
and the strong envy them.
                                 Dr. Johnson

Date: Sun, 20 May 2012 09:37:35 -0400
To: [email-masked]
From: Al Morton <[email-masked]>
Cc: Lou Berger <[email-masked]>, "BRUNGARD, DEBORAH A \(ATTLABS\)" <[email-masked]>
Subject: Re: [PMOL] Fwd: Re: [CCAMP] WG Last Call: draft-ietf-ccamp-dpm

PMDir,

I received the following request to review
http://tools.ietf.org/html/draft-ietf-ccamp-dpm-05
in connection with a previous WGLC.

I've provided some comments, appended below.
Would anyone else like to review this draft
and provide comments in a week or so?

regards,
Al
PMDir admin

At 06:19 PM 5/18/2012, Lou Berger wrote:
>...
>
>-------- Original Message --------
>Subject:        Re: [CCAMP] WG Last Call: draft-ietf-ccamp-dpm
>Date:   Thu, 22 Mar 2012 16:16:56 -0400
>From:   Lou Berger <[email-masked]>
>To:     CCAMP <[email-masked]>
>
>
>
>The last call on this document has ended.
>
>Authors,
>         Please update the draft according to any comments received.  Once the
>update is submitted, please summarize all changes to the list.
>
>Much thanks,
>Lou
>
>On 3/7/2012 9:23 AM, Lou Berger wrote:
> > This mail begins a two week working group last call on:
> >
> > http://tools.ietf.org/html/draft-ietf-ccamp-dpm-05
> >
> > This working group last call ends on March 21.  Please send comments to
> > the CCAMP mailing list.
> >
> > Lou (and Deborah)
> > _______________________________________________
> > CCAMP mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ccamp
> >
> >
> >
> >

-=-=-=-=-=-=-=-=-=-=-=-
Hi Lou,

I took a quick look this morning, the authors have nicely adopted
the familiar metric framework used in other performance work,
and I like the metric naming - very straightforward to sort out
the names once you read the explanation in section 3,
although they could say explicitly how they've done it, so it lends
to extension in the future.

I would suggest they give the acronym expansion in each section.
for example:

>5.2.  Metric Name
>
>    RRFD  =  RESV Received, Forward Datapath

One word choice in section 1 could be improved:

>    This document defines a series of performance metrics to evaluate the
>    availability of data path during the signaling process.

I would suggests/availability/connectivity/

"availability" has many more rigorous definitions than the
test pattern used here.

A minor concern:
It seems that the length of the test signal will influence
the delay measurement, the simple serialization time for bits
in the first packet of the signal, which it seems could be a
Jumbo packet. This should be mentioned as it is applicable as
a potential source of error for all the metrics. I realize this may
be negligible on high speed interfaces using a single packet for
the test signal - but they've left the option for long test
signals. There is clear motivation to use small packets from a
performance-bias perspective.

-=-=-=-=-=-=-

In recent news, the Performance Metrics Directorate has been formed
in the OPS area, and we review drafts when WG chairs request.
As PMDir Admin, I'd be glad to ask for a review volunteer.
Let me know.

We usually try to do early review of WG doc candidates rather
than WG Last Call, simply because the feedback might be extensive.
http://www.ietf.org/iesg/directorate/performance-metrics.html

hope this helps,
Al

Date: Sun, 20 May 2012 09:21:42 -0400
To: Carlos Pignataro <[email-masked]>, [email-masked], [email-masked]
From: Al Morton <[email-masked]>
Cc: [email-masked]
Subject: Re: [PMOL] [xrblock] WGLC for Packet Delay Variation Metric Reporting

<html>
<body>
Charles and Shida,<br><br>
I gave this a brief look myself, and add the following comment:<br><br>
<dl>
<dd>3.3. Guidance on use of PDV metrics<br>

<dd>&nbsp;&nbsp; This subsection provides informative guidance on when it
might be
<dd>&nbsp;&nbsp; appropriate to use each of the PDV metric types.
<dd>...
<dd>&nbsp;&nbsp; 2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute
packet delay
<dd>&nbsp;&nbsp; variation with respect to the time of arrival of the
first packet of
<dd>&nbsp;&nbsp; the connection.&nbsp; In an RTP context, the two
&quot;points&quot; are at the
<dd>&nbsp;&nbsp; sender (the synchronization source which applies RTP
timestamps) and
<dd>&nbsp;&nbsp; at the receiver.&nbsp; The value of this metric for the
packet with index
<dd>&nbsp;&nbsp; j is identical to the quantity D(i,j) defined in Section
6.4.1 of
<dd>&nbsp;&nbsp; [RFC3550] if the packet index i is set equal to 1, that
is, the
<dd>&nbsp;&nbsp; reference packet for the metric is the first packet of
the
<dd>&nbsp;&nbsp; connection.&nbsp; The metric includes the effect of the
frequency offsets
<dd>&nbsp;&nbsp; of clocks in both the sender and receiver end systems,
so it is
<dd>&nbsp;&nbsp; useful mainly in network where synchronisation is
distributed.&nbsp; As
<dd>&nbsp;&nbsp; well as measuring packet delay variation in such
networks, it may be
<dd>&nbsp;&nbsp; used to ensure that synchronisation is effective, for
example where
<dd>&nbsp;&nbsp; the network carries ISDN data traffic over RTP
[RFC4040].&nbsp; The metric
<dd>&nbsp;&nbsp; is likely to be useful in networks which use fixed
de-jitter
<dd>&nbsp;&nbsp; buffering, because it may be used to determine the
length of the
<dd>&nbsp;&nbsp; required de-jitter buffer, or to determine if network
performance has
<dd>&nbsp;&nbsp; deteriorated such that existing de-jitter buffers are
too small to
<dd>&nbsp;&nbsp; accommodate the observed delay variation.
</dl>While<br>
&nbsp;&nbsp; &quot;...The value of this metric for the packet with
index<br>
&nbsp;&nbsp; j is identical to the quantity D(i,j) defined in Section
6.4.1 of<br>
&nbsp;&nbsp; [RFC3550] if the packet index i is set equal to 1, that is,
the<br>
&nbsp;&nbsp; reference packet for the metric is the first packet of
the<br>
&nbsp;&nbsp; connection.&quot;<br>
is true, it's not a particularly relevant comparison. <br>
The reference packet &quot;i&quot; is not the first packet in either
<br>
the 3550 or the Y.1540 definition - this should be noted,<br>
at least. Also, the reference to Y.1540 is not up to date,<br>
a newer version is available.<br><br>
This section should probably reference<br>
<a href="http://tools.ietf.org/html/rfc5481" eudora="autourl">
http://tools.ietf.org/html/rfc5481</a><br>
which includes all the metrics mentioned in section 3.3<br>
and provides more complete guidance.<br><br>
Al<br><br>
At 08:57 AM 5/20/2012, Al Morton wrote:<br>
<blockquote type=cite class=cite cite="">Charles and Shida,<br><br>
Dan Romascanu suggested that the Performance Metrics Directorate<br>
take a look at this draft, in addition to his WGLC review.<br><br>
Carlos' comment is below (Thanks for your comment, Carlos).<br><br>
Al<br>
PMDir admin<br><br>
<br>
At 06:01 PM 5/19/2012, Carlos Pignataro wrote:<br><br>
<blockquote type=cite class=cite cite="">On May 16, 2012, at 8:44 PM, Al
Morton wrote:<br><br>
<blockquote type=cite class=cite cite="">At 12:22 PM 5/16/2012,
Romascanu, Dan (Dan) wrote:<br>
<blockquote type=cite class=cite cite="">I reviewed it and sent my
comments a few days ago to the XRBLOCK list -<br>
<a href="http://www.ietf.org/mail-archive/web/xrblock/current/msg00511.html">
http://www.ietf.org/mail-archive/web/xrblock/current/msg00511.html</a>,
I<br>
apologize for not copying PMOL.</blockquote><br>
Thanks Dan, no need to apologize, just trying to keep track.<br><br>
<blockquote type=cite class=cite cite="">Note that this I-D refers only
to<br>
reporting formats, while for metrics definition they are referring<br>
<a href="http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04">
http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04</a>.</blockquote>
<br>
Anyone volunteer to review this one?</blockquote><br>
I cannot volunteer to review this one this next two weeks. However I
wanted to point out that, when the XRBLOCK refers to rev -04 of the
Monitoring Architecture document, the current rev is -13.<br>
These are the changes, non trivial amount:<br>
<a href="http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-13.txt&amp;url1=draft-ietf-avtcore-monarch-04.txt">
http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-13.txt&amp;url1=draft-ietf-avtcore-monarch-04.txt</a>
<br><br>
Thanks,<br><br>
-- Carlos.<br><br>
<blockquote type=cite class=cite cite="">Al<br>
&nbsp;<br>
_______________________________________________<br>
PMOL mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/pmol" eudora="autourl">
https://www.ietf.org/mailman/listinfo/pmol</a></blockquote></blockquote>
</blockquote></body>
</html>

Date: Sun, 20 May 2012 08:57:28 -0400
To: Carlos Pignataro <[email-masked]>, [email-masked], [email-masked]
From: Al Morton <[email-masked]>
Cc: [email-masked]
Subject: Re: [PMOL] [xrblock] WGLC for Packet Delay Variation Metric Reporting

<html>
<body>
Charles and Shida,<br><br>
Dan Romascanu suggested that the Performance Metrics Directorate<br>
take a look at this draft, in addition to his WGLC review.<br><br>
Carlos' comment is below (Thanks for your comment, Carlos).<br><br>
Al<br>
PMDir admin<br><br>
<br>
At 06:01 PM 5/19/2012, Carlos Pignataro wrote:<br><br>
<blockquote type=cite class=cite cite="">On May 16, 2012, at 8:44 PM, Al
Morton wrote:<br><br>
<blockquote type=cite class=cite cite="">At 12:22 PM 5/16/2012,
Romascanu, Dan (Dan) wrote:<br>
<blockquote type=cite class=cite cite="">I reviewed it and sent my
comments a few days ago to the XRBLOCK list -<br>
<a href="http://www.ietf.org/mail-archive/web/xrblock/current/msg00511.html">
http://www.ietf.org/mail-archive/web/xrblock/current/msg00511.html</a>,
I<br>
apologize for not copying PMOL.</blockquote><br>
Thanks Dan, no need to apologize, just trying to keep track.<br><br>
<blockquote type=cite class=cite cite="">Note that this I-D refers only
to<br>
reporting formats, while for metrics definition they are referring<br>
<a href="http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04">
http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04</a>.</blockquote>
<br>
Anyone volunteer to review this one?<br>
</blockquote><br>
I cannot volunteer to review this one this next two weeks. However I
wanted to point out that, when the XRBLOCK refers to rev -04 of the
Monitoring Architecture document, the current rev is -13.<br>
These are the changes, non trivial amount:<br>
<a href="http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-13.txt&amp;url1=draft-ietf-avtcore-monarch-04.txt">
http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-13.txt&amp;url1=draft-ietf-avtcore-monarch-04.txt</a>
<br><br>
Thanks,<br><br>
-- Carlos.<br><br>
<blockquote type=cite class=cite cite="">Al<br>
&nbsp;<br>
_______________________________________________<br>
PMOL mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/pmol" eudora="autourl">
https://www.ietf.org/mailman/listinfo/pmol</a><br>
</blockquote><br>
</blockquote></body>
</html>

From: Carlos Pignataro <[email-masked]>
Date: Sat, 19 May 2012 18:01:52 -0400
To: Al Morton <[email-masked]>
Cc: [email-masked]
Subject: Re: [PMOL] [xrblock] WGLC for Packet Delay Variation Metric Reporting

--Apple-Mail=_D943D050-CA63-485D-92D8-761BBD7B1CE4
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_83D0B341-CAD4-4C8D-B441-52B12912BDE2"

--Apple-Mail=_83D0B341-CAD4-4C8D-B441-52B12912BDE2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On May 16, 2012, at 8:44 PM, Al Morton wrote:

> At 12:22 PM 5/16/2012, Romascanu, Dan (Dan) wrote:
>> I reviewed it and sent my comments a few days ago to the XRBLOCK list -
>> http://www.ietf.org/mail-archive/web/xrblock/current/msg00511.html, I
>> apologize for not copying PMOL.
> 
> Thanks Dan, no need to apologize, just trying to keep track.
> 
>> Note that this I-D refers only to
>> reporting formats, while for metrics definition they are referring
>> http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04.
> 
> Anyone volunteer to review this one?
> 

I cannot volunteer to review this one this next two weeks. However I wanted to point out that, when the XRBLOCK refers to rev -04 of the Monitoring Architecture document, the current rev is -13.
These are the changes, non trivial amount:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-13.txt&url1=draft-ietf-avtcore-monarch-04.txt

Thanks,

-- Carlos.

> Al
>  
> _______________________________________________
> PMOL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pmol
> 

--Apple-Mail=_83D0B341-CAD4-4C8D-B441-52B12912BDE2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 16, 2012, at 8:44 PM, Al Morton wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>At 12:22 PM 5/16/2012, Romascanu, Dan (Dan) wrote:<br><blockquote type="cite">I reviewed it and sent my comments a few days ago to the XRBLOCK list -<br></blockquote><blockquote type="cite"><a href="http://www.ietf.org/mail-archive/web/xrblock/current/msg00511.html">http://www.ietf.org/mail-archive/web/xrblock/current/msg00511.html</a>, I<br></blockquote><blockquote type="cite">apologize for not copying PMOL.<br></blockquote><br>Thanks Dan, no need to apologize, just trying to keep track.<br><br><blockquote type="cite">Note that this I-D refers only to<br></blockquote><blockquote type="cite">reporting formats, while for metrics definition they are referring<br></blockquote><blockquote type="cite"><a href="http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04">http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04</a>.<br></blockquote><br>Anyone volunteer to review this one?<br><br></div></blockquote><div><br></div><div>I cannot volunteer to review this one this next two weeks. However I wanted to point out that, when the XRBLOCK refers to rev -04 of the Monitoring Architecture document, the current rev is -13.</div><div>These are the changes, non trivial amount:</div><div><a href="http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-13.txt&amp;url1=draft-ietf-avtcore-monarch-04.txt">http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-13.txt&amp;url1=draft-ietf-avtcore-monarch-04.txt</a></div><div><br></div><div>Thanks,</div><div><br></div><div>-- Carlos.</div><br><blockquote type="cite"><div>Al<br> &nbsp;<br>_______________________________________________<br>PMOL mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/mailman/listinfo/pmol<br><br></div></blockquote></div><br></body></html>
--Apple-Mail=_83D0B341-CAD4-4C8D-B441-52B12912BDE2--

--Apple-Mail=_D943D050-CA63-485D-92D8-761BBD7B1CE4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

--Apple-Mail=_D943D050-CA63-485D-92D8-761BBD7B1CE4--

Content-class: urn:content-classes:message
Date: Thu, 17 May 2012 12:02:39 +0200
From: "Jan Novak (janovak)" <[email-masked]>
To: "Al Morton" <[email-masked]>, <[email-masked]>
Subject: Re: [PMOL] Fwd: Comments on draft-akhter-opsawg-perfmon-method-02

Hi Al,

I will have a look.

Jan

The climate of Edinburgh is such that the weak succumb young .... 
and the strong envy them.
                                 Dr. Johnson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Al Morton
Sent: 16 May 2012 15:55
To: [email-masked]
Subject: [PMOL] Fwd: Comments on draft-akhter-opsawg-perfmon-method-02

PM Directorate,

I reviewed one of Aamer's passive performance drafts
(attached below).

Aamer has a related draft, would anyone volunteer to
review this one:
http://tools.ietf.org/html/draft-akhter-opsawg-perfmon-ipfix

let me know, and thanks,
Al
PMdir admin

>Date: Sun, 13 May 2012 13:06:56 -0400
>To: "Aamer Akhter (aakhter)" <[email-masked]>,
>From: Al Morton <[email-masked]>
>Subject: Comments on draft-akhter-opsawg-perfmon-method-02
>Cc: [email-masked], [email-masked]
>
>Hi Aamer,
>
>I finally made some time to review one of your drafts:
>http://tools.ietf.org/html/draft-akhter-opsawg-perfmon-method-02
>
>and comments follow below.  Not sure exactly which list
>will be best, so I CC'd ipfix and opsawg.
>
>hope this helps,
>Al
>
>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
>Main Comments:
>
>1. Packet Loss Calculation Method (4.1.1)
>Each metric has a paragraph labeled Calculation Method, but
>they contain a useful discussion of the possible issues instead.
>Many details are left to the implementor, with the likely outcome
>that different implementations will produce different results.
>For example, "synchronization" is mentioned many times, but what
>does this process entail? Try to minimize interpretation,
>perhaps by including a high-level step-by-step procedure for
>processing each arriving packet, both during initiation
>(synchronization, when the first few packets arrive) and
>steady-state processing (which involves using the info from sync).
>Since this draft is proposed for the Standards Track, it
>really needs to provide definitions that will stand-up to
>scrutiny of multiple implementations.
>
>
>2. Packet Loss "Rate" (4.1.3)
>This metric is really a Statistic, or a metric derived from the
>fundamental metrics of Packet Loss and Expected Packet (counts)
>over a particular measurement interval.  Thus, there's no need
>to talk about measurement points, you've already defined these
>in the Loss and Expected metrics.
>Also, this is more accurately named "Loss Ratio", especially when
>expressed as a percentage as you've done.
>
>3. Jitter (4.1.5 and beyond)
>This metric will disappoint for use in SLAs or de-jitter buffer
>sizing if it is based on the RFCC3550 smoothed jitter calculation.
>Regardless of the measurement interval, only the last 16 packets
>have any influence over the current value (which is your Average?)
>
>General Editorial:
>There are a number of sentences that seem to contain alternate
>wordings, as though some deleted text returned somehow. Also,
>running a spell-check will help.
>
>Specific comments follow:
>
>3.1.  Quality of Service (QoS) Monitoring
>
>    The network operator needs to be able to gauge the end user's
>    satisfaction with the network service.  While there are many
>    components of the satisfaction such as pricing, packaging,
offering,
>    etc., a major component of satisfaction is delivering a consistent
>    service.
>Consistent Service in what dimensions?  Is Service Performance meant
here?
>
>
>4.  New Information Elements
>
>    The information elements are organized into two main groups:
>
>    Transport Layer:  Metrics that might be calculated from
observations
>       at higher layers but essentially provide information about the
>       network transport of user date.
>s/date/data/
>
>
>4.1.1.  perfPacketLoss
>
>    Name:  perfPacketLoss
>
>In this section, s/loss packet/lost packet/
>
>Also, what is the 5-tuple? SSRC + Src IP and Port + Dst IP and Port?
>
>At the end:
>    Measurment Timing  To be able to calculate this metric a continuous
>       set of the flow's packets (as each would have an incrementing
>       sequence number) needs to be monitored.  Therefore, per-packet
>       sampling would prevent this metric from being calculated.
>s/per-packet/sub-rate/ ??
>
>
>4.1.2.  perfPacketExpected
>
>    Name:  perfPacketExpected
>...
>    Use and Applications  The perfPacketExpected is a mid-calculation
>       metric used in the generation of perfPacketLossRate.  It is
>       equivilent to the highest received packet sequence number at the
>       time of measurement.
>True when there is no roll-over in Seq numbers.
>
>                       ... As the value only increments when packets
>       are received, packet loss may be occouring at the time of
>       measurement but perfPacketExpected remains constant.
>This is an issue worth mitigating, some sort of average packet rate
>could be used to estimate the number of losses while the Expected count
>remains constant.
>
>
>    Calculation Method:  The subtraction of the last sequence number
from
>       the first sequence number in monitoring interval yields the
>       expected count.  As discussed with perfPacketLost, there might
be
>       a delay due to synchronization with the flow's sequence numbers
>       and in such times the value of the metric should be set to
>       0xFFFFFFFE.  Care has to be taken to account for cases where the
>       packet's sequence number field wraps.
>This is an opportunity for more specifics, as an example
>(I didn't check the Appendix 3 reference, no access today...)
>
>
>4.1.3.  perfPacketLossRate
>
>    Name:  perfPacketLossPercentage
>These aren't the same!  Which is it?
>
>
>4.1.4.  perfPacketLossEvent
>
>    Name:  perfPacketLossEvent
>Need "consecutive" in the name, or some other way to distinguish
>single losses from "bursts".
>
>...
>    Calculation Method:  This data value is a simplified version of the
>       Lost Packets metric.  Whereas Lost Packets counts individual
>       packet loss, the 'loss event count' metric counts sets of
packets
>       that are lost.  For example, in the case of a sequence of
packets:
>       1,3,6,7,10 the packets marked 2,4,5,8 and 9 are lost.  So, a
total
>How long does the process wait to make the lost determination?
>
>
>4.1.5.  perfPacketInterArrivalJitterAvg
>
>    Name:  perfPacketInterArrivalJitterAvg
>
>    Description:  This metric measures the absolute deviation of the
>       difference in packet spacing at the measurement point compared
to
>       the packet spacing at the sender.
>I don't think that's what 3550 Jitter does...
>
>...
>    Use and Applications  The inter arrival jitter data value can be
used
>       be network operator to determine the network's impact to the
>       spacing in between a media stream's packets as they traverse the
>       network.
>What about Source Jitter?  this can be very significant, more than
network.
>
>Again, Min and Max are statistics.
>
>
>
>4.2.  User and Application Layer
>
>4.2.1.  perfSessionSetupDelay
>
>    Name:  perfSessionSetupDelay
>This seems to be the only two-point metric, worth noting.
>and
>[I-D.ietf-pmol-sip-perf-metrics]
>is an RFC now (which mostly defined metrics, not methods).
>
>

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

Date: Wed, 16 May 2012 20:44:02 -0400
To: "Romascanu, Dan (Dan)" <[email-masked]>, <[email-masked]>
From: Al Morton <[email-masked]>
Subject: Re: [PMOL] FW: [xrblock] WGLC for Packet Delay Variation Metric Reporting

At 12:22 PM 5/16/2012, Romascanu, Dan (Dan) wrote:
>I reviewed it and sent my comments a few days ago to the XRBLOCK list -
>http://www.ietf.org/mail-archive/web/xrblock/current/msg00511.html, I
>apologize for not copying PMOL.

Thanks Dan, no need to apologize, just trying to keep track.

>Note that this I-D refers only to
>reporting formats, while for metrics definition they are referring
>http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04.

Anyone volunteer to review this one?

Al

Content-class: urn:content-classes:message
Date: Wed, 16 May 2012 18:22:53 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Al Morton" <[email-masked]>, <[email-masked]>
Subject: Re: [PMOL] FW: [xrblock] WGLC for Packet Delay Variation Metric Reporting

Hi Al,

I reviewed it and sent my comments a few days ago to the XRBLOCK list -
http://www.ietf.org/mail-archive/web/xrblock/current/msg00511.html, I
apologize for not copying PMOL. Note that this I-D refers only to
reporting formats, while for metrics definition they are referring
http://tools.ietf.org/html/draft-ietf-avtcore-monarch-04. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Al Morton
> Sent: Wednesday, May 16, 2012 5:51 PM
> To: [email-masked]
> Subject: Re: [PMOL] FW: [xrblock] WGLC for Packet Delay Variation
> Metric Reporting
> 
> PM Directorate,
> 
> Dan sent this a few weeks back, did anyone review it?
> If not, would anyone like to review it fairly soon?
> (we could probably get some extra time for a PMdir review
> from the chairs...)
> 
> let me know,
> Al
> PMdir admin
> 
> At 04:56 AM 5/2/2012, Romascanu, Dan (Dan) wrote:
> >From: [email-masked] [mailto:[email-masked]] On
> >Behalf Of Shida Schubert
> >Sent: Wednesday, May 02, 2012 8:02 AM
> >To: xrblock
> >Subject: [xrblock] WGLC for Packet Delay Variation Metric Reporting
> >
> >This is an announcement of a 2 weeks XRBLOCK WG last call on
> >"Report Block for Packet Delay Variation Metric Reporting" prior
> >to requesting publication of the document as a proposed standard.
> >
> >Please send your comments, including nits, to the list by the
> >
> >   17th of May
> >
> >If you read the draft and you see no issues, concerns, or nits,
please
> >express the fact that you have no issue progressing the draft on the
> >list as well.
> >
> >The latest version can be found here:
> >http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-pdv-02
> >
> >Regards
> >
> >  Shida as co-chair
> >
> 
> _______________________________________________
> PMOL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pmol

Date: Wed, 16 May 2012 10:54:49 -0400
To: [email-masked]
From: Al Morton <[email-masked]>
Subject: [PMOL] Fwd: Comments on draft-akhter-opsawg-perfmon-method-02

PM Directorate,

I reviewed one of Aamer's passive performance drafts
(attached below).

Aamer has a related draft, would anyone volunteer to
review this one:
http://tools.ietf.org/html/draft-akhter-opsawg-perfmon-ipfix

let me know, and thanks,
Al
PMdir admin

>Date: Sun, 13 May 2012 13:06:56 -0400
>To: "Aamer Akhter (aakhter)" <[email-masked]>,
>From: Al Morton <[email-masked]>
>Subject: Comments on draft-akhter-opsawg-perfmon-method-02
>Cc: [email-masked], [email-masked]
>
>Hi Aamer,
>
>I finally made some time to review one of your drafts:
>http://tools.ietf.org/html/draft-akhter-opsawg-perfmon-method-02
>
>and comments follow below.  Not sure exactly which list
>will be best, so I CC'd ipfix and opsawg.
>
>hope this helps,
>Al
>
>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
>Main Comments:
>
>1. Packet Loss Calculation Method (4.1.1)
>Each metric has a paragraph labeled Calculation Method, but
>they contain a useful discussion of the possible issues instead.
>Many details are left to the implementor, with the likely outcome
>that different implementations will produce different results.
>For example, "synchronization" is mentioned many times, but what
>does this process entail? Try to minimize interpretation,
>perhaps by including a high-level step-by-step procedure for
>processing each arriving packet, both during initiation
>(synchronization, when the first few packets arrive) and
>steady-state processing (which involves using the info from sync).
>Since this draft is proposed for the Standards Track, it
>really needs to provide definitions that will stand-up to
>scrutiny of multiple implementations.
>
>
>2. Packet Loss "Rate" (4.1.3)
>This metric is really a Statistic, or a metric derived from the
>fundamental metrics of Packet Loss and Expected Packet (counts)
>over a particular measurement interval.  Thus, there's no need
>to talk about measurement points, you've already defined these
>in the Loss and Expected metrics.
>Also, this is more accurately named "Loss Ratio", especially when
>expressed as a percentage as you've done.
>
>3. Jitter (4.1.5 and beyond)
>This metric will disappoint for use in SLAs or de-jitter buffer
>sizing if it is based on the RFCC3550 smoothed jitter calculation.
>Regardless of the measurement interval, only the last 16 packets
>have any influence over the current value (which is your Average?)
>
>General Editorial:
>There are a number of sentences that seem to contain alternate
>wordings, as though some deleted text returned somehow. Also,
>running a spell-check will help.
>
>Specific comments follow:
>
>3.1.  Quality of Service (QoS) Monitoring
>
>    The network operator needs to be able to gauge the end user's
>    satisfaction with the network service.  While there are many
>    components of the satisfaction such as pricing, packaging, offering,
>    etc., a major component of satisfaction is delivering a consistent
>    service.
>Consistent Service in what dimensions?  Is Service Performance meant here?
>
>
>4.  New Information Elements
>
>    The information elements are organized into two main groups:
>
>    Transport Layer:  Metrics that might be calculated from observations
>       at higher layers but essentially provide information about the
>       network transport of user date.
>s/date/data/
>
>
>4.1.1.  perfPacketLoss
>
>    Name:  perfPacketLoss
>
>In this section, s/loss packet/lost packet/
>
>Also, what is the 5-tuple? SSRC + Src IP and Port + Dst IP and Port?
>
>At the end:
>    Measurment Timing  To be able to calculate this metric a continuous
>       set of the flow's packets (as each would have an incrementing
>       sequence number) needs to be monitored.  Therefore, per-packet
>       sampling would prevent this metric from being calculated.
>s/per-packet/sub-rate/ ??
>
>
>4.1.2.  perfPacketExpected
>
>    Name:  perfPacketExpected
>...
>    Use and Applications  The perfPacketExpected is a mid-calculation
>       metric used in the generation of perfPacketLossRate.  It is
>       equivilent to the highest received packet sequence number at the
>       time of measurement.
>True when there is no roll-over in Seq numbers.
>
>                       ... As the value only increments when packets
>       are received, packet loss may be occouring at the time of
>       measurement but perfPacketExpected remains constant.
>This is an issue worth mitigating, some sort of average packet rate
>could be used to estimate the number of losses while the Expected count
>remains constant.
>
>
>    Calculation Method:  The subtraction of the last sequence number from
>       the first sequence number in monitoring interval yields the
>       expected count.  As discussed with perfPacketLost, there might be
>       a delay due to synchronization with the flow's sequence numbers
>       and in such times the value of the metric should be set to
>       0xFFFFFFFE.  Care has to be taken to account for cases where the
>       packet's sequence number field wraps.
>This is an opportunity for more specifics, as an example
>(I didn't check the Appendix 3 reference, no access today...)
>
>
>4.1.3.  perfPacketLossRate
>
>    Name:  perfPacketLossPercentage
>These aren't the same!  Which is it?
>
>
>4.1.4.  perfPacketLossEvent
>
>    Name:  perfPacketLossEvent
>Need "consecutive" in the name, or some other way to distinguish
>single losses from "bursts".
>
>...
>    Calculation Method:  This data value is a simplified version of the
>       Lost Packets metric.  Whereas Lost Packets counts individual
>       packet loss, the 'loss event count' metric counts sets of packets
>       that are lost.  For example, in the case of a sequence of packets:
>       1,3,6,7,10 the packets marked 2,4,5,8 and 9 are lost.  So, a total
>How long does the process wait to make the lost determination?
>
>
>4.1.5.  perfPacketInterArrivalJitterAvg
>
>    Name:  perfPacketInterArrivalJitterAvg
>
>    Description:  This metric measures the absolute deviation of the
>       difference in packet spacing at the measurement point compared to
>       the packet spacing at the sender.
>I don't think that's what 3550 Jitter does...
>
>...
>    Use and Applications  The inter arrival jitter data value can be used
>       be network operator to determine the network's impact to the
>       spacing in between a media stream's packets as they traverse the
>       network.
>What about Source Jitter?  this can be very significant, more than network.
>
>Again, Min and Max are statistics.
>
>
>
>4.2.  User and Application Layer
>
>4.2.1.  perfSessionSetupDelay
>
>    Name:  perfSessionSetupDelay
>This seems to be the only two-point metric, worth noting.
>and
>[I-D.ietf-pmol-sip-perf-metrics]
>is an RFC now (which mostly defined metrics, not methods).
>
>

Date: Wed, 16 May 2012 10:51:13 -0400
To: [email-masked]
From: Al Morton <[email-masked]>
Subject: Re: [PMOL] FW: [xrblock] WGLC for Packet Delay Variation Metric Reporting

PM Directorate,

Dan sent this a few weeks back, did anyone review it?
If not, would anyone like to review it fairly soon?
(we could probably get some extra time for a PMdir review
from the chairs...)

let me know,
Al
PMdir admin

At 04:56 AM 5/2/2012, Romascanu, Dan (Dan) wrote:
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Shida Schubert
>Sent: Wednesday, May 02, 2012 8:02 AM
>To: xrblock
>Subject: [xrblock] WGLC for Packet Delay Variation Metric Reporting
>
>This is an announcement of a 2 weeks XRBLOCK WG last call on
>"Report Block for Packet Delay Variation Metric Reporting" prior
>to requesting publication of the document as a proposed standard.
>
>Please send your comments, including nits, to the list by the
>
>   17th of May
>
>If you read the draft and you see no issues, concerns, or nits, please
>express the fact that you have no issue progressing the draft on the
>list as well.
>
>The latest version can be found here:
>http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-pdv-02
>
>Regards
>
>  Shida as co-chair
>

Content-class: urn:content-classes:message
Date: Wed, 2 May 2012 10:56:21 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Subject: [PMOL] FW: [xrblock] WGLC for Packet Delay Variation Metric Reporting

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Shida Schubert
Sent: Wednesday, May 02, 2012 8:02 AM
To: xrblock
Subject: [xrblock] WGLC for Packet Delay Variation Metric Reporting

This is an announcement of a 2 weeks XRBLOCK WG last call on 
"Report Block for Packet Delay Variation Metric Reporting" prior
to requesting publication of the document as a proposed standard. 

Please send your comments, including nits, to the list by the

  17th of May

If you read the draft and you see no issues, concerns, or nits, please
express the fact that you have no issue progressing the draft on the
list as well. 

The latest version can be found here:
http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-pdv-02

Regards

 Shida as co-chair
 
_______________________________________________
xrblock mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xrblock