Subject: Re: [ippm] [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
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: "Weiqiang Sun" <[email-masked]>
Date: Mon, 9 Jun 2008 16:53:13 +0800

Hi all,

It seems that my SJTU mail account has some problems with the IETF lists 
(maybe blacklisted?).
I am resending this email from  my Gmail account. Sorry if you receive 
multiple copies of this.

Best regards,
Weiqiang Sun
Shanghai Jiao Tong University

--------------------------------------------------
From: "Weiqiang Sun" <[email-masked]>
Sent: Thursday, June 05, 2008 9:15 PM
To: "Henk Uijterwaal" <[email-masked]>; "IETF IPPM WG" <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Subject: Re: [PMOL] FW: [bmwg] Soliciting comments on GMPLS performance 
metrics draft inCCAMP

> 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
>
>> Hi all,
>>
>>> Hi IPPMers and BMWGers,
>>
> 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.
> 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.
> Yes we do have the percentile of metric in 12.3, although we do not 
> specify which exact value should be used.
>
> 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
>>
>>
>> --