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

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