Last Call Review of draft-ietf-ippm-rate-problem-08
review-ietf-ippm-rate-problem-08-opsdir-lc-romascanu-2014-12-17-00

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

Review
review-ietf-ippm-rate-problem-08-opsdir-lc-romascanu-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




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