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

[Weiqiang Sun <[e-mail]>]

Al, Lou and CCAMPers,

Please see our responses to Al's comments/suggestions inline starting with
[SUN]. 

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.
[SUN] We are glad that you liked the naming. :)

>>>
>>> I would suggest they give the acronym expansion in each section.
>>> for example:
>>>
>>>
>>>> 5.2.  Metric Name
>>>>
>>>>    RRFD  =  RESV Received, Forward Datapath
[SUN] Really nice suggestion. This will make the naming strategy more
explicit and understandable. We will add this in the new version.

>>>
>>>
>>> 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.
[SUN] Okay. I would say "connectivity" captures our intention more
accurately. Thanks Al, will make this change in the new version.

>>>
>>> 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.

[SUN] Good comment.

Be noted that the serialization/de-serialization process on the control
path are also relevant.
In our current definition, the serialization/de-serialization delay of
control packets are counted
in the overall delay and this seems reasonable to me.

On the data path part, the current definition requires a test signal being
sent before control messages are sent. So the serialization of data path
signals on 
the sending side will not influence delay measurement. However, we do have
a de-serialization
delay on the receiver side. In the current definition, we say:
 	"...an error free signal is received..."
By this, we intend to define the reception of test signals in a very
general way since specific
data path technologies are out of scope. However, by this definition, we
have included the 
de-serialization delay into the overall delay in packet interface cases.
When very long test frames are sent,
the obtained delay will be notably longer than the actual value.

To address this concern, I suggest the following text being added in the
Discussion section of each metric:

The accuracy of this metric is also dependent on the physical layer
serialization/de-serialization of
the test signal for certain data path technologies. For instance, for an
LSP between a pair of low
speed Ethernet interfaces, the time needed to serialize/deserialize a
large frame may not be
negligible. In this case, it is RECOMMENDED that the ingress (or egress)
node uses small frames.
The average length of the frame MAY be reported.

Hope this will address Al's concern.


Best regards,
Weiqiang




>>>
>>> -=-=-=-=-=-=-
>>>
>>> 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