Subject: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 15 Dec 2014 15:27:13 +0000

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

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 16 Dec 2014 10:05:19 -0500

Hi Dan,

Thanks for your review. Perhaps we can close this
quickly before we both disappear for the holidays
(officially, I'm already gone and writing from
Chicago, where it is unseasonably warm).

We can certainly add details on the operational
impact that test protocols conforming to this memo's
problem statement might cause.  This has been a point
of issue since the earliest days of IPPM, so we should
be able to cover the topic by introducing several references.

If there is some additional point we can cover here,
keeping in mind that measurement methods are a non-goal
of this draft and the operational impact of specific methods
are best dealt with when such methods are specified,
please provide your thoughts.

regards,
Al

The IPPM Framework RFC 2330, section 11.1, says

+    The act of measurement can perturb what is being measured (for
      example, injecting measurement traffic into a network alters the
      congestion level of the network), and repeated periodic
      perturbations can drive a network into a state of synchronization
      (cf. [FJ94]), greatly magnifying what might individually be minor
      effects.

And also, RFC 2330 adopts the term "conservative" for measurement
   methodologies for which:,

   "... the act of measurement does not modify, or only slightly
   modifies, the value of the performance metric the methodology
   attempts to measure."

However, the constraint that measurements strictly retain the 
conservative property is updated in RFC 7312
https://tools.ietf.org/html/rfc7312#section-4.4

   It should be noted that this definition of "conservative" in the
   sense of [RFC2330] depends to a large extent on the measurement
   path's technology and characteristics.  In particular, when deployed
   on reactive paths, subpaths, links or hosts conforming to the
   definition in Section 1.1 of RFC 7312, measurement packets can
   originate capacity (re)allocations.  In addition, small measurement
   flow variations can result in other users on the same path perceiving
   significant variations in measurement results.  Therefore:

      It is not always possible for the method to be conservative.

And, on modern networks with reactive components, any traffic level
will have some impact on other users.  Therefore,  metrics
and their measurement methods should be vetted by the industry
SDOs.  To make this point clear, we should cite 
BMWG RFC (2455 considered harmful on production networks), 
which covers the topic in Section 6
http://tools.ietf.org/html/rfc6815#section-6
and says:

   ...There are no specific methods proposed for
   activation of a packet transfer service in IPPM at this time.  Thus,
   individuals who need to conduct capacity tests on production networks
   should actively participate in standards development to ensure their
   methods receive appropriate industry review and agreement, in the
   IETF or in alternate standards development organizations.

________________________________________
From: OPS-DIR [[email-masked]] On Behalf Of Romascanu, Dan (Dan) [[email-masked]]
Sent: Monday, December 15, 2014 10:27 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [OPS-DIR] OPS-DIR review of draft-ietf-ippm-rate-problem-08

Ready with one issue

Ø
‘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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Dec 2014 10:25:27 +0000

Hi Al,

I kind of disagree that dealing with the operational implications of applying active testing should not be mentioned in the problem statement, but only when specific measurement methods are described. The problem statement document explicitly describes active rate management and includes a section of requirements for test protocol control and generation. I believe that the operational aspects of generating traffic in production networks should be part of the problem statement, and explicitly mentioned, not only in the context of altering measurement results or security considerations. 

Regards,

Dan

> -----Original Message-----
> From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
> Sent: Tuesday, December 16, 2014 5:05 PM
> To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08
> 
> Hi Dan,
> 
> Thanks for your review. Perhaps we can close this quickly before we both
> disappear for the holidays (officially, I'm already gone and writing from
> We can certainly add details on the operational impact that test protocols
> conforming to this memo's problem statement might cause.  This has been a
> point of issue since the earliest days of IPPM, so we should be able to cover
> the topic by introducing several references.
> 
> If there is some additional point we can cover here, keeping in mind that
> measurement methods are a non-goal of this draft and the operational
> impact of specific methods are best dealt with when such methods are
> specified, please provide your thoughts.
> 
> regards,
> Al
> 
> However, the constraint that measurements strictly retain the conservative
> property is updated in RFC 7312
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=AAIF-
> g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd
> rphpBsFA&m=N8q-
> hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=pGbP1qC4qqZh21gJkoiKs
> BmrE3lDnv8ulVOvmjOAlY0&e=
> 
> And, on modern networks with reactive components, any traffic level will
> have some impact on other users.  Therefore,  metrics and their
> measurement methods should be vetted by the industry SDOs.  To make this
> point clear, we should cite BMWG RFC (2455 considered harmful on
> production networks), which covers the topic in Section 6
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=AAIF-
> g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd
> rphpBsFA&m=N8q-
> hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=5fEqW5JnBgSuJYNRNSJS
> mwfu04Mp6cQTBkG_aQNT6qU&e=
> and says:
> 
> 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.
> 
> 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:
> 
> 
> '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

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 17 Dec 2014 08:38:45 -0500

Hi Dan,

I did not say that the operational implications would not be dealt with here.

I'm simply saying that IPPM drafts have done as you have asked many times already,
that is discuss the implications of active measurements, and that we would not
repeat that guidance (but include four references below).  Also, that the measurement
methods would each be vetted on their own, when proposed for standardization.
You need both methods and control/test protocol, and the method solutions 
for this problem are out of scope.

For example, the model-based metrics draft in IPPM introduces the notion of a target rate,
which is a good thing, because it means that the test stream will have an upper bound.
But that is an operational evaluation of a specific method, and OOS for the problem 
statement.

Is this approach more clear?  If not, please suggest some text.

regards,
Al
________________________________________
From: Romascanu, Dan (Dan) [[email-masked]]
Sent: Wednesday, December 17, 2014 5:25 AM
To: MORTON, ALFRED C (AL); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08

Hi Al,

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Dec 2014 14:34:02 +0000

Suggested edit: 

Insert section 7 after the Security considerations section with the following text, and renumber the other sections accordingly: 

7.  Operational Considerations

The increase in traffic levels caused by applying any active measurement of live networks is a concern and needs to be considered and controlled any time active measurements are applied. It is RECOMMENDED that the increase load in the traffic levels in the live networks caused by the active measurement protocols and by the management of the active measurement protocols does not lead to a degradation of the quality of service of the applications running in the networks or the quality of experience of the users of the applications. 

Regards,

Dan

> Sent: Wednesday, December 17, 2014 3:39 PM
> I'm simply saying that IPPM drafts have done as you have asked many times
> already, that is discuss the implications of active measurements, and that we
> would not repeat that guidance (but include four references below).  Also,
> that the measurement methods would each be vetted on their own, when
> proposed for standardization.
> For example, the model-based metrics draft in IPPM introduces the notion of
> a target rate, which is a good thing, because it means that the test stream will
> have an upper bound.
> But that is an operational evaluation of a specific method, and OOS for the
> problem statement.
> 
> I kind of disagree that dealing with the operational implications of applying
> active testing should not be mentioned in the problem statement, but only
> when specific measurement methods are described. The problem statement
> document explicitly describes active rate management and includes a section
> of requirements for test protocol control and generation. I believe that the
> operational aspects of generating traffic in production networks should be
> part of the problem statement, and explicitly mentioned, not only in the
> context of altering measurement results or security considerations.
> 
> Regards,
> 
> Dan
> 
> 
> > Thanks for your review. Perhaps we can close this quickly before we
> > both disappear for the holidays (officially, I'm already gone and
> > writing from Chicago, where it is unseasonably warm).
> >
> > We can certainly add details on the operational impact that test
> > protocols conforming to this memo's problem statement might cause.
> > This has been a point of issue since the earliest days of IPPM, so we
> > should be able to cover the topic by introducing several references.
> >
> > If there is some additional point we can cover here, keeping in mind
> > that measurement methods are a non-goal of this draft and the
> > operational impact of specific methods are best dealt with when such
> > methods are specified, please provide your thoughts.
> >
> > regards,
> > Al
> >
> > will have some impact on other users.  Therefore,  metrics and their
> > measurement methods should be vetted by the industry SDOs.  To make
> > this point clear, we should cite BMWG RFC (2455 considered harmful on
> > 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.
> > 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:
> >
> > * 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.,
> > 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 does not provide too many details as I was
> > expecting. It actually deals with traffic injection as with a security concern:
> >
> >
> > '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

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 18 Dec 2014 08:05:31 -0500

Hi Dan,

I now see better where the disconnect is.  You are looking for
new explicit statements about operational impact. But you are
assuming that the active measurement traffic is *excess* traffic,
beyond some normal level resulting from all Subscriber traffic
and an operator-chosen level of net management traffic.
However, management traffic includes performance measurement traffic
(when the traffic is originated by the operator),
and Subscriber traffic includes active measurement traffic
(when originated by the users). Test-related traffic needs to
be engineered and limited along with all other traffic.

Also, the requirement you wrote "does not lead to degradation"
doesn't seem attainable, so we need to provide cautions
through other means. Sending a single packet results
in larger queue occupations all along its path = degradation.
The packet could be for routing or other network management.

The active measurement traffic is often launched by
subscribers or their authorized users, and there may well be
some degree of degradation to other subscriber's streams.
Your proposed text recommends against this, yet it is no different
from the degradation caused by a user who chooses to watch a
video instead of testing (except that the video session may be longer).

Further, Service providers may be temporarily replacing an
idle user's traffic with active test traffic. Again there may
be some degradation to other subscribers,
but it would typically be no worse than from an
additional user using their service.

There is also the question of test frequency and overall performance:
a user may experience instantaneous packet delay or loss while
another subscriber tests their performance, but then the performance
is at nominal levels for long periods between tests and the
overall performance for a multi-hour session would be satisfactory.

It is clear to me that the operational issues primarily addressed in
previous IPPM work include the affects on other traffic,
the accuracy of the measurements (including preferential treatment
or spoofing of measured streams), and the real or perceived existence
of DoS attacks. Although these are not identified as operations
issues, they are certainly relevant in network operations where
measurement has become a growing part of the management portfolio.
So, we should continue to cite the existing IPPM (and BMWG) guidance
on topics such as conservative measurement, and insert the references
I provided earlier into Section 3 (where you cited the reference
from RFC2680 - note the reference was to the sentence on
high traffic rates, ("too much traffic") so the phrase "trivial
amounts of additional traffic" may be an inadequate specification,
but it was not the intended reference material.

This is the new section I propose:

All forms of testing originate traffic on the network,
through their communications for control and results collection,
or from dedicated measurement packet streams, or both.
Testing traffic primarily falls in one of two categories,
subscriber traffic or network management traffic.
There is an on-going need to engineer networks so that various
forms of traffic are adequately served, and publication of
this memo does not change this need.
Service subscribers and authorized users SHOULD
obtain their network operator's or service provider's permission
before conducting tests. Likewise, a service provider or third
party SHOULD obtain the subscriber's permission to conduct tests,
since they might temporarily reduce service quality.
See section 4.1 of [RFC 3148].

Subscribers, their service providers and network operators,
and sometimes third parties, all seek to measure network performance.
Capacity testing with active traffic often affects the
packet transfer performance of streams traversing shared
components of the test path, to some degree. The
degradation can be minimized by scheduling such
tests infrequently, and restricting the amount of measurement
traffic required to assess capacity metrics. As a result,
occasional short-duration estimates are preferred to
measurements based on frequent file transfers of many Megabytes.
New measurement methodologies intended for standardization
should be evaluated individually for potential operational issues.
However, the scheduled frequency of testing is as important as the
methods used (and schedules are not typically submitted for
standardization).

Sent: Wednesday, December 17, 2014 9:34 AM

Suggested edit:

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Dec 2014 14:08:46 +0000

Hi Al,

We are getting close. Your suggested text seems almost appropriate, with two observations: 

- 'adequately served' is too vague and an explanation of what that means is needed
- I do not believe that we need a reference to RFC 3148. Again, the concern is not about the potential of security attacks (like DoS attacks mentioned in 3148). The intent is to warn well intentioned operators, SPs and end users of the potential dangers of not taking into consideration the effects of active methods, and recommend that they design and deploy accordingly

Suggested edit to your proposal: 

OLD: 

All forms of testing originate traffic on the network, through their communications for control and results collection, or from dedicated measurement packet streams, or both.
Testing traffic primarily falls in one of two categories, subscriber traffic or network management traffic.
There is an on-going need to engineer networks so that various forms of traffic are adequately served, and publication of this memo does not change this need.
Service subscribers and authorized users SHOULD obtain their network operator's or service provider's permission before conducting tests. Likewise, a service provider or third party SHOULD obtain the subscriber's permission to conduct tests, since they might temporarily reduce service quality.
See section 4.1 of [RFC 3148].

Subscribers, their service providers and network operators, and sometimes third parties, all seek to measure network performance.
Capacity testing with active traffic often affects the packet transfer performance of streams traversing shared components of the test path, to some degree. The degradation can be minimized by scheduling such tests infrequently, and restricting the amount of measurement traffic required to assess capacity metrics. As a result, occasional short-duration estimates are preferred to measurements based on frequent file transfers of many Megabytes.
New measurement methodologies intended for standardization should be evaluated individually for potential operational issues.
However, the scheduled frequency of testing is as important as the methods used (and schedules are not typically submitted for standardization).

NEW: 

All forms of testing originate traffic on the network, through their communications for control and results collection, or from dedicated measurement packet streams, or both.
Testing traffic primarily falls in one of two categories, subscriber traffic or network management traffic.
There is an on-going need to engineer networks so that various forms of traffic are adequately served, and publication of this memo does not change this need . It is desirable that the increase load in the traffic levels in the live networks caused by the active measurement protocols and by the management of the active measurement protocols does not lead to any significant degradation of the quality of service of the applications running in the networks or the quality of experience of the users of the applications.
Service subscribers and authorized users SHOULD obtain their network operator's or service provider's permission before conducting tests. Likewise, a service provider or third party SHOULD obtain the subscriber's permission to conduct tests, since they might temporarily reduce service quality.

Subscribers, their service providers and network operators, and sometimes third parties, all seek to measure network performance.
Capacity testing with active traffic often affects the packet transfer performance of streams traversing shared components of the test path, to some degree. The degradation can be minimized by scheduling such tests infrequently, and restricting the amount of measurement traffic required to assess capacity metrics. As a result, occasional short-duration estimates are preferred to measurements based on frequent file transfers of many Megabytes.
New measurement methodologies intended for standardization should be evaluated individually for potential operational issues.
However, the scheduled frequency of testing is as important as the methods used (and schedules are not typically submitted for standardization).

Regards,

Dan

> Sent: Thursday, December 18, 2014 3:06 PM
> I now see better where the disconnect is.  You are looking for new explicit
> statements about operational impact. But you are assuming that the active
> measurement traffic is *excess* traffic, beyond some normal level resulting
> from all Subscriber traffic and an operator-chosen level of net management
> traffic.
> (when the traffic is originated by the operator), and Subscriber traffic
> includes active measurement traffic (when originated by the users). Test-
> related traffic needs to be engineered and limited along with all other traffic.
> 
> doesn't seem attainable, so we need to provide cautions through other
> means. Sending a single packet results in larger queue occupations all along
> its path = degradation.
> The active measurement traffic is often launched by subscribers or their
> authorized users, and there may well be some degree of degradation to
> other subscriber's streams.
> Your proposed text recommends against this, yet it is no different from the
> degradation caused by a user who chooses to watch a video instead of
> testing (except that the video session may be longer).
> 
> Further, Service providers may be temporarily replacing an idle user's traffic
> with active test traffic. Again there may be some degradation to other
> subscribers, but it would typically be no worse than from an additional user
> using their service.
> 
> a user may experience instantaneous packet delay or loss while another
> subscriber tests their performance, but then the performance is at nominal
> levels for long periods between tests and the overall performance for a
> multi-hour session would be satisfactory.
> 
> It is clear to me that the operational issues primarily addressed in previous
> IPPM work include the affects on other traffic, the accuracy of the
> measurements (including preferential treatment or spoofing of measured
> streams), and the real or perceived existence of DoS attacks. Although these
> are not identified as operations issues, they are certainly relevant in network
> operations where measurement has become a growing part of the
> management portfolio.
> So, we should continue to cite the existing IPPM (and BMWG) guidance on
> topics such as conservative measurement, and insert the references I
> provided earlier into Section 3 (where you cited the reference from RFC2680
> - note the reference was to the sentence on high traffic rates, ("too much
> traffic") so the phrase "trivial amounts of additional traffic" may be an
> inadequate specification, but it was not the intended reference material.
> 
> All forms of testing originate traffic on the network, through their
> communications for control and results collection, or from dedicated
> measurement packet streams, or both.
> Testing traffic primarily falls in one of two categories, subscriber traffic or
> network management traffic.
> There is an on-going need to engineer networks so that various forms of
> traffic are adequately served, and publication of this memo does not change
> this need.
> Service subscribers and authorized users SHOULD obtain their network
> operator's or service provider's permission before conducting tests. Likewise,
> a service provider or third party SHOULD obtain the subscriber's permission
> to conduct tests, since they might temporarily reduce service quality.
> Subscribers, their service providers and network operators, and sometimes
> third parties, all seek to measure network performance.
> Capacity testing with active traffic often affects the packet transfer
> performance of streams traversing shared components of the test path, to
> some degree. The degradation can be minimized by scheduling such tests
> infrequently, and restricting the amount of measurement traffic required to
> assess capacity metrics. As a result, occasional short-duration estimates are
> preferred to measurements based on frequent file transfers of many
> Megabytes.
> New measurement methodologies intended for standardization should be
> evaluated individually for potential operational issues.
> However, the scheduled frequency of testing is as important as the methods
> used (and schedules are not typically submitted for standardization).
> 
> 
> Insert section 7 after the Security considerations section with the following
> text, and renumber the other sections accordingly:
> 
> The increase in traffic levels caused by applying any active measurement of
> live networks is a concern and needs to be considered and controlled any
> time active measurements are applied. It is RECOMMENDED that the
> increase load in the traffic levels in the live networks caused by the active
> measurement protocols and by the management of the active measurement
> protocols does not lead to a degradation of the quality of service of the
> applications running in the networks or the quality of experience of the users
> of the applications.
> 
> Regards,
> 
> Dan
> 
> 
> > I'm simply saying that IPPM drafts have done as you have asked many
> > times already, that is discuss the implications of active
> > measurements, and that we would not repeat that guidance (but include
> > four references below).  Also, that the measurement methods would each
> > be vetted on their own, when proposed for standardization.
> > You need both methods and control/test protocol, and the method
> > solutions for this problem are out of scope.
> >
> > For example, the model-based metrics draft in IPPM introduces the
> > notion of a target rate, which is a good thing, because it means that
> > the test stream will have an upper bound.
> > But that is an operational evaluation of a specific method, and OOS
> > for the problem statement.
> >
> > I kind of disagree that dealing with the operational implications of
> > applying active testing should not be mentioned in the problem
> > statement, but only when specific measurement methods are described.
> > The problem statement document explicitly describes active rate
> > management and includes a section of requirements for test protocol
> > control and generation. I believe that the operational aspects of
> > generating traffic in production networks should be part of the
> > problem statement, and explicitly mentioned, not only in the context of
> altering measurement results or security considerations.
> >
> > Regards,
> >
> > Dan
> >
> >
> > > This has been a point of issue since the earliest days of IPPM, so
> > > we should be able to cover the topic by introducing several references.
> > >
> > > this point clear, we should cite BMWG RFC (2455 considered harmful
> > > on production networks), which covers the topic in Section 6
> > > I have reviewed this document as part of the Operational
> > > directorate's ongoing effort to review all IETF documents being processed
> by the IESG.
> > > * How will the new protocol impact the behavior of other protocols
> > > in the network? Will it impact performance (e.g.,
> > > '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

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 18 Dec 2014 09:34:01 -0500

Hi Dan,

When you added the sentence:
  It is desirable that the increase load in the traffic levels in the live networks caused by the active measurement protocols
  and by the management of the active measurement protocols does not lead to any significant degradation of the
  quality of service of the applications running in the networks or the quality of experience of the users of the applications.

You have continued to assume that the measurement traffic is excess traffic ("increased load") and it needs
new requirements.  As I said, one subscriber's traffic can degrade the traffic of another subscriber,
whether the degradation is significant or not depends on too many factors to go into here,
but one or both of the subscribers could be running tests related to this problem statement.
Operators engineer their management traffic load, including measurement-related traffic.

There is simply traffic from many sources, all to be engineered. Operations and Engineering as usual.
The section has provided specific cautions and guidance for operators and users.  No need for
new implementation rules, IMO.

regards,
Al
Sent: Thursday, December 18, 2014 9:08 AM

Hi Al,

OLD:

NEW:

Regards,

Dan

> > > ?  Section 5 of [RFC2680] lists the problems with high
> > > ?  is the tendency for measurement traffic to skew the results, followed
> > > ?  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.
> > >
> > > ?

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Dec 2014 15:00:11 +0000

Hi Al,

But this IS increased traffic, as standardized rate measurements were not in practice until now, hence the need for new standards, including the ones in IPPM. Yes, it's management traffic, but the very issue an operational considerations sections aims is to draw the attention that people that design an deploy new protocols need to factor in the overall effects of new protocols traffic on the networks. New protocols and methods to measure rate generate new traffic, active measurement causes more new traffic than passive methods, all this needs to be considered. The goal of this text is exactly to make sure and explicit that operators engineer their management traffic load, including measurement-related traffic.

Regards,

Dan

> Sent: Thursday, December 18, 2014 4:34 PM
>   It is desirable that the increase load in the traffic levels in the live networks
> caused by the active measurement protocols
>   and by the management of the active measurement protocols does not
> lead to any significant degradation of the
>   quality of service of the applications running in the networks or the quality
> of experience of the users of the applications.
> 
> You have continued to assume that the measurement traffic is excess traffic
> ("increased load") and it needs new requirements.  As I said, one subscriber's
> traffic can degrade the traffic of another subscriber, whether the
> degradation is significant or not depends on too many factors to go into here,
> The section has provided specific cautions and guidance for operators and
> users.  No need for new implementation rules, IMO.
> 
> regards,
> Al
> - I do not believe that we need a reference to RFC 3148. Again, the concern is
> not about the potential of security attacks (like DoS attacks mentioned in
> 3148). The intent is to warn well intentioned operators, SPs and end users of
> the potential dangers of not taking into consideration the effects of active
> methods, and recommend that they design and deploy accordingly
> 
> this need . It is desirable that the increase load in the traffic levels in the live
> networks caused by the active measurement protocols and by the
> management of the active measurement protocols does not lead to any
> significant degradation of the quality of service of the applications running in
> the networks or the quality of experience of the users of the applications.
> > I now see better where the disconnect is.  You are looking for new
> > explicit statements about operational impact. But you are assuming
> > that the active measurement traffic is *excess* traffic, beyond some
> > normal level resulting from all Subscriber traffic and an
> > operator-chosen level of net management traffic.
> > (when the traffic is originated by the operator), and Subscriber
> > traffic includes active measurement traffic (when originated by the
> > users). Test- related traffic needs to be engineered and limited along with
> all other traffic.
> >
> > means. Sending a single packet results in larger queue occupations all
> > along its path = degradation.
> > The active measurement traffic is often launched by subscribers or
> > their authorized users, and there may well be some degree of
> > degradation to other subscriber's streams.
> > from the degradation caused by a user who chooses to watch a video
> > instead of testing (except that the video session may be longer).
> >
> > Further, Service providers may be temporarily replacing an idle user's
> > traffic with active test traffic. Again there may be some degradation
> > to other subscribers, but it would typically be no worse than from an
> > subscriber tests their performance, but then the performance is at
> > nominal levels for long periods between tests and the overall
> > performance for a multi-hour session would be satisfactory.
> >
> > previous IPPM work include the affects on other traffic, the accuracy
> > of the measurements (including preferential treatment or spoofing of
> > measured streams), and the real or perceived existence of DoS attacks.
> > Although these are not identified as operations issues, they are
> > certainly relevant in network operations where measurement has become
> > a growing part of the management portfolio.
> > I provided earlier into Section 3 (where you cited the reference from
> > RFC2680
> > traffic") so the phrase "trivial amounts of additional traffic" may be
> > an inadequate specification, but it was not the intended reference
> material.
> >
> > There is an on-going need to engineer networks so that various forms
> > of traffic are adequately served, and publication of this memo does
> > not change this need.
> > operator's or service provider's permission before conducting tests.
> > Likewise, a service provider or third party SHOULD obtain the
> > subscriber's permission to conduct tests, since they might temporarily
> reduce service quality.
> > Subscribers, their service providers and network operators, and
> > sometimes third parties, all seek to measure network performance.
> > performance of streams traversing shared components of the test path,
> > to some degree. The degradation can be minimized by scheduling such
> > tests infrequently, and restricting the amount of measurement traffic
> > required to assess capacity metrics. As a result, occasional
> > short-duration estimates are preferred to measurements based on
> > frequent file transfers of many Megabytes.
> > Insert section 7 after the Security considerations section with the
> > following text, and renumber the other sections accordingly:
> >
> > The increase in traffic levels caused by applying any active
> > measurement of live networks is a concern and needs to be considered
> > and controlled any time active measurements are applied. It is
> > RECOMMENDED that the increase load in the traffic levels in the live
> > networks caused by the active measurement protocols and by the
> > management of the active measurement protocols does not lead to a
> > degradation of the quality of service of the applications running in
> > the networks or the quality of experience of the users of the applications.
> >
> > Regards,
> >
> > Dan
> >
> >
> > > measurements, and that we would not repeat that guidance (but
> > > include four references below).  Also, that the measurement methods
> > > would each be vetted on their own, when proposed for standardization.
> > > notion of a target rate, which is a good thing, because it means
> > > that the test stream will have an upper bound.
> > > > Thanks for your review. Perhaps we can close this quickly before
> > > > we both disappear for the holidays (officially, I'm already gone
> > > > and writing from Chicago, where it is unseasonably warm).
> > > >
> > > > If there is some additional point we can cover here, keeping in
> > > > mind that measurement methods are a non-goal of this draft and the
> > > > operational impact of specific methods are best dealt with when
> > > > such methods are specified, please provide your thoughts.
> > > >
> > > > regards,
> > > > Al
> > > >
> > > > +    The act of measurement can perturb what is being measured
> > > > + (for
> > > > And, on modern networks with reactive components, any traffic
> > > > level will have some impact on other users.  Therefore,  metrics
> > > > SDOs.  To make this point clear, we should cite BMWG RFC (2455
> > > > considered harmful on production networks), which covers the topic
> > > > in Section 6
> > > > From: OPS-DIR [[email-masked]] On Behalf Of Romascanu,
> > > > Dan
> > > > (Dan) [[email-masked]]
> > > > Document editors and WG chairs should treat these comments just
> > > > like any other last call comments.
> > > >
> > > > Ready with one issue
> > > >
> > > > The following reference to the effects of the high level traffic
> > > > is not sufficient
> > > > IMO:
> > > >
> > > >

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 18 Dec 2014 10:19:58 -0500

Hi Dan,

you wrote:
   The goal of this text is exactly to make sure and explicit that operators engineer their management traffic load,
    including measurement-related traffic.

The text does that now, adding new considerations. The audience of this section are the operators.
We now know the issue, potential for degradation. Do we need further implementation guidance?
I don't think so.

If the root of your concern is the comparison between active and passive, then you have many
more factors to consider than traffic. One is "What happens to forwarding capacity when I turn on NetFlow?"
That's a question we helped operators try to answer in BMWG's  RFC 6645.
http://tools.ietf.org/html/rfc6645

regards,
Al

Sent: Thursday, December 18, 2014 10:00 AM

Hi Al,

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Dec 2014 15:31:24 +0000

Hi Al,

I will not further insist on fine tuning the text this I-D, as I do not like keeping one document 'hostage' even for such important issues, when we came that close. 

I believe that making the text more clear would have been useful, but we almost walked the extra mile with the inclusion of the new section, and that's fine by now. 

Regards,

Dan

> Sent: Thursday, December 18, 2014 5:20 PM
> If the root of your concern is the comparison between active and passive,
> then you have many more factors to consider than traffic. One is "What
> happens to forwarding capacity when I turn on NetFlow?"
> 3A__tools.ietf.org_html_rfc6645&d=AwIFAg&c=BFpWQw8bsuKpl1SgiZH64Q
> &r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=gidqHsa1uFlRnPsB
> pwAmd1-VWq9YWDrVjyT2xjxFAm8&s=0UDbON-
> YV4jGVyt8H9aBb1kTlyJmt3bJSwfW-5FZwrM&e=
> 
> regards,
> Al
> 
> But this IS increased traffic, as standardized rate measurements were not in
> practice until now, hence the need for new standards, including the ones in
> IPPM. Yes, it's management traffic, but the very issue an operational
> considerations sections aims is to draw the attention that people that design
> an deploy new protocols need to factor in the overall effects of new
> protocols traffic on the networks. New protocols and methods to measure
> rate generate new traffic, active measurement causes more new traffic than
> passive methods, all this needs to be considered. The goal of this text is
> exactly to make sure and explicit that operators engineer their management
> traffic load, including measurement-related traffic.
> 
> Regards,
> 
> Dan
> 
> 
> >   It is desirable that the increase load in the traffic levels in the
> > live networks caused by the active measurement protocols
> >   quality of service of the applications running in the networks or
> > the quality of experience of the users of the applications.
> >
> > You have continued to assume that the measurement traffic is excess
> > traffic ("increased load") and it needs new requirements.  As I said,
> > one subscriber's traffic can degrade the traffic of another
> > subscriber, whether the degradation is significant or not depends on
> > too many factors to go into here, but one or both of the subscribers
> > could be running tests related to this problem statement.
> > Operators engineer their management traffic load, including
> > measurement- related traffic.
> >
> > The section has provided specific cautions and guidance for operators
> > and users.  No need for new implementation rules, IMO.
> >
> > regards,
> > Al
> > - I do not believe that we need a reference to RFC 3148. Again, the
> > concern is not about the potential of security attacks (like DoS
> > attacks mentioned in 3148). The intent is to warn well intentioned
> > operators, SPs and end users of the potential dangers of not taking
> > into consideration the effects of active methods, and recommend that
> > they design and deploy accordingly
> >
> > not change this need . It is desirable that the increase load in the
> > traffic levels in the live networks caused by the active measurement
> > protocols and by the management of the active measurement protocols
> > does not lead to any significant degradation of the quality of service
> > of the applications running in the networks or the quality of experience of
> the users of the applications.
> > > doesn't seem attainable, so we need to provide cautions through
> > > other means. Sending a single packet results in larger queue
> > > occupations all along its path = degradation.
> > > Further, Service providers may be temporarily replacing an idle
> > > user's traffic with active test traffic. Again there may be some
> > > degradation to other subscribers, but it would typically be no worse
> > > than from an additional user using their service.
> > >
> > > is at nominal levels for long periods between tests and the overall
> > > previous IPPM work include the affects on other traffic, the
> > > accuracy of the measurements (including preferential treatment or
> > > spoofing of measured streams), and the real or perceived existence of
> DoS attacks.
> > > certainly relevant in network operations where measurement has
> > > become a growing part of the management portfolio.
> > > on topics such as conservative measurement, and insert the
> > > references I provided earlier into Section 3 (where you cited the
> > > reference from
> > > RFC2680
> > > traffic") so the phrase "trivial amounts of additional traffic" may
> > > be an inadequate specification, but it was not the intended
> > > reference
> > material.
> > >
> > > Capacity testing with active traffic often affects the packet
> > > transfer performance of streams traversing shared components of the
> > > test path, to some degree. The degradation can be minimized by
> > > scheduling such tests infrequently, and restricting the amount of
> > > measurement traffic required to assess capacity metrics. As a
> > > result, occasional short-duration estimates are preferred to
> > > > I did not say that the operational implications would not be dealt
> > > > with
> > here.
> > > >
> > > > I'm simply saying that IPPM drafts have done as you have asked
> > > > many times already, that is discuss the implications of active
> > > > include four references below).  Also, that the measurement
> > > > But that is an operational evaluation of a specific method, and
> > > > OOS for the problem statement.
> > > >
> > > > I kind of disagree that dealing with the operational implications
> > > > of applying active testing should not be mentioned in the problem
> > > > management and includes a section of requirements for test
> > > > protocol control and generation. I believe that the operational
> > > > aspects of generating traffic in production networks should be
> > > > part of the problem statement, and explicitly mentioned, not only
> > > > in the context of
> > > > > This has been a point of issue since the earliest days of IPPM,
> > > > > so we should be able to cover the topic by introducing several
> references.
> > > > >
> > > > > mind that measurement methods are a non-goal of this draft and
> > > > > the operational impact of specific methods are best dealt with
> > > > > when such methods are specified, please provide your thoughts.
> > > > >
> > > > > regards,
> > > > > Al
> > > > >
> > > > > considered harmful on production networks), which covers the
> > > > > topic in Section 6
> > > > > protocol or protocol extensions. It does however contain a
> > > > > problem statement for test protocols conducting access rate
> > > > > measurement in
> > > > productions networks.
> > > > > Section
> > 2.5.
> > > > > expecting. It actually deals with traffic injection as with a
> > > > > security
> > concern:
> > > > >
> > > > >
> > > > > ?  There are two types of security concerns: potential harm
> > > > > caused by
> > > > >
> > > > > 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

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 18 Dec 2014 10:40:55 -0500

Hi Dan,

Thanks for your compromise.

On the topic of "increased" traffic:

This document introduces a RECOMMENDATION  for test protocols
to add the capability generate asymmetrical packet sizes in different directions,
something that the current protocols cannot do
(but they can certainly be used to make rate measurements now).

In fact, this asymmetric size feature REDUCES the test traffic load.
Perhaps you would like this mentioned as a desirable feature from an
operations perspective?

regards,
Al

Sent: Thursday, December 18, 2014 10:31 AM

Hi Al,

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Dec 2014 15:50:11 +0000

Indeed. 

Thanks and Regards,

Dan

> Sent: Thursday, December 18, 2014 5:41 PM
> This document introduces a RECOMMENDATION  for test protocols to add
> the capability generate asymmetrical packet sizes in different directions,
> something that the current protocols cannot do (but they can certainly be
> used to make rate measurements now).
> 
> I will not further insist on fine tuning the text this I-D, as I do not like keeping
> one document 'hostage' even for such important issues, when we came that
> close.
> 
> I believe that making the text more clear would have been useful, but we
> almost walked the extra mile with the inclusion of the new section, and that's
> fine by now.
> 
> Regards,
> 
> Dan
> 
> 
> >    The goal of this text is exactly to make sure and explicit that
> > operators engineer their management traffic load,
> > If the root of your concern is the comparison between active and
> > passive, then you have many more factors to consider than traffic. One
> > is "What happens to forwarding capacity when I turn on NetFlow?"
> > But this IS increased traffic, as standardized rate measurements were
> > not in practice until now, hence the need for new standards, including
> > the ones in IPPM. Yes, it's management traffic, but the very issue an
> > operational considerations sections aims is to draw the attention that
> > people that design an deploy new protocols need to factor in the
> > overall effects of new protocols traffic on the networks. New
> > protocols and methods to measure rate generate new traffic, active
> > measurement causes more new traffic than passive methods, all this
> > needs to be considered. The goal of this text is exactly to make sure
> > and explicit that operators engineer their management traffic load,
> > >   It is desirable that the increase load in the traffic levels in
> > > the live networks caused by the active measurement protocols
> > > traffic ("increased load") and it needs new requirements.  As I
> > > said, one subscriber's traffic can degrade the traffic of another
> > > The section has provided specific cautions and guidance for
> > > operators and users.  No need for new implementation rules, IMO.
> > >
> > > regards,
> > > Al
> > > does not lead to any significant degradation of the quality of
> > > service of the applications running in the networks or the quality
> > > of experience of
> > > > that the active measurement traffic is *excess* traffic, beyond
> > > > some normal level resulting from all Subscriber traffic and an
> > > > traffic includes active measurement traffic (when originated by
> > > > the users). Test- related traffic needs to be engineered and
> > > > limited along with
> > > all other traffic.
> > > >
> > > > degradation to other subscribers, but it would typically be no
> > > > worse than from an additional user using their service.
> > > >
> > > > another subscriber tests their performance, but then the
> > > > performance is at nominal levels for long periods between tests
> > > > and the overall performance for a multi-hour session would be
> satisfactory.
> > > >
> > > > It is clear to me that the operational issues primarily addressed
> > > > in previous IPPM work include the affects on other traffic, the
> > > > So, we should continue to cite the existing IPPM (and BMWG)
> > > > guidance on topics such as conservative measurement, and insert
> > > > the references I provided earlier into Section 3 (where you cited
> > > > the reference from
> > > > RFC2680
> > > > traffic") so the phrase "trivial amounts of additional traffic"
> > > > may be an inadequate specification, but it was not the intended
> > > > reference
> > > material.
> > > >
> > > > All forms of testing originate traffic on the network, through
> > > > their communications for control and results collection, or from
> > > > dedicated measurement packet streams, or both.
> > > > forms of traffic are adequately served, and publication of this
> > > > memo does not change this need.
> > > > Service subscribers and authorized users SHOULD obtain their
> > > > network operator's or service provider's permission before conducting
> tests.
> > > > transfer performance of streams traversing shared components of
> > > > the test path, to some degree. The degradation can be minimized by
> > > > Insert section 7 after the Security considerations section with
> > > > the following text, and renumber the other sections accordingly:
> > > >
> > > > measurement of live networks is a concern and needs to be
> > > > considered and controlled any time active measurements are
> > > > applied. It is RECOMMENDED that the increase load in the traffic
> > > > levels in the live networks caused by the active measurement
> > > > protocols and by the management of the active measurement
> > > > protocols does not lead to a degradation of the quality of service
> > > > of the applications running in the networks or the quality of
> > > > experience of the users of the
> > applications.
> > > >
> > > > Regards,
> > > >
> > > > Dan
> > > >
> > > >
> > > > > I did not say that the operational implications would not be
> > > > > dealt with
> > > here.
> > > > >
> > > > > For example, the model-based metrics draft in IPPM introduces
> > > > > the notion of a target rate, which is a good thing, because it
> > > > > means that the test stream will have an upper bound.
> > > > > I kind of disagree that dealing with the operational
> > > > > implications of applying active testing should not be mentioned
> > > > > in the problem statement, but only when specific measurement
> > > > > methods are
> > described.
> > > > > part of the problem statement, and explicitly mentioned, not
> > > > > only in the context of
> > > > > > Thanks for your review. Perhaps we can close this quickly
> > > > > > before we both disappear for the holidays (officially, I'm
> > > > > > already gone and writing from Chicago, where it is unseasonably
> warm).
> > > > > >
> > > > > > We can certainly add details on the operational impact that
> > > > > > test protocols conforming to this memo's problem statement might
> cause.
> > > > > > This has been a point of issue since the earliest days of
> > > > > > IPPM, so we should be able to cover the topic by introducing
> > > > > > several
> > references.
> > > > > >
> > > > > > If there is some additional point we can cover here, keeping
> > > > > > in mind that measurement methods are a non-goal of this draft
> > > > > > and the operational impact of specific methods are best dealt
> > > > > > with when such methods are specified, please provide your
> thoughts.
> > > > > >
> > > > > > regards,
> > > > > > Al
> > > > > >
> > > > > > level will have some impact on other users.  Therefore,
> > > > > > metrics and their measurement methods should be vetted by the
> > > > > > industry SDOs.  To make this point clear, we should cite BMWG
> > > > > > RFC (2455 considered harmful on production networks), which
> > > > > > covers the topic in Section 6
> > > > > >    individuals who need to conduct capacity tests on
> > > > > > production
> > > networks
> > > > > > From: OPS-DIR [[email-masked]] On Behalf Of
> > > > > > Romascanu, Dan
> > > > > > 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
> > > > > > 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:
> > > > > >
> > > > > > 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:
> > > > > >
> > > > > >
> > > > > > ?  is the tendency for measurement traffic to skew the
> > > > > > results,
> > followed
> > > > > > 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:
> > > > > >
> > > > > >
> > > > > > ?   carefully selected so that the measurements inject trivial
> amounts
> > of
> > > > > >
> > > > > > '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