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

From: Steve Baillargeon <[email-masked]>
Date: Wed, 7 Jan 2015 20:03:58 +0000

I don't why there is so much focus on asymmetrical packet sizes when packet sizes may not matter at all or may cause the opposite effect i.e. other operational problems like rate measurement inaccuracy or packet processing overload if small packets are used.
Generating asymmetrical flow rates in different directions or even better, controlling the flow rate in a given direction (as opposed to sending traffic at line rate or attempting to use as much as possible) is a lot more operationally desirable.

Steve B

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: December-18-14 10:50 AM
To: MORTON, ALFRED C (AL); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08

Indeed. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
> Sent: Thursday, December 18, 2014 5:41 PM
> To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08
> 
> 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
> 
> ________________________________________
> From: Romascanu, Dan (Dan) [[email-masked]]
> Sent: Thursday, December 18, 2014 10:31 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,
> 
> 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
> 
> 
> > -----Original Message-----
> > From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
> > Sent: Thursday, December 18, 2014 5:20 PM
> > To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08
> >
> > 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.
> > https://urldefense.proofpoint.com/v2/url?u=http-
> >
> 3A__tools.ietf.org_html_rfc6645&d=AwIFAg&c=BFpWQw8bsuKpl1SgiZH64Q
> >
> &r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=gidqHsa1uFlRnPsB
> > pwAmd1-VWq9YWDrVjyT2xjxFAm8&s=0UDbON-
> > YV4jGVyt8H9aBb1kTlyJmt3bJSwfW-5FZwrM&e=
> >
> > regards,
> > Al
> >
> > ________________________________________
> > From: Romascanu, Dan (Dan) [[email-masked]]
> > Sent: Thursday, December 18, 2014 10:00 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,
> >
> > 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
> >
> >
> > > -----Original Message-----
> > > From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
> > > Sent: Thursday, December 18, 2014 4:34 PM
> > > To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08
> > >
> > > 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
> > > ________________________________________
> > > From: Romascanu, Dan (Dan) [[email-masked]]
> > > Sent: Thursday, December 18, 2014 9:08 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,
> > >
> > > 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:
> > >
> > > 7. Operational Considerations
> > >
> > > 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:
> > >
> > > 7. Operational Considerations
> > >
> > > 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
> > >
> > >
> > > > -----Original Message-----
> > > > From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
> > > > Sent: Thursday, December 18, 2014 3:06 PM
> > > > To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08
> > > >
> > > >
> > > > 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:
> > > >
> > > > 7. Operational Considerations
> > > >
> > > > 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).
> > > >
> > > >
> > > > ________________________________________
> > > > From: Romascanu, Dan (Dan) [[email-masked]]
> > > > Sent: Wednesday, December 17, 2014 9:34 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
> > > >
> > > > 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
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
> > > > > Sent: Wednesday, December 17, 2014 3:39 PM
> > > > > To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> > > > > Cc: [email-masked]
> > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08
> > > > >
> > > > > 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,
> > > > >
> > > > > 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]
> > > > > > Cc: [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 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://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=
> > > > > >
> > > > > >    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
> > > > > > 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:
> > > > > >
> > > > > >    ...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
> > > > > >
> > > > > > 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

_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Joachim Fabini <[email-masked]>
Date: Thu, 08 Jan 2015 09:47:17 +0100

Steve,

you wrote that packet size _may_ not matter. But it does in practice.
The decision what is operationally desirable depends on the measurement
objective _and_ on the network technology. And the latter is the factor
that makes packet size matter.

For symmetrical core network paths the flow rate adaption that you
propose may work as functional equivalent to asymmetrical packet size.
But the closer one gets to the (predominantly asymmetrical) network
access, the more important becomes the capability to use asymmetrical
packet sizes.

First, there is a need to accurately emulate the behavior of
request-reply messaging patterns, where requests and replies differ
substantially in size. Be it SIP, HTTP, FTP, SMTP, whatever: it's a fact
that the request-reply asymmetry is there and that it is substantial.

Second, and my main concern is the testing and monitoring of networks
with on-demand capacity allocation. Here, the network behavior depends
on the exact stream structure (packet size and timing) rather than on
the average stream flow rate. Just one example: depending on your RRC
state, cellular network schedulers may allocate dedicated channels for
transfer of a large packet, whereas a series of small packets could even
reuse existing signaling bearers. Depending on network technology,
configuration and the exact stream (packet size plus inter-packet
delay), the network response may be completly different - at identical
stream rate.

We had many discussion on the IPPM list and I felt that there was
consensus that we need this feature. So, my summary: there IS an
effective need for asymmetrical packet size as we have cases that we can
not overcome with flow rate.
That's why I request and support the asymmetrical packet size feature.

regards
Joachim

Steve Baillargeon wrote: (07.01.2015 21:03)

---

From: Kostas Pentikousis <[email-masked]>
Date: Thu, 8 Jan 2015 16:56:09 +0100

Happy New Year all!

<snip>

| We had many discussion on the IPPM list and I felt that there was consensus
| that we need this feature.

Indeed, that is my recollection as well.

| So, my summary: there IS an effective need for asymmetrical packet size
| as we have cases that we can not overcome with flow rate.
| That's why I request and support the asymmetrical packet size feature.

Second that.

Best regards,

Kostas