Skip to main content

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

Request Review of draft-ietf-ippm-rate-problem
Requested revision 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
I-D 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
Request Last Call review on draft-ietf-ippm-rate-problem by Ops Directorate Assigned
Reviewed revision 08 (document currently at 10)
Result Has issues
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
 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
 policies are applied would be welcome.

I hope this helps.