Subject: Review of draft-ietf-pce-monitoring-04.txt

From: Matt Mathis <[email-masked]>
Date: Mon, 27 Apr 2009 23:44:59 -0400 (EDT)

I've reviewed draft-ietf-pce-monitoring-04.txt as part of the transport area 
directorate's ongoing effort to review key IETF documents. These comments were 
written primarily for the transport area directors, but are copied to the 
document's authors for their information and to allow them to address any 
issues raised. The authors should consider this review together with any other 
last-call comments they receive. Please always CC [email-masked] if you 
reply to or forward this review.

draft-ietf-pce-monitoring-04.txt describes procedures and extensions to the 
Path Computation Element Protocol (PCEP) for monitoring the state of the path 
computation chain for troubleshooting and performance monitoring purposes.

It is designed specifically to carry information about PCE liveness, 
processing time and congestion.

However this draft does not define any of these metrics.

As a transport person, I have several comments about the congestion metric.

First it wasn't clear from the document if "congestion" was referring to the 
PCE itself or the corresponding LSPs.  For clarity of discussion, I will 
assume LSP congestion.  Even if that is not correct, my comments are general 
and there are equivalent problems for PCE case.

Second, there is not a universal definition of congestion.  The relevant 
feature of congestion is that it perturbs transit flows, by causing some sort 
of back-pressure.  This back-pressure generally comes in the form of raised 
RTT and/or increased loss probability, which reduces the data rate for elastic 
flows.  In the operational Internet normal values for these parameters can 
span many orders of magnitude.  For example on research and education 
backbones, loss probabilities as high as 1E-6 would be considered massively 
congested.  In other parts of the world loss probabilities as low as 1E-2 
might be considered extremely good.  There is not a standard way to determine 
when the load is high enough to effect service or when the users would 
perceive the network as "congested".

Without a definition of what congested means the metric is useless for such 
things as choosing alternative paths.  One implementation's uncongested state 
might be lower performance than another implementation's congested state.

Even if you are thinking in terms of admission control (where the 
back-pressure is to reject calls), your success probability might be higher on 
a very congested heavily multiplexed path than another path which has a single 
user is using most of the capacity, but not quite filling the link.

Although my examples are somewhat contrived, my point still stands: without a 
definition of "congested" there is no value to sharing a congestion 
indication.   I can't imagine any global definition of congestion that would 
work, and suspect that you need to add a mechanism to define a local, 
organization/topology specific definition of congestion.

Third, the only parameter carried by the congestion object is "expected 
congestion duration", as though the network can anticipate when the congestion 
will subside. It can't.  It may be that this parameter would be better 
identified by something like "recommended polling interval", e.g. "please 
don't ask again for x seconds."

In a similar vein neither processing time nor liveness is sufficiently 
well defined.

Although this is perhaps a nit, the IANA directions are structured in a way 
that forces somebody else to rewrite your text, possibly introducing errors, 
and peventing full review in last call. E.g. where you have "The MONITORING 
Object-Class is to be assigned by IANA (recommended value=19)" It would be 
better to say "The MONITORING Object-Class is XX [Value to be provided by 
IANA, recommended value=1]"  The point is to clearly distinguish between 3 
classes of text:

- Stuff that IANA adjusts in a clearly specified way while the document is at
   the RFC editor.

- Instructions to the IANA that should be removed while at the RFC editor,
   generally about the above.

- Instruction to the IANA that should be preserved in the final RFC (Registry
   creation, etc), which might include some details in the previous two
   categories.

It should be clear to everyone (especially the reviewers) how the IANA text is 
expected to be appear in the final RFC, even when it can't match the ID.

This draft has serious issues, described in the review, and needs some 
rethinking.

Thanks,
--MM--
-------------------------------------------
Matt Mathis     http://staff.psc.edu/mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------