Re: [lmap] degrees of Measurement Suppression

[Charles Cook <[e-mail]>]

Just some thoughts...

I just finished reading the framework draft.  As written, it talks about
large-scale measurements, but does not really define the magnitude of
large-scale.  It also states that end-users can request that
measurements be done on their behalf, and that measurements can
potentially run indefinitely.  Although not mentioned in the framework,
a service provider could offer a measurement service that under normal
conditions runs essentially continuously when the end user is not
transmitting their own data.    In other words, we don't know what the
upper bound is on what can be running in the network as measurements. 
Consequently, we need to assume worst case. 

Using the national emergency analogy, I suggest that during an emergency
is when you want to do everything possible to improve communications as
much as possible.  It is essential that there be a mechanism that
eliminates measurements almost immediately, if necessary.  If
"large-scale" measurements are being done, it probably is not scalable
for a Controller to send an individual message to each MA.  Furthermore,
the emergency may directly affect the Controller and prevent it from
sending messages.  The MA needs an easy way to assess the state of the
network and respond accordingly.  It is relatively easy for the MA to
poll the network before starting a measurement, and then continue to
periodically poll during the measurement.  If there is no response, the
MA assumes there is a network issue and terminates the measurement. 

There probably needs to be more than a go / no-go response from the
network to account for varying degrees of the condition of the network. 
There probably needs to be at least three states, but if there are too
many states it complicates the measurement system.  If there are three
states then an MA can run the measurement, terminate the measurement, or
complete certain measurements and then cease further measurements until
the appropriate network conditions are restored.  MA behavior in
response to network conditions to a certain extent could be
pre-provisioned in the MA by the operational domain owner responsible
for the MA.  There may also be some benefit in dictating behavior in the
Instruction from the Controller.

Charles

On 12/10/2013 3:39 PM, Steve Miller wrote:
>    If we are testing at a rate where leaving the tests running during a national emergency will make a meaningful difference as to whether or not lives are saved, we shouldn't be testing at that rate even during normal operation.  Relying on the ability to turn anything off -- in an active manner at least -- during an emergency seems like something we should avoid: I'd think that anyone who's experienced making a phone call just after a natural disaster would be able to testify as to the flakiness of any communications medium under those circumstances.
>
>    A key (and maybe *the* key) element here is that in many cases the time you must want to hit the big red off switch is the time at which you are least able to communicate with the MAs.
>
>    The other autoshutdown stuff that's been discussed so far would give people the flexibility to implement the only policy that truly seems important: the one that disables measurements after N seconds/minutes/hours/days in which the MA can't reach the controller.  It's been my experience that no matter how important that seems on paper, it ends up being much, much less critical than it seems in the Real World.  Still, leaving this binary on/off level of control in place makes some sense: it's easy to code, it's pretty innocuous, the additional load on the controller infrastructure shouldn't be that bad, and it avoids the "three million old devices hammering some poor destination that belongs to the people who bought some defunct ISP" problem.  It's also been my experience that even that level of control isn't needed and can in fact cause problems of its own, but I recognize that this scenario is a little different.  I still think we should not overcomplicate things.
>

> 	-Steve
> 	(who still needs to read the updated I-Ds, hopefully early next week, sorry)
>
> On Tue, Dec 10, 2013 at 10:16:58PM +0000, Bugenhagen, Michael K wrote:
>> I concur with Barbara -
>>
>>   Stated a bit differently - If LMAP says put this probe on everything (Part of the introduction statement)...
>>
>> Then 
>>
>> 1)  They will want a suppression method that allows them to disable it in case of national emergency - saving lives via emergency communication takes priority in their minds.
>>     So they typically will ask for 2 each Safety breaks.
>> 		1 from the controller
>> 		A second from a element controller or whatever configures the element in the first place.   
>>
>>    These "MA unavailable" states should also be recorded for transparency sake.
>>
>>
>> 2)  Op's folks like to test - even when things are going bad.. otherwise fault isolation is hard to do.
>>
>> 	So suppression should have 3 levels (again this goes back to everyone has a probe) -
>> 	Green = do as you will (test anything)
>> 	Yellow - don't load anything - restrict testing that will load the network, or kick up CPU cycles ...but allow fault testing (NO Saturation tests, ....)(
>> 	RED - Stop, don't pass go, ... ADHOC testing only
>>
>>
>> If USE case 1 is the ISP - not adopting those types of Op's requirements would get a significant amount of pushback on the implementation side.
>>
>> Regards,
>> Mike
>>
>>
>>
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of STARK, BARBARA H
>> Sent: Tuesday, November 12, 2013 10:50 AM
>> To: [e-mail]
>> Subject: [lmap] degrees of Measurement Suppression
>>
>> A number of providers have discussed a model of Measurement Suppression that supports more granular degrees of suppression (other than just suppress and don't suppress). Michael Bugenhagen presented the original version of this model, and he said it would be ok if I brought it up to IETF.
>>
>> Following are highlights of the proposal (with some modifications I've included as a result of additional discussion):
>>
>> 1. Measurement Methods (or perhaps Tasks) have a configurable parameter that indicates whether the Controller operator considers them to be "critical for OAM", "not critical, but not resource intensive", and "not critical and resource intensive".
>>
>> 2. The Controller can specify degrees of Measurement Suppression, which should include: halt all non-critical tasks immediately but allow OAM tasks; halt resource-intensive tasks immediately but allow non-resource-intensive tasks; finish resource intensive tasks but do not start new resource-intensive tasks and allow all non-resource-intensive tasks; allow all tasks.
>>
>> 3. It may also be possible for the unspecified bootstrap mechanism to instruct the MA to suppress measurements. Where multiple channels exist for Measurement Suppression (e.g., Controller and bootstrap), the MA is to use the most restrictive setting.
>>
>> Barbara
>>
>>
>> _______________________________________________
>> lmap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lmap
>> _______________________________________________
>> lmap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lmap
> _______________________________________________
> lmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lmap

-- 

Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  [phone]  Fax:  [phone]
[e-mail]