Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Apr 2014 09:17:09 +0000

Thanks to Phil & friends. 

I will issue a second Last Call to make sure that everybody is happy with this new version of the document before we send it to the IESG. 

Regards,

Dan

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, March 31, 2014 6:45 PM
> To: [email-masked]
> Subject: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-
> 04.txt
> 
> We've created a new version -04 of the framework doc. This resolves (we
> believe) all the WG last call issues according to the consensus agreed in
> London.
> Thanks
> Phil & friends
> http://tools.ietf.org/html/draft-ietf-lmap-framework
> 
> --
> From: lmap [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 13 March 2014 15:29
> To: [email-masked]
> Subject: [lmap] Progress on Framework
> 
> I’m trying to resolve the issues raised in WG Last call about the framework
> http://tools.ietf.org/html/draft-ietf-lmap-framework-03
> 
> 1.	Especially if you weren’t in London, please can you check the slides to
> make sure you’re happy with the proposed consensus on the various issues.
> http://tools.ietf.org/agenda/89/slides/slides-89-lmap-2.pdf    (ignore slides 5,
> 6, 7 – see link below instead)
> 2.	I prepared some slides about the MA vs MP terminology in action. Do
> these examples help clarify things? They could be turned into some text for
> the next version of the framework  http://www.leone-
> project.eu/drupal/sites/default/files/public_downloads/lmap-framework-
> examples-13march2014.pdf
> 
> I plan to work on the framework i-d next week, so please let me know if you
> have any comments.
> 
> Background: A group of us met for a side meeting in London and (we think)
> reached consensus on all the open issues. I presented the proposals during
> the WG meeting in London. We had some good discussion, especially about
> the terminology for Measurement Peer, which led to consensus round a
> slightly revised wording, and the suggestion that the i-d should include some
> explanatory examples, to illustrate the MA vs MP terminology in action.
> 
> Thanks!
> Best wishes
> phil
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 31 March 2014 16:41
> To: Aamer Akhter; Al C. Morton; Al Morton; Eardley,PL,Philip,TUB8 R; Paul
> Aitken; Paul Aitken; Marcelo Bagnulo; Eardley,PL,Philip,TUB8 R; Marcelo
> Bagnulo; Burbridge,T,Trevor,TUB8 R; Aamer Akhter; Burbridge,T,Trevor,TUB8
> R
> Subject: New Version Notification for draft-ietf-lmap-framework-04.txt
> 
> 
> A new version of I-D, draft-ietf-lmap-framework-04.txt
> has been successfully submitted by Philip Eardley and posted to the
> IETF repository.
> 
> Name:		draft-ietf-lmap-framework
> Revision:	04
> Title:		A framework for large-scale measurement platforms (LMAP)
> Document date:	2014-03-31
> Group:		lmap
> Pages:		52
> URL:            http://www.ietf.org/internet-drafts/draft-ietf-lmap-framework-
> 04.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/
> Htmlized:       http://tools.ietf.org/html/draft-ietf-lmap-framework-04
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-04
> 
> Abstract:
>    Measuring broadband service on a large scale requires a description
>    of the logical architecture and standardisation of the key protocols
>    that coordinate interactions between the components.  The document
>    presents an overall framework for large-scale measurements.  It also
>    defines terminology for LMAP (large-scale measurement platforms).
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Apr 2014 15:28:52 +0200

On Mon, Mar 31, 2014 at 04:45:03PM +0100, [email-masked] wrote:
> We've created a new version -04 of the framework doc. This resolves (we believe) all the WG last call issues according to the consensus agreed in London.

Thanks.

I have gone through the changes and below are some comments. Overall I
like the many improvements very much.

a) s/(the MA observes user traffic)/(the MA observes traffic)/

   I do not think it needs to be 'user traffic' nor do we have a
   definition of the term 'user traffic'.

b) The suppression text says:

     Suppression: the temporary cessation of Active Measurement Tasks.

   Should we not remove 'Active' from this definition? Why would it be
   illegal to suppress a passive measurement task? Is it not simpler
   to remove this restriction so that we do not have classify all
   measurement tasks? (I can imagine a passive measurement task that
   generates tons of reports and by suppressing the task, I may as a
   consequence suppress the reports.)

c) It is somewhat unclear to me why the framework likes to decide how
   capabilities, failure information and logging information is
   transferred. For example, why does it mandate that logging
   information is only sent when requested by the controller? (I could
   very well see a solution where logging information transfer is
   controlled by a schedule as well). Unless there is a very clear and
   strong reason, I think we should leave these details to the
   protocol work and not regulate them in the framework.

d) In section 10, s/just another customer/just another client/

e) I find this text somewhat irritating:

     Another case that is slightly different than this would be the one of
     a ping responder.  This is also an MP, with a helper function, the
     ping server, which is specially deployed to assist the MAs that
     perform pings.

   At least for conventional ICMP-based pings, the 'ping server' is
   the MP's IP implementation and as such it is not "specially
   deployed to assist the MAs".

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 01 Apr 2014 15:55:32 +0200

>     deployed to assist the MAs".

Right. What we meant is that ping responder is something deployed with 
the intention of testing as oposed to a web server for exmaple that 
serves an application. It is clearer with the TWAMP case, since ping is 
widely available. Do you think it is better to change the ping case for 
a TWAMP example?

Regards, marcelo

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Apr 2014 16:04:13 +0200

On Tue, Apr 01, 2014 at 03:55:32PM +0200, marcelo bagnulo braun wrote:
> Right. What we meant is that ping responder is something deployed
> with the intention of testing as oposed to a web server for exmaple
> that serves an application. It is clearer with the TWAMP case, since
> ping is widely available. Do you think it is better to change the
> ping case for a TWAMP example?

Yes, I think that would be clearer.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Apr 2014 14:15:14 +0000

Philip, 

Do you want to address immediately the comments made by Juergen, or would you rather have the second WGLC issued and consider these as LC comments? 

Dan

> From: lmap [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Tuesday, April 01, 2014 4:29 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-
> framework-04.txt
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 1 Apr 2014 15:30:47 +0000

>    consequence suppress the reports.)

What I had lobbied for was that Suppression caused the cessation of measurement traffic originated by the MA.
Suppression was proposed as a blunt hammer that would stop measurement traffic. I would like to keep it as proposed, and not expand the breadth of its bluntness.

It may have side effects of stopping other processes not directly related to cessation of originated measurement traffic, but this cannot be assumed. For a generic MA, it cannot be assumed that passive measuring will or won't continue, or that reporting will or won't continue. If someone designs their particular MA to shut down all activities as a result of Suppression, that's ok (as long as there is no originated measurement traffic). If someone designs their particular MA to only prevent originated measurement traffic, that's ok, too.
 
If someone wants to suppress a report, they can send updated Instruction to change details regarding that report (or all reports). 

One of the use cases is "service providers collecting measurements from their managed devices". Service provider operations systems are often on a distinct management network, so it's unnecessary to force everyone with this sort of separation of Internet traffic and management traffic to always use the "only suppress these specific measurement tasks/schedules" in order to avoid having their devices (that they procure and supply design requirements for) suppress reporting or other Report and Control activities.

Those who design devices intended for other use cases are free to shut down all activities on those devices. So long as the primary goal of preventing originated measurement traffic is met, IMO, it's ok to allow flexibility in design of what else gets impacted by Suppression.
Barbara

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Apr 2014 17:38:08 +0200

Barbara,

do you agree with the current text, with my change, or do you propose
something different? I fail to get this our of your text.

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 1 Apr 2014 15:59:21 +0000

> something different? I fail to get this our of your text.

I propose something different.
Suppression: the cessation of measurement traffic originated by the MA.

[I'm ok with "temporary" but find it awkward since there's actually nothing in the Suppression mechanism that ensures it's always temporary.]

I agree with you that "Active" does not belong in the definition. I disagree that internal collection of passive measurements must cease, or that reporting must cease. They may cease in a particular implementation, but all implementations are not required to cause them to cease. Only originated measurement traffic must cease.
Barbara
 
> > What I had lobbied for was that Suppression caused the cessation of
> measurement traffic originated by the MA.
> > Suppression was proposed as a blunt hammer that would stop
> measurement traffic. I would like to keep it as proposed, and not expand the
> breadth of its bluntness.
> >
> > It may have side effects of stopping other processes not directly related to
> cessation of originated measurement traffic, but this cannot be assumed. For
> a generic MA, it cannot be assumed that passive measuring will or won't
> continue, or that reporting will or won't continue. If someone designs their
> particular MA to shut down all activities as a result of Suppression, that's ok
> (as long as there is no originated measurement traffic). If someone designs
> their particular MA to only prevent originated measurement traffic, that's ok,
> too.
> >
> > If someone wants to suppress a report, they can send updated Instruction
> to change details regarding that report (or all reports).
> >
> > One of the use cases is "service providers collecting measurements from
> their managed devices". Service provider operations systems are often on a
> distinct management network, so it's unnecessary to force everyone with
> this sort of separation of Internet traffic and management traffic to always
> use the "only suppress these specific measurement tasks/schedules" in
> order to avoid having their devices (that they procure and supply design
> requirements for) suppress reporting or other Report and Control activities.
> >
> > Those who design devices intended for other use cases are free to shut
> down all activities on those devices. So long as the primary goal of preventing
> originated measurement traffic is met, IMO, it's ok to allow flexibility in
> design of what else gets impacted by Suppression.
> > Barbara
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Apr 2014 18:27:00 +0200

> I agree with you that "Active" does not belong in the definition. I disagree that internal collection of passive measurements must cease, or that reporting must cease. They may cease in a particula…

I am having a problem with 'may in some implementations'. This is not
interoperable.

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 1 Apr 2014 18:34:00 +0000

> > I agree with you that "Active" does not belong in the definition. I disagree
> that internal collection of passive measurements must cease, or that
> reporting must cease. They may cease in a particular implementation, but all
> implementations are not required to cause them to cease. Only originated
> measurement traffic must cease.
> 

In my experience, it's impossible to define a function so thoroughly that there are no unknowns about what it will do in a certain situation, and no decisions left up to the implementer. 

But let's say hypothetically that all collection of passive measurements *are* "stopped". We've defined internal measuring of CPU utilization and memory resources and general device health checking as "passive measurements". So this means they all have to stop. Firewall logging is a passive measurement. It must stop. Link resource utilization to be used in active queue management is a passive measurement. It must stop. But why is it an interoperability "issue" whether these passive measurement processes continue to run or not? I really don't understand how they impact interoperability.

As for reporting, we've defined sending log info (e.g. measurement tasks successfully run, suppressed, etc.) to the Controller as a report. Let's say we expect Suppression to stop all reports. That means it must not send the Controller any logs. 

Anyway, I was illustrating just a few examples of unknowns wrt impacts of Suppression. There are many more unknowns. My proposed definition of Suppression has no 'may' statements.

If we wanted to explicitly say that suppression shall not impact collection of passive measurements or reporting, I would be fine with that, since I think that's the better design and I think it's easily achieved. But others thought it would be complex to do and that it would be simpler for them to "kill all measurement tasks". As long as I'm not obliged to implement Suppression as "kill all tasks" I'm fine with giving others the freedom to do so in their implementations.
Barbara

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Apr 2014 07:55:42 +0200

Barbara,

I disagree. If I hit the supression button, I like to know what the
consequence of this is. Leaving this partially up to implementations
is in my view the worst of all choices. Looking at the current ID, my
understanding is that a suppression without parameters suppresses a
certain set of measurement tasks, takes effect immediately, and
supression ends when the unsuppress button is hit. I assume the
suppress ongoing task bit defaults to false (but this is less clearly
spelled out).

To define the set of measurement tasks that is affected if no set is
specified, we can either introduce a classification of all measurement
tasks (where is this coming from?) or we could make this explicit
config (this way I know which tasks will be stopped if someone hits
the button). Both could work for me. But, a definition of 'a certain
set of measurement tasks plus additional tasks that are implementation
specific' is in my view not a desirable outcome.

/js

---

From: <[email-masked]>
Date: Wed, 2 Apr 2014 10:06:45 +0100

Can I suggest we discuss S5.2.1.1 first and get the definition of Suppression right after that.

Just to confirm what the current 5.2.1.1 is intended to mean:
Suppression must stop new active measurement tasks from starting.
The impact is undefined (left to the implementer /deployer) on other things like passive measurement tasks and on-going active tasks.
Suppression is intended to be temporary - if you want to stop all the active tasks permanently, then it's suggested you send a new schedule [but I guess there's nothing to stop you 'abusing' suppression as a permanent stop]

5.2.1.1 doesn't talk about the impact on Data Transfer Tasks. Not sure we've discussed this. I suppose at the moment the implication is that Data Transfer Tasks (including reporting) continues to run. 

--

In terms of implementation, the way I thought about it is that the MA would have a mini-firewall that would block all outgoing traffic associated with a measurement task; there's at least some traffic it mustn't block, such as capabilities & logging info sent in response to a request from the controller. Is this easy to implement? 
I don't think the MA needs to understand any classification of different measurement tasks. However, the measurement system would probably like to understand the impact of this mini-firewall function for non-obvious cases like a measurement task that simply modifies the header of end-user traffic.

--

> we can either introduce a classification of all measurement
> config (this way I know which tasks will be stopped if someone hits the
> button). 
I don't like classification. This is work, requires extra state in controller and MA, and what happens if there's a classification mistake.
Explicit config. This basically means 'send a new schedule' (actually my personal view but not the consensus)

Phil

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: 02 April 2014 06:56
> To: STARK, BARBARA H
> Cc: Eardley,PL,Philip,TUB8 R; [email-masked]
> consequence of this is. Leaving this partially up to implementations is
> in my view the worst of all choices. Looking at the current ID, my
> config (this way I know which tasks will be stopped if someone hits the
> button). Both could work for me. But, a definition of 'a certain set of
> measurement tasks plus additional tasks that are implementation
> > > reporting must cease. They may cease in a particular
> implementation,
> > > but all implementations are not required to cause them to cease.
> > > Only originated measurement traffic must cease.
> > >
> > > I am having a problem with 'may in some implementations'. This is
> > > not interoperable.
> >
> > In my experience, it's impossible to define a function so thoroughly
> that there are no unknowns about what it will do in a certain
> situation, and no decisions left up to the implementer.
> >
> > But let's say hypothetically that all collection of passive
> measurements *are* "stopped". We've defined internal measuring of CPU
> utilization and memory resources and general device health checking as
> "passive measurements". So this means they all have to stop. Firewall
> logging is a passive measurement. It must stop. Link resource
> utilization to be used in active queue management is a passive
> measurement. It must stop. But why is it an interoperability "issue"
> whether these passive measurement processes continue to run or not? I
> really don't understand how they impact interoperability.
> >
> > As for reporting, we've defined sending log info (e.g. measurement
> tasks successfully run, suppressed, etc.) to the Controller as a
> report. Let's say we expect Suppression to stop all reports. That means
> it must not send the Controller any logs.
> >
> > Anyway, I was illustrating just a few examples of unknowns wrt
> impacts of Suppression. There are many more unknowns. My proposed
> definition of Suppression has no 'may' statements.
> >
> > If we wanted to explicitly say that suppression shall not impact
> collection of passive measurements or reporting, I would be fine with
> that, since I think that's the better design and I think it's easily
> achieved. But others thought it would be complex to do and that it
> would be simpler for them to "kill all measurement tasks". As long as
> I'm not obliged to implement Suppression as "kill all tasks" I'm fine
> with giving others the freedom to do so in their implementations.
> > Barbara
> 
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Apr 2014 11:28:59 +0200

Phil,

I think what you have in mind (the mini firewall) is not exactly what
I would understand from "must stop new active measurement tasks from
starting". Your notion of suppressiong is blocking measurement
traffic, you are not starting or stopping or not starting anything.

If this is what suppression is meant to be (and I think this is close
to Barbara's ideas), then we need to spell this out more clearly I
think.

Is it simple to implement? I think one would need for each measurement
task a filter that can be injected and removed and the filters would
have to be designed such that they do not cause side effects affecting
other things going on. In other words, this sets up a requirement for
measurement task implementations, not so much for the generic
infrastructure (that would simply inject and remove such filters).

Anyway, as useful as this might be, the current text seems to say
something different.

/js

---

From: <[email-masked]>
Date: Wed, 2 Apr 2014 10:30:05 +0100

Juergen - thanks for the comments!

>    protocol work and not regulate them in the framework.

Ok, will modify so it describes the different sorts of info and then says they may be sent in response to a request by the controller, or by the MA on its own initiative. 

Also, I'll modify the picture as I think "Capabilities request" suggests there's a special message, whereas really this is an Instruction with a Data Transfer Task (that is effectively a request to send capabilities info).

Suppression - discussing separately

Other changes - will make.

phil

---

From: <[email-masked]>
Date: Wed, 2 Apr 2014 10:32:00 +0100

I'm happy for the WGLC to be issued. 
I think the one issue to resolve is about suppression, which I think we can do as part of LC.

Phil/

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: 01 April 2014 15:15
> To: Juergen Schoenwaelder; Eardley,PL,Philip,TUB8 R
> Cc: [email-masked]
> Subject: RE: [lmap] FW: New Version Notification for draft-ietf-lmap-
> framework-04.txt
> 
> Philip,
> 
> Do you want to address immediately the comments made by Juergen, or
> would you rather have the second WGLC issued and consider these as LC
> comments?
> 
> Dan
> 
> 
> > believe) all the WG last call issues according to the consensus
> agreed
> > in London.
> >
> > Thanks.
> >

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 2 Apr 2014 08:18:31 -0400

So, keeping the firewall/filter analogy,  the "suppress" action
is to grab a list of filters and remove or modify them to block 
the measurement traffic. This means the suppress process needs a 
list of measurement tasks to act on, even if the intent is 
"suppress all" or "suppress active". the active type we can distinguish
from the metric registry assignment (if it's in the active registry,
suppress).

And as Juergen points out, tasks that aren't started yet are not so
easily handled, the firewall doesn't have a filter for un-started tasks
so we really need to take action on the scheduler, too.

Al

> Sent: Wednesday, April 02, 2014 5:29 AM
> Cc: STARK, BARBARA H; [email-masked]
> > The impact is undefined (left to the implementer /deployer) on other
> things like passive measurement tasks and on-going active tasks.
> > Suppression is intended to be temporary - if you want to stop all the
> active tasks permanently, then it's suggested you send a new schedule [but
> I guess there's nothing to stop you 'abusing' suppression as a permanent
> stop]
> >
> > 5.2.1.1 doesn't talk about the impact on Data Transfer Tasks. Not sure
> we've discussed this. I suppose at the moment the implication is that Data
> Transfer Tasks (including reporting) continues to run.
> >
> > --
> >
> > In terms of implementation, the way I thought about it is that the MA
> would have a mini-firewall that would block all outgoing traffic
> associated with a measurement task; there's at least some traffic it
> mustn't block, such as capabilities & logging info sent in response to a
> request from the controller. Is this easy to implement?
> > I don't think the MA needs to understand any classification of different
> measurement tasks. However, the measurement system would probably like to
> understand the impact of this mini-firewall function for non-obvious cases
> like a measurement task that simply modifies the header of end-user
> traffic.
> >
> > --
> >
> the
> > I don't like classification. This is work, requires extra state in
> controller and MA, and what happens if there's a classification mistake.
> is
> the
> > > > > > I agree with you that "Active" does not belong in the
> definition.
> > > > > > I disagree

---

From: <[email-masked]>
Date: Mon, 28 Apr 2014 17:26:21 +0100

Not sure this discussion (about suppression) reached a conclusion. 

At the moment, the default is that suppression stops all new active measurement tasks and the impact on other tasks (including passive measurements and reporting) is left up to the implementation.

Please re-start the discussion if you think this needs to be adjusted

Thanks
phil

> Sent: 02 April 2014 10:29
> To: Eardley,PL,Philip,TUB8 R
> Cc: [email-masked]; [email-masked]
> I think what you have in mind (the mini firewall) is not exactly what I
> would understand from "must stop new active measurement tasks from
> starting". Your notion of suppressiong is blocking measurement traffic,
> you are not starting or stopping or not starting anything.
> 
> > active tasks permanently, then it's suggested you send a new schedule
> > [but I guess there's nothing to stop you 'abusing' suppression as a
> > permanent stop]
> >
> > 5.2.1.1 doesn't talk about the impact on Data Transfer Tasks. Not
> sure we've discussed this. I suppose at the moment the implication is
> that Data Transfer Tasks (including reporting) continues to run.
> >
> > --
> >
> mustn't block, such as capabilities & logging info sent in response to
> a request from the controller. Is this easy to implement?
> > I don't think the MA needs to understand any classification of
> different measurement tasks. However, the measurement system would
> probably like to understand the impact of this mini-firewall function
> for non-obvious cases like a measurement task that simply modifies the
> header of end-user traffic.
> >
> > --
> >
> > > we can either introduce a classification of all measurement tasks
> > > (where is this coming from?) or we could make this explicit config
> > > (this way I know which tasks will be stopped if someone hits the
> > > button).
> > > Subject: Re: [lmap] FW: New Version Notification for
> > > draft-ietf-lmap- framework-04.txt
> > >
> > > Barbara,
> > >
> > > is in my view the worst of all choices. Looking at the current ID,
> > > my understanding is that a suppression without parameters
> suppresses
> > > a certain set of measurement tasks, takes effect immediately, and
> > > suppress ongoing task bit defaults to false (but this is less
> > > clearly spelled out).
> > >
> > > specified, we can either introduce a classification of all
> > > measurement tasks (where is this coming from?) or we could make
> this
> > > explicit config (this way I know which tasks will be stopped if
> > > someone hits the button). Both could work for me. But, a definition
> > > of 'a certain set of measurement tasks plus additional tasks that
> > > are implementation specific' is in my view not a desirable outcome.
> > >
> > > /js
> > >
> > > > > I am having a problem with 'may in some implementations'. This
> > > > > is not interoperable.
> > > >
> > > measurements *are* "stopped". We've defined internal measuring of
> > > CPU utilization and memory resources and general device health
> > > checking as "passive measurements". So this means they all have to
> > > stop. Firewall logging is a passive measurement. It must stop. Link
> > > resource utilization to be used in active queue management is a
> > > passive measurement. It must stop. But why is it an
> interoperability "issue"
> > > whether these passive measurement processes continue to run or not?
> > > I really don't understand how they impact interoperability.
> > > >
> > > report. Let's say we expect Suppression to stop all reports. That
> > > means it must not send the Controller any logs.
> > > >
> > > > Suppression: the cessation of measurement traffic originated by
> > > > the
> > > MA.
> > > >
> > > collection of passive measurements or reporting, I would be fine
> > > with that, since I think that's the better design and I think it's
> > > easily achieved. But others thought it would be complex to do and
> > > that it would be simpler for them to "kill all measurement tasks".
> > > As long as I'm not obliged to implement Suppression as "kill all
> > > tasks" I'm fine with giving others the freedom to do so in their
> implementations.
> > > > Barbara
> > >
> > > --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Apr 2014 21:28:56 +0200

Phil,

during the discussion, I heard two very different interpretations of
'suppression' and I think we need to pick between the two possible but
fundamentally different interpretations:

a) Suppressions means that (active) measurement tasks are not started
   anymore - so it is essentially a filter applied to the scheduler
   (analogous to commenting out scheduled (active) tasks).

b) Suppression means a filter applied that drop the measurement
   traffic generated by measurement tasks. In this case, the
   scheduling is not really effected and measurement tasks keep
   getting started but the traffic they inject is filtered away.

It seems that a) is just a short cut to temporarily change the
scheduling while b) is really a different function since measurment
tasks would have to come with appropriate filters that can suppress
the traffic generated by the tasks.

/js

---

From: Charles Cook <[email-masked]>
Date: Mon, 28 Apr 2014 14:15:38 -0600

It is good we are having this discussion.  I am not sure if I am saying
the same as what Juergen is saying in b), but my understanding is that:

Default Suppression means that all Measurement Tasks that generate
traffic are suppressed (however the MA decides how to do that -
filtering at the MA so that no traffic is generated could be one way to
do it, cancelling the current instance of the Measurement Task could be
another way to do it).  Schedules stay in place such that if an
un-Suppression is received, that a scheduled Measurement Task will
commence when the time comes (as long as the scheduled time for the
Measurement Task to be executed occurs after the un-Suppression has been
received). 

I don't recall anything being said about what happens to a Measurement
Task (that according to schedule) would be in process if a Suppression
had not been received.  I DO recall that IF the MA reports results of a
Measurement Task that has been suppressed any time during its execution,
the MA must report that the results are not valid.  I don't recall that
we specified that an MA needs to report Results if it has been impacted
by a Suppression.  At this stage, my interpretation is that it is an
implementation choice of whether the MA continues to run Measurement
Tasks (and does not let any generated traffic leak into the network)
during a period of Suppression.  So depending on implementation, filters
may not be necessary.  If we believe filtering is required, then we need
to specify that.  My belief is that the simpler the better. 

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: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Apr 2014 22:23:35 +0200

> Measurement Task to be executed occurs after the un-Suppression has been

I prefer to have a precise definition what suppression means. I can
easily picture measurement tasks where leaving the task running while
temporarily block the traffic leads to different results compared to
stopping the task and restarting it later. In terms of the traffic
generated during suppression, the result may be the same but a restart
causes measurement task internal context information to get lost,
which can be more disruptive to the measurement.

/js

---

From: <[email-masked]>
Date: Wed, 30 Apr 2014 11:36:55 +0100

I agree it would be better to have a precise definition of suppression. I agree that a) and b) are not completely the same. 

I tend to favour a) - ie suppression means the task is not run.

I think this is simpler and fits better with the information model. 
For example, we talked about the idea of suppressing particular tasks (maybe ones that are generating a lot of traffic, or ones that are suspected of having a bug) and suppressing a particular schedule (maybe one with less important tasks) - a) fits better with that. Also, after our London discussions, the information model will talk in terms of generic Tasks (which may be measurements, data transfer tasks or even other sorts), so it makes sense to suppress Tasks - then we get the choice (or not) of suppressing Reports as well as active measurement tasks say.

phil

> Sent: 28 April 2014 21:24
> To: Charles Cook
> Cc: Eardley,PL,Philip,TUB8 R; [email-masked]; [email-masked]
> > It is good we are having this discussion.  I am not sure if I am
> > saying the same as what Juergen is saying in b), but my understanding
> is that:
> >
> > filtering at the MA so that no traffic is generated could be one way
> > to do it, cancelling the current instance of the Measurement Task
> > could be another way to do it).  Schedules stay in place such that if
> > an un-Suppression is received, that a scheduled Measurement Task will
> > Measurement Task to be executed occurs after the un-Suppression has
> > been received).
> >
> 
> causes measurement task internal context information to get lost, which
> can be more disruptive to the measurement.
> 
> /js
> 
> --

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: 28 April 2014 20:29
To: Eardley,PL,Philip,TUB8 R
Cc: [email-masked]; [email-masked]
Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt

Phil,

during the discussion, I heard two very different interpretations of 'suppression' and I think we need to pick between the two possible but fundamentally different interpretations:

It seems that a) is just a short cut to temporarily change the scheduling while b) is really a different function since measurment tasks would have to come with appropriate filters that can suppress the traffic generated by the tasks.

/js

---

From: KEN KO <[email-masked]>
Date: Wed, 30 Apr 2014 12:14:59 +0000

I favor a) as well.

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 30, 2014 6:37 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt

phil

> > could be another way to do it).  Schedules stay in place such that 
> > if an un-Suppression is received, that a scheduled Measurement Task 
> > will commence when the time comes (as long as the scheduled time for 
> > the Measurement Task to be executed occurs after the un-Suppression 
> > has been received).
> >
> 

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: 28 April 2014 20:29
To: Eardley,PL,Philip,TUB8 R
Cc: [email-masked]; [email-masked]
Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt

Phil,

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 30 Apr 2014 13:00:47 +0000

Just to quibble a bit.
I dislike requirements that cannot be easily externally verified. So for me, I don't care if processes run or don't run, or whether or not there are filters. I care about whether I can see any external evidence of those processes. For me, such external evidence is measurement traffic. If I can put a sniffer outside the MA's device and see measurement traffic, then the measurement tasks causing that traffic are not being suppressed. If I've asked for certain measurement tasks to be suppressed and I don't see any traffic associated with those measurements, then I'm satisfied that the measurements have effectively been suppressed. I don't care if that was done by a filter or killing a process or causing a special part of the measurement task code to run that runs only when suppression is invoked. 

This is why I would prefer to define Suppression in terms of the external behavior we expect to see (or not see) as opposed to internal ways of causing these external behaviors to occur.

The goal of Suppression was to prevent (certain) measurement traffic. The original goal had nothing to do with internal processes or filters, and I'm at a loss to understand why we care how external traffic is prevented.
Barbara

> From: KEN KO [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2014 8:15 AM
> To: [email-masked]; [email-masked];
> From: [email-masked]
> 
> I agree it would be better to have a precise definition of suppression. I agree
> that a) and b) are not completely the same.
> 
> For example, we talked about the idea of suppressing particular tasks
> (maybe ones that are generating a lot of traffic, or ones that are suspected of
> having a bug) and suppressing a particular schedule (maybe one with less
> important tasks) - a) fits better with that. Also, after our London discussions,
> the information model will talk in terms of generic Tasks (which may be
> measurements, data transfer tasks or even other sorts), so it makes sense to
> suppress Tasks - then we get the choice (or not) of suppressing Reports as
> well as active measurement tasks say.
> 
> phil
> 
> 
> It seems that a) is just a short cut to temporarily change the scheduling while
> b) is really a different function since measurment tasks would have to come
> with appropriate filters that can suppress the traffic generated by the tasks.
> 
> /js
>

---

From: KEN KO <[email-masked]>
Date: Wed, 30 Apr 2014 13:12:06 +0000

But to return to Juergen's mail ... if preventing the task entirely results in one set of measurement results and simply suppressing traffic results in a different set, that is an externally verified difference. I think he has a good point.

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2014 9:01 AM
To: KEN KO; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.txt

Just to quibble a bit.

> I agree it would be better to have a precise definition of 
> suppression. I agree that a) and b) are not completely the same.
> 
> (maybe ones that are generating a lot of traffic, or ones that are 
> suspected of having a bug) and suppressing a particular schedule 
> (maybe one with less important tasks) - a) fits better with that. 
> Also, after our London discussions, the information model will talk in 
> terms of generic Tasks (which may be measurements, data transfer tasks 
> or even other sorts), so it makes sense to suppress Tasks - then we 
> get the choice (or not) of suppressing Reports as well as active measurement tasks say.
> 
> phil
> 
> 
> > > filtering at the MA so that no traffic is generated could be one 
> > > way to do it, cancelling the current instance of the Measurement 
> > > Task could be another way to do it).  Schedules stay in place such 
> > > that if an un-Suppression is received, that a scheduled 
> > > Measurement Task will commence when the time comes (as long as the 
> > > scheduled time for the Measurement Task to be executed occurs 
> > > after the un-Suppression has been received).
> > >
> >
> > easily picture measurement tasks where leaving the task running 
> > while temporarily block the traffic leads to different results 
> > compared to stopping the task and restarting it later. In terms of 
> > the traffic generated during suppression, the result may be the same 
> > but a restart causes measurement task internal context information 
> > to get lost, which can be more disruptive to the measurement.
> >
> > /js
> >
> > --
> scheduling while
> b) is really a different function since measurment tasks would have to 
> come with appropriate filters that can suppress the traffic generated by the tasks.
> 
> /js
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Apr 2014 15:59:57 +0200

On Wed, Apr 30, 2014 at 01:00:47PM +0000, STARK, BARBARA H wrote:
> 
> The goal of Suppression was to prevent (certain) measurement
> traffic. The original goal had nothing to do with internal processes
> or filters, and I'm at a loss to understand why we care how external
> traffic is prevented.

Because the way it is implemented does impact the measurements. There
can be a big difference between keeping the a measurement task running
and merely suppressing its traffic and stopping and restarting a
measurement task.

If we assume that agreement is that supression affects the tasks
running, then suppression is like a scheduled change of the scheduled
tasks (and the generalization would be a scheduled change of any
aspect of the 'instructions', that is, have named sets of instructions
and a schedule that says which set is activated when - ok, we probably
do not want to go there in LMAP 1.0).

/js