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

From: Lou Berger <[email-masked]>
Date: Sun, 20 May 2012 10:44:45 -0400

Al,
	Thank you very much!

WG,
	Al is the Admin for the relatively new performance metrics directorate
(http://www.ietf.org/iesg/directorate/performance-metrics.html) and I
asked for his/their review as part of preparation for requesting
publication of the DPM draft.

Authors,
	Please note that Al has already suggested some useful changes.  I
suggest waiting until we have any additional comments from the
directorate before publishing the update that addresses them, but please
don't wait before discussing them.

Lou

On 5/20/2012 9:42 AM, Al Morton wrote:
> Lou and Deborah,
> 
> As requested, my brief review of the dpm draft is below.
> I've also asked for a Performance Metrics Directorate volunteer
> who could review the draft quickly. If another review is coming,
> I'll let you know.
> 
> Al
> 
> 
>> Date: Sat, 19 May 2012 10:06:22 -0400
>> To: Lou Berger <[email-masked]>
>> From: Al Morton <[email-masked]>
>> Subject: Re: Fwd: Re: [CCAMP] WG Last Call: draft-ietf-ccamp-dpm
>> Cc: "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
>>
>> 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
> 
> 
> 
> 
>

---

From: Weiqiang Sun <[email-masked]>
Date: Tue, 22 May 2012 09:01:07 +0800

Lou,

Al's comments have been helpful. And we will update the draft until the
directorate review has been received.

Kind regards,
Weiqiang

On 5/20/12 10:44 PM, "Lou Berger" <[email-masked]> wrote:

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