Last Call Review of draft-ietf-ippm-rate-problem-08

Request Review of draft-ietf-ippm-rate-problem
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-12-22
Requested 2014-12-15
Authors Al Morton
Draft last updated 2014-12-17
Completed reviews Genart Last Call review of -08 by Ben Campbell (diff)
Genart Telechat review of -09 by Ben Campbell (diff)
Opsdir Last Call review of -08 by Dan Romascanu (diff)
Opsdir Telechat review of -09 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-ippm-rate-problem-08-opsdir-lc-romascanu-2014-12-17
Reviewed rev. 08 (document currently at 10)
Review result Has Issues
Review completed: 2014-12-17


I have reviewed this document as part of the Operational directorate's ongoing

effort to review all IETF documents being processed by the IESG.  These comments

were written primarily for the benefit of the operational area directors. 

Document editors and WG chairs should treat these comments just like any other

last call comments.


Ready with one issue


This I-D is an informational document that does not define a new protocol or protocol extensions. It does however contain a problem statement for test protocols conducting access rate measurement in productions networks. These protocols
 can be OWAMP (RFC 4656) or TWAMP (RFC 5357) but also non-IETF protocols. The following operational considerations in Appendix A.1 of RFC 5706 apply, I believe, and do not receive appropriate answers in the document:


5. Has the impact on network operation been discussed? See

Section 2.5.

* Will the new protocol significantly increase traffic load on

existing networks?

* Will the proposed management for the new protocol

significantly increase traffic load on existing networks?

* How will the new protocol impact the behavior of other

protocols in the network? Will it impact performance (e.g.,

jitter) of certain types of applications running in the same



I believe that at least a reference to these aspects need to be included, especially as the In-Service testing with injection of active traffic on production network is one of the methods discussed by the document.


The following reference to the effects of the high level traffic is not sufficient IMO:




Section 5 of [RFC2680] lists the problems with high

   measurement traffic rates, and the most relevant for rate measurement



is the tendency for measurement traffic to skew the results, followed

   by the possibility of introducing congestion on the access link.  In-

   Service testing MUST respect these traffic constraints.  Obviously,

   categories of rate measurement methods that use less active test

   traffic than others with similar accuracy are preferred for In-

   Service testing.


Section 5 of RFC2680 does not provide too many details as I was expecting. It actually deals with traffic injection as with a security concern:




There are two types of security concerns: potential harm caused by



 the measurements, and potential harm to the measurements. The



 measurements could cause harm because they are active, and inject



 packets into the network. The measurement parameters MUST be



 carefully selected so that the measurements inject trivial amounts of



 additional traffic into the networks they measure. If they inject



 "too much" traffic, they can skew the results of the measurement, and



 in extreme cases cause congestion and denial of service.


‘trivial amounts of additional traffic’ is too vague – I believe that more clear text that deals with the issue as with an operational issue, and makes clear that degradation of service for users is not acceptable if In-Service testing
 policies are applied would be welcome. 


I hope this helps.