Subject: [PMOL] LSP DPPM draft updated.

From: [email-masked]
Date: Wed, 25 Jun 2008 11:36:51 +0800

Hi all,
Thanks to Henk and Al, the authors have now updated the LSP DPPM draft. 
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-02.txt

The two notable changes are:
1) We recovered the *sample definition* part which was removed from older versions. 
We feel the existing IPPM framework (by defining a singleton metric followed by definition of samples of singleton values) is the most convenient and reasonable way for us to cover the bound issue raised by Henk and Al. The arrival parameters can also be placed comfortablely in this sectioin.&nbsp; 

2) Two experts from Carriers joined us: Dr. Tomohiro Otani (KDDI) and Dr. Ruiquan Jing (CT).
Inputs from carriers has always been one major driving force for this work. The close involvement of carriers will possibly guides us to define more metrics, and accelerate the adoption of the defined metrics in testing and operational environments.
Below, I try to summarize the received comments and the changes made accordingly. Please let us know if you have further comments.
-Comments from Henk
&nbsp; 3.4. Units.
&nbsp;&nbsp;&nbsp; I don't think this is quite correct: you start to measure at T1 and
&nbsp;&nbsp;&nbsp; wait for the setup to complete.&nbsp; However, it doesn't, so at some point
&nbsp;&nbsp;&nbsp; you become bored and stop the measurement.&nbsp; You report undefined.
&nbsp;&nbsp;&nbsp; However, one then has to report in the metrics parameters when the
&nbsp;&nbsp;&nbsp; measurement will be stopped.&nbsp; This value should be added to the
&nbsp;&nbsp;&nbsp; metrics parameters.&nbsp; (Note: this will apply to more metrics).
Response: Yes this has been addressed in the sample definition sections, section 8-12.
-------------------------------------
&nbsp; 4.3. Metrics Parameters.
&nbsp;&nbsp;&nbsp; In IPPM speak, Lamba refers to a rate but it also specifies a distribution
&nbsp;&nbsp;&nbsp; for the interval between probe packets.&nbsp; For example, poisson or periodic.
&nbsp;&nbsp;&nbsp; The draft should mention which distribution to use.
Response：We mentioned the use of poisson process in sections like 4.5/4.6/4.7. For sample definition, we mentioned it before actual definition begins.
However, despite the poisson process, periodic process may also be used in the sampling process. The question is that do we need a new parameter for the choice of different arrival model? We would like to have your comments.

----------------------------
&nbsp; 12.1. Statistics.
&nbsp;&nbsp;&nbsp; I think you better report the 5th or 10th percentile of the distributions,
&nbsp;&nbsp;&nbsp; rather than the minimum (and the same for the maximum).&nbsp; This excludes
&nbsp;&nbsp;&nbsp; data points where something went wrong in the measurement process.
Response: This section is now numbered 14 in the new version. We give a generalized definition of percentile in 14.3. Hope it works.
=====
-Comments from Al 
&nbsp; As I've said in the past, this draft is an excellent start,
&nbsp; and because it adopts the metric template used in bmwg and ippm,
&nbsp; it's an easy read. Thanks for doing that part.
Thanks. It feels good to be native. : -)
----------------------------------------------
&nbsp; There is a taxonomy of possible outcomes for set-up protocols.
&nbsp; Each set-up attempt will have one of the following outcomes:
&nbsp; 1. Success
&nbsp; 2. Failure
&nbsp; 3. Incorrect Set-up (wrong destination)
&nbsp; The same basic outcomes apply to release attempts.
&nbsp; In the current text, the set-up time metrics cover the 
&nbsp; Successful outcome (they could be called Successful *.* Setup Time).
&nbsp; .....For more nit-picking background, read
&nbsp; http://tools.ietf.org/id/draft-morton-ippm-reporting-metrics-05.txt
&nbsp; So, I propose to add metrics to cover the Failure outcome,
&nbsp; defined as a count of failures=Undefined setup times divided by the
&nbsp; total attempts. ...
&nbsp; Adding metrics to cover the Incorrect setup/release outcome
&nbsp; would complete the taxonomy.&nbsp; ...
Response:&nbsp; Thanks for the detailed explanations and for pointing us to the draft. We totally agree. We have added a new section, section 13 to discuss this (below). 
Any more comments on that?&nbsp; 

13.&nbsp; Discussion for unsuccessful setup/release cases
&nbsp;&nbsp; As has been mentioned earlier, LSP setup/release may fail due to
&nbsp;&nbsp; various reasons.&nbsp; For example, setup/release may fail when the
&nbsp;&nbsp; control plane is overburdened or when there is resource shortage in
&nbsp;&nbsp; one of the intermediat nodes.&nbsp; Since the setup/release failure may
&nbsp;&nbsp; have significant impact on network operation, it is worthwhile to
&nbsp;&nbsp; report each failure cases, so that appropriate operations can be
&nbsp;&nbsp; performed to check the possible implementation,configuration or other
&nbsp;&nbsp; deficiency.
&nbsp;&nbsp; Although not commonly seen, an LSP setup/release attemp may be
&nbsp;&nbsp; falsely carried out. for example, the setup/release request may be
&nbsp;&nbsp; targed to a wrong egress node.&nbsp; Although faulty results may have
&nbsp;&nbsp; totally different implications to the control plane, if compared with
&nbsp;&nbsp; failure cases, for the purpose of performance evaluation, it is still
&nbsp;&nbsp; reasonable to treat such results as unsuccessful cases.&nbsp; Thus the
&nbsp;&nbsp; unsuccessful cases include both failure and incorrect cases.
&nbsp;&nbsp; Once a sample of a particular metric, e.g, single unidirectional LSP
&nbsp;&nbsp; setup delay, is obtained, we can deduce the unsuccessful cases by
&nbsp;&nbsp; sorting out from the sample the <time, delay> pairs with undefined
&nbsp;&nbsp; delay value.
---------------------------
&nbsp; 3.3&nbsp; Metric Parameters
&nbsp;&nbsp;&nbsp; o&nbsp; ID0, the ingress LSR ID
&nbsp;&nbsp;&nbsp; o&nbsp; ID1, the egress LSR ID
&nbsp; You should use these ID#s in the definition of the metric.
&nbsp;&nbsp;&nbsp; o&nbsp; T, a time
&nbsp; I've found that the two word description of a parameter is 
&nbsp; not always sufficient for me.&nbsp; I suggest:
&nbsp;&nbsp;&nbsp; o&nbsp; T, a time when the setup is attempted
&nbsp; I suggest to add a parameter, for clarity:
&nbsp;&nbsp;&nbsp; o&nbsp; WAITTIME, the maximum waiting time for successful setup
&nbsp; and mention this parameter in the sections where discussed, 
&nbsp; like 3.5 and 3.6.
Response: These have been addressed.
---------------------------------------------
&nbsp; 13. Discussion
&nbsp; The control-plane-only nature of these metrics should be clear(er)
&nbsp; in the Introduction/Scope.
Response: We change the introduction part into:&nbsp;&nbsp; 
&nbsp; This draft defines performance metrics and methodologies that can be
&nbsp; used to depict the dynamic LSP provisioning performance of GMPLS
&nbsp; networks, **more specifically, performance of the signaling protocol**.
Hope it is clearer.
--------------------------------------------------------------------
&nbsp; How important is it to have data-plane verification of the 
&nbsp; apparent control-plane success/failure/incorrect performance?
Response:&nbsp; Yes, it is important. But as the introduction of the verification may involve complex and totally different methodologies, we'd rather address it in (future) separate documents. Anyhow, the performance of the signaling itself is still an important metric to have. And depending on implementations, the overall time of an successful setup/release can sometimes be deduced from (or approximated by) this metric.
&nbsp; ----------------------------------
Our question:
With the addition of sample definition, do we still need the multiple LSP setup delay metric(in Section 4,6) and Samples of Multiple&nbsp; LSPs Setup Delay(in section 9,11)? We'd like to have your comments.

Best regards,
Authors
　　　　　　　&nbsp;

-------------------------------------------------------------------
08榜样行动中国，与我们一起传递坚强的力量(http://d1.sina.com.cn/sina/limeng3/mail_zhuiyu/2008/mail_zhuiyu_20080623.html)

-------------------------------------------------------------------
注册新浪2G免费邮箱(http://mail.sina.com.cn/)

_______________________________________________
PMOL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pmol