Subject: [lmap] Suppress suppression?

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 5 May 2014 12:47:38 +0000

Given all of the Suppression difficulty we're having, I'd like to suggest a radically different approach: either don't define it at all, or define it as a loose, optional concept.

We know that it's possible to stop any or all measurements or reports simply by updating the Instruction. So we don't absolutely need Suppression.
I'm becoming convinced that Suppression is rapidly becoming bigger and more complex, the more we discuss it. The more tightly defined it is, the more bells and whistles that get added, the more complex it becomes. Complexity = cost. For me, the complexity is getting to the point that the disadvantages of this ever-increasing complexity are starting to outweigh any potential benefit of having something simple that can stop measurement traffic from originating from an MA.

My summary of positions regarding Suppression are:
Position 1: Suppression must cause X to happen. Reason: This is lowest complexity for my expected design.
Position 2: No, Suppression must cause subset-of-X to happen. Reason: This is lowest complexity for my expected design. Suggestion: Can we allow for Suppression to cause X or subset-of-X? Either way, subset-of-X happens.
Position 3: No, we cannot allow for ambiguity in Suppression behavior.

I'm not seeing any near-term coming together of positions happening.

If we get rid of Suppression in LMAP, and don't mention it at all, then there is no ambiguity. It wouldn't be forbidden (because it wouldn't be mentioned). So if implementers or other orgs choose to do something along this line, that's ok.
Barbara

---

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Tue, 6 May 2014 10:36:33 +0800

Hi Barbara,

I don't think we should avoid defining suppression. As I view it as an important feature for active measurement management.

> We know that it's possible to stop any or all measurements or reports simply by
> updating the Instruction. So we don't absolutely need Suppression.
[邓灵莉/Lingli Deng] I suppose this holds for controller directly triggered suppression only. It would be of value if one can indicate in an instruction to guide MA's locally triggered suppression based on certain conditions for resource-demanding active measurement tasks.

Lingli

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
> Sent: Monday, May 05, 2014 8:48 PM
> To: [email-masked]
> Subject: [lmap] Suppress suppression?
> 
> Given all of the Suppression difficulty we're having, I'd like to suggest a radically
> different approach: either don't define it at all, or define it as a loose, optional
> concept.
> 
> We know that it's possible to stop any or all measurements or reports simply by
> updating the Instruction. So we don't absolutely need Suppression.
> I'm becoming convinced that Suppression is rapidly becoming bigger and more
> complex, the more we discuss it. The more tightly defined it is, the more bells
> and whistles that get added, the more complex it becomes. Complexity = cost.
> For me, the complexity is getting to the point that the disadvantages of this
> ever-increasing complexity are starting to outweigh any potential benefit of
> having something simple that can stop measurement traffic from originating
> from an MA.
> 
> Position 2: No, Suppression must cause subset-of-X to happen. Reason: This is
> lowest complexity for my expected design. Suggestion: Can we allow for
> Suppression to cause X or subset-of-X? Either way, subset-of-X happens.
> If we get rid of Suppression in LMAP, and don't mention it at all, then there is no
> ambiguity. It wouldn't be forbidden (because it wouldn't be mentioned). So if
> implementers or other orgs choose to do something along this line, that's ok.
> Barbara
> 
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap