[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PMOL] FW: [bmwg] Soliciting comments on GMPLS performance metrics draft inCCAMP
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" <sunwq at sjtu.edu.cn>
Sent: Thursday, June 05, 2008 9:15 PM
To: "Henk Uijterwaal" <henk at ripe.net>; "IETF IPPM WG" <ippm at ietf.org>;
<ccamp at ietf.org>
Cc: <pmol at ietf.org>
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" <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