Subject: Re: [PMOL] Fwd: Re: [CCAMP] WG Last Call: draft-ietf-ccamp-dpm

From: Al Morton <[email-masked]>
Date: Sun, 20 May 2012 09:37:35 -0400

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