Subject: [lmap] Measurement Suppression broadcasting and non-acknowledgement

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 12 Nov 2013 16:17:01 +0000

I have some concerns with the way "Measurement Suppression" is architected in framework currently.

framework says "the "suppress" message is not acknowledged, since it is likely to be broadcast to several /many MAs at a time when the measurement system wants to eliminate inessential traffic."

1. I'm not sure if this is intended to literally mean "broadcast" (which is a very specific concept in IP that uses broadcast destination IP addresses like 255.255.255.255 or more specific subnet addresses to reach all hosts on a network with a single sent message), or "multicast" (similar to broadcast but sent to a multicast address), or just massive quantities of unicast messages sent "simultaneously".
Where MAs are internal to an enterprise or campus network (managed by Controllers also internal to the network), I could see where literal IP broadcast messages (or even multicast messages) might be a good technique to use. For MAs managed by Controllers that are out on the Internet somewhere (which I'd hope we all agree are definitely in scope), I don't think it's practical. Therefore I disagree that it's likely.

2. I believe it would be a bad idea for MAs managed by Controllers out on the Internet to react to a suppression message that is unauthenticated and unencrypted. Therefore, there exists a need for it to be possible for the Controller and each MA to establish authenticated and encrypted (e.g., TLS) sessions prior to the Controller sending the suppression command.

3. The overhead of having the MA send an Ack message after setting up the authenticated and encrypted session isn't so big that it should be prohibited, if the Controller operator wants such an Ack to occur.

Therefore, I disagree that the framework should mandate non-acknowledgement of suppression messages. I have no problem with unacknowledged suppression messages being allowed -- this can be useful in enterprise/campus environments.  But I also believe there is value in supporting acknowledged suppression messages, and that this option should also be allowed.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Nov 2013 17:35:00 +0100

Barbara,

I share your concerns.

/js

On Tue, Nov 12, 2013 at 04:17:01PM +0000, STARK, BARBARA H wrote:
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

-- 
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: <[email-masked]>
Date: Wed, 13 Nov 2013 16:32:50 +0000

Barbara
Sounds Sensible, will rewrite to give both possibilities
Thanks
Phil
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Juergen Schoenwaelder [[email-masked]]
Sent: 12 November 2013 16:35
To: STARK, BARBARA H
Cc: [email-masked]
Subject: Re: [lmap] Measurement Suppression broadcasting and non-acknowledgement

Barbara,

I share your concerns.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Nov 2013 10:26:25 +0100

Phil,

so far I assumed we communicate over TLS/TCP and with that a multicast
make no sense at all. If you want to include the option to include
multicasts, then you have to answer a number of non-trivial questions:

- What is the transport? Since we talk wide area, it needs to be
  congestion aware.

- How is the security provided over the transport? How are group
  keys managed?

- How to make multicasts reliable? How to deal with MA that are
  temporarily down?

- Why support multicasts for suppressions but not other changes
  that might affect many MAs?

There is probably more. My point here (and I think this is also
Barbara's point) is that doing multicasts for the sake of saving a
bunch of ACKs adds significant challenges and so far I have not heard
about a system that does this 'optimization' today.

I believe this multicast idea shoud be _removed_ and not be made
optional - at least for LMAP 1.0.

/js

---

From: <[email-masked]>
Date: Tue, 26 Nov 2013 16:49:14 +0000

I think you convinced me that for lmap 1.0 it would be better to go with one option, and this shouldn't be multicast
Will update (currently do a revision on the framework)

Thanks
phil

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: 14 November 2013 09:26
> To: Eardley,PL,Philip,TUB8 R
> Cc: [email-masked]
> > Sounds Sensible, will rewrite to give both possibilities Thanks Phil
> > From: [email-masked] [[email-masked]] On Behalf Of
> > Juergen Schoenwaelder [[email-masked]]
> > > framework says "the "suppress" message is not acknowledged, since
> it is likely to be broadcast to several /many MAs at a time when the
> measurement system wants to eliminate inessential traffic."
> > >
> > > 1. I'm not sure if this is intended to literally mean "broadcast"
> (which is a very specific concept in IP that uses broadcast destination
> IP addresses like 255.255.255.255 or more specific subnet addresses to
> reach all hosts on a network with a single sent message), or
> "multicast" (similar to broadcast but sent to a multicast address), or
> just massive quantities of unicast messages sent "simultaneously".
> > > Where MAs are internal to an enterprise or campus network (managed
> by Controllers also internal to the network), I could see where literal
> IP broadcast messages (or even multicast messages) might be a good
> technique to use. For MAs managed by Controllers that are out on the
> Internet somewhere (which I'd hope we all agree are definitely in
> scope), I don't think it's practical. Therefore I disagree that it's
> likely.
> > >
> > > 2. I believe it would be a bad idea for MAs managed by Controllers
> out on the Internet to react to a suppression message that is
> unauthenticated and unencrypted. Therefore, there exists a need for it
> to be possible for the Controller and each MA to establish
> authenticated and encrypted (e.g., TLS) sessions prior to the
> Controller sending the suppression command.
> > >
> > > 3. The overhead of having the MA send an Ack message after setting
> up the authenticated and encrypted session isn't so big that it should
> be prohibited, if the Controller operator wants such an Ack to occur.
> > >
> > > Therefore, I disagree that the framework should mandate non-
> acknowledgement of suppression messages. I have no problem with
> unacknowledged suppression messages being allowed -- this can be useful
> in enterprise/campus environments.  But I also believe there is value
> in supporting acknowledged suppression messages, and that this option
> should also be allowed.