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

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 05 Jun 2008 12:04:09 +0200

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

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.

12.1. Statistics.
  I think you better report the 5th or 10th percentile of the distributions,
  rather than the minimum (and the same for the maximum).  This excludes
  data points where something went wrong in the measurement process.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/pmol

---

From: "Weiqiang Sun" <[email-masked]>
Date: Thu, 5 Jun 2008 22:15:04 +0900

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" <[email-masked]>
Sent: Thursday, June 05, 2008 7:04 PM
To: "IETF IPPM WG" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "Weiqiang Sun" <[email-masked]>
Subject: Re: [PMOL] FW: [bmwg] Soliciting comments on GMPLS performance 
metrics draft inCCAMP

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

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

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

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