Re: [PMOL] FW: [bmwg] Soliciting comments on GMPLS performance metrics draft inCCAMP

["Weiqiang Sun" <sunwq at sjtu.edu.cn>]

Hi Henk,

Many thanks for going through the draft and for the comments.
Please see online for my responses.

Best regards,
Weiqiang

--------------------------------------------------
From: "Henk Uijterwaal" <henk at ripe.net>
Sent: Thursday, June 05, 2008 7:04 PM
To: "IETF IPPM WG" <ippm at ietf.org>; <ccamp at ietf.org>
Cc: <pmol at ietf.org>; "Weiqiang Sun" <sunwq at sjtu.edu.cn>
Subject: Re: [PMOL] FW: [bmwg] Soliciting comments on GMPLS performance 
metrics draft inCCAMP

> Hi all,
>
>> Hi IPPMers and BMWGers,
>
>> Recently the LSP dynamic provisioning performance draft is adopted as a 
>> working item of CCAMP.
>
> Some comments, reading this as a non-expert on GMPLS.
>
> 3.4. Units.
>
>  I don't think this is quite correct: you start to measure at T1 and
>  wait for the setup to complete.  However, it doesn't, so at some point
>  you become bored and stop the measurement.  You report undefined.
>  However, one then has to report in the metrics parameters when the
>  measurement will be stopped.  This value should be added to the
>  metrics parameters.  (Note: this will apply to more metrics).
Yes I agree that this parameter is very important and should be carefully 
chosen, provided that different switching technologies may differ 
drastically in the delay when performing switching operations. For this 
reason we have a little bit discussion regarding this threshhold:
   o  A given methodology will have to include a way to determine
      whether a latency value is infinite or whether it is merely very
      large.  Simple upper bounds could be used.  But GMPLS networks may
      accommodate many kinds of devices.  For example, some photonic
      cross-connects (PXCs) have to move the micro mirrors.  This
      physical motion may take several milliseconds.  But the common
      electronic switches finish the nodal process within several
      microseconds.  So the unidirectional LSP setup delay varies
      drastically from a network to another.  In practice, the upper
      bound should be chosen carefully.
However, I think it is a good idea to put this parameter in the "metric 
parameter" section. This also makes the results more reasonable, since 
different threshholds may lead to different results.

>
> 4.3. Metrics Parameters.
>  In IPPM speak, Lamba refers to a rate but it also specifies a 
> distribution
>  for the interval between probe packets.  For example, poisson or 
> periodic.
>  The draft should mention which distribution to use.
We did define poisson arrival process for the lambda. However, it may be 
interesting to add some more arrival statistical models (with periodic as an 
example). We will consider this in the next revision.

>
> 12.1. Statistics.
>  I think you better report the 5th or 10th percentile of the 
> distributions,
Yes we do have the percentile of metric in 12.3, although we do not specify 
which exact value should be used.

>  rather than the minimum (and the same for the maximum).  This excludes
>  data points where something went wrong in the measurement process.
I think it is reasonable to keep the minimum value as this in normal cases 
can reflect the least amount of time needed to set up/release an LSP 
(something that is pretty much inherent for the control plane). And I agree 
that we don't need the maximum. Luckily enough we do not have one in the 
current version. :)

Anyway, I find a little mistake in 12.3:
   Given a metric and a percent X between 0% and 100%, the Xth
   percentile of all the dT values in the sample.  In addition, the
   unidirectional LSP setup delay percentile is undefined if the sample
   is empty.
It will be changed into:
   Given a metric and a percent X between 0% and 100%, the Xth
   percentile of all the dT values in the sample.  In addition, the
   percentile is undefined if the sample is empty.


>
> Henk
>
>
> -- 
> ------------------------------------------------------------------------------
> Henk Uijterwaal                           Email: 
> henk.uijterwaal(at)ripe.net
> RIPE Network Coordination Centre 
> http://www.amsterdamned.org/~henk
> P.O.Box 10096          Singel 258         Phone: +31.20.5354414
> 1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
> The Netherlands        The Netherlands    Mobile: +31.6.55861746
> ------------------------------------------------------------------------------
>
> Is one of the choices leaving the office open?
>                                       Alan Greenspan on the next elections
> 

_______________________________________________
PMOL mailing list
PMOL at ietf.org
https://www.ietf.org/mailman/listinfo/pmol