Subject: [lmap] Comment on LMAP 06 Suppression

From: Charles Cook <[email-masked]>
Date: Tue, 17 Jun 2014 10:47:21 -0600

A comment regarding ending immediately and completing a Measurement Task
in response to a Suppress.

   o  a demand that the MA ends its on-going Active Measurement Task(s)
      immediately (and deletes the associated partial Measurement
      Result(s)).  If absent, the MA completes on-going Measurement
      Tasks.

I believe the logic of this option needs to be reversed.  The default if
the option is absent needs to be that the Measurement Task will end
immediately, because this will be the more common case.  I don't think
we want to require an option to be set to immediately end all unflagged
Measurement Tasks when a simple Suppress is sent.  Perhaps something
like this would work.

o  a demand that the MA competes its on-going Active Measurement Task(s).

      If absent, the MA ends on-going Measurement

      Tasks immediately (and deletes the associated partial Measurement

      Result(s)).

Charles

-- 

Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
[email-masked]

---

From: <[email-masked]>
Date: Thu, 19 Jun 2014 13:33:11 +0100

Charles,

I think it's marginally better to keep as-is, so by default suppression doesn't impact on-going measurement tasks.
Reason is that it's very simple for a MA to stop new Tasks starting (it barely has to do anything), but it may be a bit harder for it to stop on-going Tasks (at least if it wants to make sure they stop cleanly, perhaps clean up state in the MA, perhaps shut down connections with the remote server etc).
I guess also it might have a task that essentially runs for ever, such as a basic connectivity check - but of course this depends how the operator has defined their tasks and schedules.

Thanks
phil

From: lmap [mailto:[email-masked]] On Behalf Of Charles Cook
Sent: 17 June 2014 17:47
To: [email-masked]'
Subject: [lmap] Comment on LMAP 06 Suppression

A comment regarding ending immediately and completing a Measurement Task in response to a Suppress.

I believe the logic of this option needs to be reversed.  The default if the option is absent needs to be that the Measurement Task will end immediately, because this will be the more common case.  I don't think we want to require an option to be set to immediately end all unflagged Measurement Tasks when a simple Suppress is sent.  Perhaps something like this would work.

Charles

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

[email-masked]<mailto:[email-masked]>

---

From: Charles Cook <[email-masked]>
Date: Thu, 19 Jun 2014 06:51:54 -0600

Phil,

I'm still not convinced that we should keep the default behavior as is. 
Particularly because we can set a flag for a Measurement Task to ignore
suppression.

The real question is which is the more common case:  that a Measurement
Task needs to stop completely or that a Measurement Task can continue to
completion?  People may have differing views on this.  My view is that a
Suppression is intended to stop the generation of traffic because there
is a Network emergency of some sort.  That implies stopping the
Measurement Task immediately.  If it is not a Network Emergency, then
the Controller can simply update the Measurement Task Schedule to change
when a Measurement Task ends.  I also believe that Measurement Tasks
that are expected to run to completion can simply have the the ignore
Suppression flag set. 

Consequently, I believe the default response should be reversed so that
an optional parameter does not need to be set in order to cause a
Measurement Task to cease immediately.

Charles

On 6/19/2014 6:33 AM, [email-masked] wrote:
>
> Charles,
>
>  
>
> I think it's marginally better to keep as-is, so by default
> suppression doesn't impact on-going measurement tasks.
>
> Reason is that it's very simple for a MA to stop new Tasks starting
> (it barely has to do anything), but it may be a bit harder for it to
> stop on-going Tasks (at least if it wants to make sure they stop
> cleanly, perhaps clean up state in the MA, perhaps shut down
> connections with the remote server etc).
>
> I guess also it might have a task that essentially runs for ever, such
> as a basic connectivity check -- but of course this depends how the
> operator has defined their tasks and schedules.
>
>  
>
> Thanks
>
> phil
>
>  
>
>  
>
> *From:*lmap [mailto:[email-masked]] *On Behalf Of *Charles Cook
> *Sent:* 17 June 2014 17:47
> *To:* [email-masked]'
> *Subject:* [lmap] Comment on LMAP 06 Suppression
>
>  
>
> I believe the logic of this option needs to be reversed.  The default
> if the option is absent needs to be that the Measurement Task will end
> we want to require an option to be set to immediately end all
> unflagged Measurement Tasks when a simple Suppress is sent.  Perhaps
> something like this would work.
>
>  
>
> [email-masked] <mailto:[email-masked]>

-- 

Charles Cook 
Principal Architect
Network

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 19 Jun 2014 09:39:34 -0400

Charles,

The currently-defined Suppression has a "Panic-button" capability
which satisfies your case of a Network Emergency. Perhaps we could
make this more clear.

If we cast the message starting from Panic/Full-Stop, it seems more
unexpected to add options for only on-going tasks, or only certain tasks,
or start times, etc. IMO, it's called Suppression now to allow for
different degrees of measurement deletion, all the way up to full stop.

It also seems tom that it's easier to resume (Unsuppress) the measurement
schedule from the current definition of Suppression. Long-term or On-going
measurement tasks would probably need to be re-scheduled after
a Panic/Full-Stop is withdrawn.

Al

From: lmap [mailto:[email-masked]] On Behalf Of Charles Cook
Sent: Thursday, June 19, 2014 8:52 AM
To: [email-masked]; [email-masked]
Subject: Re: [lmap] Comment on LMAP 06 Suppression

Phil,

I'm still not convinced that we should keep the default behavior as is.  Particularly because we can set a flag for a Measurement Task to ignore suppression.

The real question is which is the more common case:  that a Measurement Task needs to stop completely or that a Measurement Task can continue to completion?  People may have differing views on this.  My view is that a Suppression is intended to stop the generation of traffic because there is a Network emergency of some sort.  That implies stopping the Measurement Task immediately.  If it is not a Network Emergency, then the Controller can simply update the Measurement Task Schedule to change when a Measurement Task ends.  I also believe that Measurement Tasks that are expected to run to completion can simply have the the ignore Suppression flag set.

Consequently, I believe the default response should be reversed so that an optional parameter does not need to be set in order to cause a Measurement Task to cease immediately.

Charles

On 6/19/2014 6:33 AM, [email-masked]<mailto:[email-masked]> wrote:
Charles,

Thanks
phil

From: lmap [mailto:[email-masked]] On Behalf Of Charles Cook
Sent: 17 June 2014 17:47
To: [email-masked]<mailto:[email-masked]>'
Subject: [lmap] Comment on LMAP 06 Suppression

Charles

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 19 Jun 2014 13:38:58 +0000

Perhaps if the flag were made optional to send but mandatory to implement, then the choice of default behavior (in absence of flag) for me wouldn't be worth arguing about. I have no crystal ball regarding which might be more common, or whether suppression itself will ever get much use (if any). But "what's the default" is only a problem if the flag is optional to implement. Sending it when you need it adds very little overhead.
Barbara

Phil,

Charles

Thanks
phil

Charles

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

---

From: KEN KO <[email-masked]>
Date: Thu, 19 Jun 2014 14:10:45 +0000

I agree with Barbara's comment -  and in general when we define a flag as optional, we need to specify whether it is optional or mandatory that both values be supported by the function receiving it.

Unfortunately, "mandatory to implement" means that MAs need to implement the complexity Phil was hoping to avoid whether it is ever used or not. But is seems that this complexity will usually scale with the complexity of the Measurement Task itself - for example, a MA that must clean up state to terminate a task would  already be tracking state to implement the task. So the relative increase in complexity shouldn't be significant in most cases (I think).

Ken

From: lmap [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Thursday, June 19, 2014 9:39 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] Comment on LMAP 06 Suppression

From: lmap [mailto:[email-masked]] On Behalf Of Charles Cook
Sent: Thursday, June 19, 2014 8:52 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lmap] Comment on LMAP 06 Suppression

Phil,

Charles

Thanks
phil

Charles

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

---

From: Charles Cook <[email-masked]>
Date: Fri, 20 Jun 2014 08:20:50 -0600

Al,

I don't think I recognized a Suppression "Panic-button" capability in
the draft that would shut everything down (except of course those
Measurement Tasks with the Ignore Suppression flag set).  So additional
clarification may indeed help me out.

Charles

On 6/19/2014 7:39 AM, MORTON, ALFRED C (AL) wrote:
> *Sent:* Thursday, June 19, 2014 8:52 AM
> *To:* [email-masked]; [email-masked]
> *Subject:* Re: [lmap] Comment on LMAP 06 Suppression
>
>  
>
> Phil,
>
> I'm still not convinced that we should keep the default behavior as
> is.  Particularly because we can set a flag for a Measurement Task to
> ignore suppression.
>
> The real question is which is the more common case:  that a
> Measurement Task needs to stop completely or that a Measurement Task
> can continue to completion?  People may have differing views on this. 
> My view is that a Suppression is intended to stop the generation of
> traffic because there is a Network emergency of some sort.  That
> implies stopping the Measurement Task immediately.  If it is not a
> Network Emergency, then the Controller can simply update the
> Measurement Task Schedule to change when a Measurement Task ends.  I
> also believe that Measurement Tasks that are expected to run to
> completion can simply have the the ignore Suppression flag set. 
>
> Consequently, I believe the default response should be reversed so
> that an optional parameter does not need to be set in order to cause a
>     Reason is that it's very simple for a MA to stop new Tasks
>     starting (it barely has to do anything), but it may be a bit
>     harder for it to stop on-going Tasks (at least if it wants to make
>     sure they stop cleanly, perhaps clean up state in the MA, perhaps
>     shut down connections with the remote server etc).
>
>     I guess also it might have a task that essentially runs for ever,
>     such as a basic connectivity check -- but of course this depends
>     how the operator has defined their tasks and schedules.
>
>      
>
>     Thanks
>
>     phil
>
>      
>
>      
>
>     *To:* [email-masked] <mailto:[email-masked]>'
>     A comment regarding ending immediately and completing a
>     Measurement Task in response to a Suppress.
>
>      
>
>     I believe the logic of this option needs to be reversed.  The
>     default if the option is absent needs to be that the Measurement
>     Task will end immediately, because this will be the more common
>     case.  I don't think we want to require an option to be set to
>     immediately end all unflagged Measurement Tasks when a simple
>     Suppress is sent.  Perhaps something like this would work.
>
>      
>

-- 

Charles Cook 
Principal Architect
Network

---

From: <[email-masked]>
Date: Mon, 23 Jun 2014 11:17:16 +0100

On mandatory to implement and optional to send - yes.  I think this is implied by the current text "The Suppression information may include any of the following optional fields:"

In general I don't like optional-to-implement aspects, as it hinders interoperability - and I'm not expecting the lmap protocol to be hugely complex.

I have adjusted the bullet so it says:
<< a demand that the MA ends its on-going Measurement Task(s) immediately (and deletes the associated partial Measurement Result(s)). This could be useful in the case of a network emergency so that the operator can eliminate all inessential traffic as rapidly as possible. If absent, the MA completes on-going Measurement Tasks.>>
If I read the discussion correctly, this is the consensus.

Bet wishes
phil

From: Charles Cook [mailto:[email-masked]]
Sent: 20 June 2014 15:21
To: MORTON, ALFRED C (AL); Eardley,PL,Philip,TUB8 R; [email-masked]
Subject: Re: [lmap] Comment on LMAP 06 Suppression

Al,

I don't think I recognized a Suppression "Panic-button" capability in the draft that would shut everything down (except of course those Measurement Tasks with the Ignore Suppression flag set).  So additional clarification may indeed help me out.

Charles

Al

Phil,

Charles

Thanks
phil

Charles

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221