Telechat Review of draft-ietf-ippm-rate-problem-09
review-ietf-ippm-rate-problem-09-opsdir-telechat-romascanu-2015-02-17-00

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

network?



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.



Regards,



Dan