Subject: [ippm] draft-morton-ippm-rate-problem

From: Yaakov Stein <[email-masked]>
Date: Tue, 31 Jan 2012 07:47:37 +0000

Al

I read the draft and have a few comments.

My main comment is that I think you should discuss the difference between commissioning tests and live network tests.
In that regard, I think that in section 3 you mean that minimizing test traffic is a key tenet, not a key tenant.
I agree for live testing, but not for commissioning testing where 2544 methods are applicable.
On the other hand, I would like to see some text on the implications of this principle for live testing,
for example pointing out how this can be accomplished and what modifications, if any,
are needed to the current protocols.

In addition, in live testing, to understand the true datarate one needs to add the measurement
datarate to the background datarate. Moreover, in order to minimize the effect on the user,
one needs to know the background datarate and inject active traffic accordingly.
At very least this should be mentioned, and perhaps a discussion on if this limits these measurements
to point to point cases.

Also, live tests are different from commissioning tests in that they are either performed over time
or performed in diagnostic mode. I would appreciate some wording about continuous, periodic, and on-demand use.

One of the two scenarios you highlight is the access network environment, or at least cases where the bottleneck is there.
You then say that in this environment rates are often asymmetric,
but you do not rule out two-way measurements, even saying that it may be favored.
Can you explain why ?
If it is because of the OOF case, perhaps you should insert some guidance.

Also, there can be 2-way measurements that contain enough information to determine
the two one-way parameters (even for delay if clocks are sync'ed up).
Are you ruling this out ? If not, can we have some mention of it ?

Regarding the security section, SLAs are business agreements between the provider and its customer,
and as such can indeed be sensitive. Consider the case where a business is ramping up its operations
in advance of a major (but still secret) launch, and thus commissioning many new services.
Leaking this to a competitor could be disastrous.

Y(J)S

---

From: Al Morton <[email-masked]>
Date: Tue, 31 Jan 2012 09:05:23 -0500

Hi Yaakov,

Regarding your main comment, I certainly agree,

it's worthwhile to sort-out the difference between

the testing scenarios of:

* Service Activation (commissioning) tests,

which are usually conducted prior to releasing the

communications service to the subscriber for use.

* In-Service (live network) tests, where subscriber traffic

may be present on the service entity.

There's a third category, where the communications service

is temporarily removed from service for testing or maintenance,

but this can be combined with Service Activation if we

refer to it as:

* Out-of-Service Testing, where no subscriber traffic is present

on the service entity. This covers commissioning and
maintenance.

Also, while it is always useful to minimize test traffic and the

time needed to conduct tests, I agree that In-Service tests tighten

the constraints. I'll deal with your other comments in the next

version.

Regarding RFC 2544's role in production testing, I refer you to

http://tools.ietf.org/html/draft-ietf-bmwg-2544-as-01

This draft will be in WGLC shortly, and should be discussed on

bmwg's list.

regards,

Al

At 02:47 AM 1/31/2012, Yaakov Stein wrote:

Content-Language: en-US

Content-Type: multipart/alternative;

boundary="_000_07F7D7DED63154409F13298786A2ADC9042D1B8EEXRAD5adradcoil_"

Al

My main comment is that I think you should discuss the difference between
commissioning tests and live network tests.

In that regard, I think that in section 3 you mean that minimizing test
traffic is a key tenet, not a key tenant.

I agree for live testing, but not for commissioning testing where 2544
methods are applicable.

On the other hand, I would like to see some text on the implications of
this principle for live testing,

for example pointing out how this can be accomplished and what
modifications, if any,

In addition, in live testing, to understand the true datarate one needs
to add the measurement

datarate to the background datarate. Moreover, in order to minimize the
effect on the user,

one needs to know the background datarate and inject active traffic
accordingly.

At very least this should be mentioned, and perhaps a discussion on if
this limits these measurements

to point to point cases.

Also, live tests are different from commissioning tests in that they are
either performed over time

or performed in diagnostic mode. I would appreciate some wording about
continuous, periodic, and on-demand use.

One of the two scenarios you highlight is the access network environment,
or at least cases where the bottleneck is there.

but you do not rule out two-way measurements, even saying that it may be
favored.

Can you explain why ?

If it is because of the OOF case, perhaps you should insert some
guidance.

Also, there can be 2-way measurements that contain enough information to
determine

the two one-way parameters (even for delay if clocks are sync'ed
up).

Regarding the security section, SLAs are business agreements between the
provider and its customer,

and as such can indeed be sensitive. Consider the case where a business
is ramping up its operations

in advance of a major (but still secret) launch, and thus commissioning
many new services.

Y(J)S

_______________________________________________

ippm mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ippm