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

[Al Morton <[e-mail]>]

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" rel="nofollow"> 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
 
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
 
_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm" rel="nofollow"> https://www.ietf.org/mailman/listinfo/ippm