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

[Weiqiang Sun <[e-mail]>]

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" <[e-mail]> wrote:

>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 <[e-mail]>
>>> From: Al Morton <[e-mail]>
>>> Subject: Re: Fwd: Re: [CCAMP] WG Last Call: draft-ietf-ccamp-dpm
>>> Cc: "BRUNGARD, DEBORAH A (ATTLABS)" <[e-mail]>
>>>
>>> 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
>> 
>> 
>> 
>> 
>> 
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp