Subject: [lmap] Question regarding MA and MP definitions

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 11 Feb 2014 14:15:50 +0000

Several of us have been having a very active discussion regarding nuances of the MA and MP definitions, and I'm curious as to what the opinions of others on the lmap list are.

Regarding active measurements that involve the MA and an MP...
The following sentence is in the framework: "For Active Measurement Tasks, the MA (or Measurement Peer) generates Active Measurement Traffic...".
Does this mean that it is possible for the MP to initiate the active measurement to the MA, or is the MA always the initiator?
For example: Sometimes service providers will initiate measurement tests from the access network to the service provider supplied residential gateway (RG). Before running the test, the RG is first configured to respond to the test appropriately. 

If the MP can be the initiator in the lmap framework, we would still need to configure the MA to respond appropriately. Consistent with already-identified MA functionality, we would need the Controller to know the MA is capable of doing this, and be able to send Instructions to properly configure the MA. There isn't a Measurement Schedule associated with this, and the MA doesn't necessarily have any results to include in a Report. Is that ok?

So in the opinion of others on this list, is this scenario covered by and in-scope of the current framework, is it allowed but not in the current scope of work, or is it inconsistent with others' ideas of what MAs and MPs are and should be capable of doing (i.e., MAs always initiate and MPs can only respond)?

Barbara

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 11 Feb 2014 09:28:48 -0500

Hi Barbara,

The key distinction is generate *Active measurement traffic*,
which is not the same as the control messages that may be
exchanged between a MA and MP.

Some measurement protocols (o-o-scope for LMAP) can control
a remote end-point to send back a one-way stream of active
measurement traffic. The MA would initiate active measurement,
telling the MP to send a one-way active measurement stream
back to the receiving address/port at the MA. OWAMP can do it.

If you want a device to initiate the measurement control protocol
exchange, then I think that device is the MA, and right now
that's the only device the Controller talks to, which is consistent.

hth,
Al

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
> Sent: Tuesday, February 11, 2014 9:16 AM
> To: [email-masked]
> Subject: [lmap] Question regarding MA and MP definitions
> 
> 
> Several of us have been having a very active discussion regarding nuances
> of the MA and MP definitions, and I'm curious as to what the opinions of
> others on the lmap list are.
> 
> The following sentence is in the framework: "For Active Measurement Tasks,
> the MA (or Measurement Peer) generates Active Measurement Traffic...".
> Does this mean that it is possible for the MP to initiate the active
> measurement to the MA, or is the MA always the initiator?
> For example: Sometimes service providers will initiate measurement tests
> from the access network to the service provider supplied residential
> gateway (RG). Before running the test, the RG is first configured to
> respond to the test appropriately.
> 
> If the MP can be the initiator in the lmap framework, we would still need
> to configure the MA to respond appropriately. Consistent with already-
> identified MA functionality, we would need the Controller to know the MA
> is capable of doing this, and be able to send Instructions to properly
> configure the MA. There isn't a Measurement Schedule associated with this,
> and the MA doesn't necessarily have any results to include in a Report. Is
> that ok?
> 
> So in the opinion of others on this list, is this scenario covered by and
> in-scope of the current framework, is it allowed but not in the current
> scope of work, or is it inconsistent with others' ideas of what MAs and
> MPs are and should be capable of doing (i.e., MAs always initiate and MPs
> can only respond)?
> 
> Barbara
> 
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: Brian Trammell <[email-masked]>
Date: Tue, 11 Feb 2014 15:36:11 +0100

hi Barbara, Al,

To take this a bit further, I think the main thing that distinguishes an MA from the point of view of the framework is that it’s the component the Controller can send Instructions to. As long as sending an Instruction to an MA causes the right thing to happen, then what happens between the MA(s) and MP(s), how things are initiated internally and the direction of active measurement traffic within the measurement protocol, should to the extent possible be out of scope.

> exchanged between a MA and MP.

And these are (and should remain) out of scope, unless I’ve misunderstood something.

> that's the only device the Controller talks to, which is consistent.

One could certainly envision active measurement protocols where the MPs poll active measurement control from the MAs. That’s also consistent with the present arrangement.

Best regards,

Brian

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Tue, 11 Feb 2014 14:39:39 +0000

Barbara,

  My observations (until we have a list of tests from someone....)   

Here's what I'm reading in the regulatory performance reports --- test wise ---

Both types (co-ordinated / non-coordinated) test are showing up in regulator reports -

The first 3 aren't documented in a SDO anywhere I know of, the others are either known test or documented in non-SDO locations...

Non-coordinated MA tests 
1) Multiple session TCP throughput (up and down) - with a stability factor to cancel out burst
2) Single session TCP throughput (up and down) - with a stability factor to cancel out burst
3) Some type of burst measurement (up and down)
4) Webpage load time 
5) Ping response times

Coordination required type MA tests
6) UDP in each direction

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C (AL)
Sent: Tuesday, February 11, 2014 8:29 AM
To: STARK, BARBARA H; [email-masked]
Subject: Re: [lmap] Question regarding MA and MP definitions

Hi Barbara,

The key distinction is generate *Active measurement traffic*, which is not the same as the control messages that may be exchanged between a MA and MP.

Some measurement protocols (o-o-scope for LMAP) can control a remote end-point to send back a one-way stream of active measurement traffic. The MA would initiate active measurement, telling the MP to send a one-way active measurement stream back to the receiving address/port at the MA. OWAMP can do it.

If you want a device to initiate the measurement control protocol exchange, then I think that device is the MA, and right now that's the only device the Controller talks to, which is consistent.

hth,
Al

> Several of us have been having a very active discussion regarding 
> nuances of the MA and MP definitions, and I'm curious as to what the 
> opinions of others on the lmap list are.
> 
> The following sentence is in the framework: "For Active Measurement 
> Tasks, the MA (or Measurement Peer) generates Active Measurement Traffic...".
> For example: Sometimes service providers will initiate measurement 
> tests from the access network to the service provider supplied 
> residential gateway (RG). Before running the test, the RG is first 
> configured to respond to the test appropriately.
> 
> If the MP can be the initiator in the lmap framework, we would still 
> need to configure the MA to respond appropriately. Consistent with 
> already- identified MA functionality, we would need the Controller to 
> know the MA is capable of doing this, and be able to send Instructions 
> to properly configure the MA. There isn't a Measurement Schedule 
> associated with this, and the MA doesn't necessarily have any results 
> to include in a Report. Is that ok?
> 
> So in the opinion of others on this list, is this scenario covered by 
> and in-scope of the current framework, is it allowed but not in the 
> current scope of work, or is it inconsistent with others' ideas of 
> what MAs and MPs are and should be capable of doing (i.e., MAs always 
> initiate and MPs can only respond)?
> 
> Barbara
>

---

From: "Sharam Hakimi" <[email-masked]>
Date: Tue, 11 Feb 2014 09:46:44 -0500

That was my understanding also from the lmap text. MA is the only
initiator of the test but traffic generation can be from either the MA
to MP, MP to MA or MA to MP at the same time for a specific test.

Thanks,
Sharam

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C
(AL)
Sent: Tuesday, February 11, 2014 9:29 AM
To: STARK, BARBARA H; [email-masked]
Subject: Re: [lmap] Question regarding MA and MP definitions

Hi Barbara,

hth,
Al

> Several of us have been having a very active discussion regarding
nuances
> The following sentence is in the framework: "For Active Measurement
Tasks,
> For example: Sometimes service providers will initiate measurement
tests
> If the MP can be the initiator in the lmap framework, we would still
need
> So in the opinion of others on this list, is this scenario covered by
and

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 11 Feb 2014 14:47:10 +0000

Thank you Brian. I completely agree with what you wrote. This is my view as well.
Barbara
 
> hi Barbara, Al,
> 
> To take this a bit further, I think the main thing that distinguishes an MA from
> the point of view of the framework is that it's the component the Controller
> can send Instructions to. As long as sending an Instruction to an MA causes
> the right thing to happen, then what happens between the MA(s) and
> MP(s), how things are initiated internally and the direction of active
> measurement traffic within the measurement protocol, should to the extent
> possible be out of scope.
> 
> > The key distinction is generate *Active measurement traffic*, which is
> > not the same as the control messages that may be exchanged between a
> > MA and MP.
> 
> And these are (and should remain) out of scope, unless I've misunderstood
> something.
> 
> > Some measurement protocols (o-o-scope for LMAP) can control a remote
> > end-point to send back a one-way stream of active measurement traffic.
> > The MA would initiate active measurement, telling the MP to send a
> > one-way active measurement stream back to the receiving address/port
> > at the MA. OWAMP can do it.
> >
> > exchange, then I think that device is the MA, and right now that's the
> > only device the Controller talks to, which is consistent.
> 
> One could certainly envision active measurement protocols where the MPs
> poll active measurement control from the MAs. That's also consistent with
> the present arrangement.
> 
> Best regards,
> 
> Brian
> 
> > hth,
> > Al
> >
> >> From: lmap [mailto:[email-masked]] On Behalf Of STARK,
> BARBARA
> >> H
> >> know the MA is capable of doing this, and be able to send
> >> Instructions to properly configure the MA. There isn't a Measurement
> >> Schedule associated with this, and the MA doesn't necessarily have
> >> any results to include in a Report. Is that ok?
> >>

---

From: <[email-masked]>
Date: Wed, 12 Feb 2014 10:14:58 +0000

Agree.

>From this discussion, I take the lesson that us framework authors need to add some more explanatory text on the lines suggested by you all

phil

> Sent: 11 February 2014 14:47
> To: Brian Trammell; MORTON JR., AL
> Cc: [email-masked]
> > To take this a bit further, I think the main thing that distinguishes
> > an MA from the point of view of the framework is that it's the
> > component the Controller can send Instructions to. As long as sending
> > an Instruction to an MA causes the right thing to happen, then what
> > happens between the MA(s) and MP(s), how things are initiated
> > internally and the direction of active measurement traffic within the
> > measurement protocol, should to the extent possible be out of scope.
> >
> > > The key distinction is generate *Active measurement traffic*, which
> > > is not the same as the control messages that may be exchanged
> > > between a MA and MP.
> >
> > And these are (and should remain) out of scope, unless I've
> > misunderstood something.
> >
> > > exchange, then I think that device is the MA, and right now that's
> > > the only device the Controller talks to, which is consistent.
> >
> > One could certainly envision active measurement protocols where the
> > MPs poll active measurement control from the MAs. That's also
> > consistent with the present arrangement.
> >
> > Best regards,
> >
> > Brian
> >
> > > hth,
> > > Al
> > >
> > >> nuances of the MA and MP definitions, and I'm curious as to what
> > >> the opinions of others on the lmap list are.
> > >>
> > >> Does this mean that it is possible for the MP to initiate the
> > >> active measurement to the MA, or is the MA always the initiator?
> > >> If the MP can be the initiator in the lmap framework, we would
> > >> still need to configure the MA to respond appropriately.
> Consistent
> > >> with
> > >> already- identified MA functionality, we would need the Controller
> > >> to know the MA is capable of doing this, and be able to send
> > >> Instructions to properly configure the MA. There isn't a
> > >> Measurement Schedule associated with this, and the MA doesn't
> > >> necessarily have any results to include in a Report. Is that ok?
> > >>
> > >> So in the opinion of others on this list, is this scenario covered
> > >> by and in-scope of the current framework, is it allowed but not in
> > >> the current scope of work, or is it inconsistent with others'
> ideas
> > >> of what MAs and MPs are and should be capable of doing (i.e., MAs
> > >> always initiate and MPs can only respond)?
> > >>
> > >> Barbara
> > >>

---

From: KEN KO <[email-masked]>
Date: Wed, 12 Feb 2014 14:56:05 +0000

Brian and Barbara,

This is a very helpful discussion. I need to drill down into what may or may not be an inconsistency below - please clarify.

Brian 1: "... the main thing that distinguishes an MA from the point of view of the framework is that it's the component the Controller can send Instructions to. As long as sending an Instruction to an MA causes the right thing to happen, then what happens between the MA(s) and MP(s), how things are initiated internally and the direction of active measurement traffic within the measurement protocol, should to the extent possible be out of scope."

Brian 2: "One could certainly envision active measurement protocols where the MPs poll active measurement control from the MAs."

Barbara: "Does this mean that it is possible for the MP to initiate the active measurement to the MA, or is the MA always the initiator? For example: Sometimes service providers will initiate measurement tests from the access network to the service provider supplied residential gateway (RG). Before running the test, the RG is first configured to respond to the test appropriately."

I read Brian 1 as saying that the initiator of a Measurement Task is an MA, because only an MA interacts with a Controller and receives an Instruction that gets the ball rolling. Brian 2 extends that thought to what I would call a series of Measurement Tasks polled from an MP, but for it to be consistent with Brian 1 the series would still be initiated by an Instruction via an MA.

Barbara seems to be asking something different. An independently initiated measurement test from the access network to an RG, if it is to be consistent with Brian 1, should be traceable back to an Instruction to an MA. That's fine if the access network source is acting as MA, but I wouldn't phrase it as coming from an MP (no Controller, no Instruction) to an MA, at least not as I read Brian's interpretation. And if the network source is acting as MA, I would refer the RG as acting in the role of MP.

I think lmap can define this consistent with what Brian said or with what Barbara said, but not both. I also view the current wording in lmap to be consistent with Brian's statements.

Looking forward to your responses,
Ken

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Brian Trammell
Sent: Tuesday, February 11, 2014 9:36 AM
To: Al Morton
Cc: STARK, BARBARA H; [email-masked]
Subject: Re: [lmap] Question regarding MA and MP definitions

hi Barbara, Al,

To take this a bit further, I think the main thing that distinguishes an MA from the point of view of the framework is that it's the component the Controller can send Instructions to. As long as sending an Instruction to an MA causes the right thing to happen, then what happens between the MA(s) and MP(s), how things are initiated internally and the direction of active measurement traffic within the measurement protocol, should to the extent possible be out of scope.

> not the same as the control messages that may be exchanged between a 

And these are (and should remain) out of scope, unless I've misunderstood something.

> only device the Controller talks to, which is consistent.

One could certainly envision active measurement protocols where the MPs poll active measurement control from the MAs. That's also consistent with the present arrangement.

Best regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Wed, 12 Feb 2014 16:56:50 +0100

hi Ken, all,

On 12 Feb 2014, at 15:56, KEN KO <[email-masked]> wrote:

> Brian 2: "One could certainly envision active measurement protocols where the MPs poll active measurement control from the MAs.”

To clarify: I mentioned polling here only as an example. The point is that the MA-MP relationship is completely out of the scope of LMAP’s control protocol.

> Barbara: "Does this mean that it is possible for the MP to initiate the active measurement to the MA, or is the MA always the initiator? For example: Sometimes service providers will initiate measurement tests from the access network to the service provider supplied residential gateway (RG). Before running the test, the RG is first configured to respond to the test appropriately.”

Reading this, I presumed that the RG is an MP in this context, and that the RG is configured to become an MP out of band; i.e. by the time the Instruction is sent to the (central) MA, the MP is (from LMAP’s point of view) “magically ready”.

> I read Brian 1 as saying that the initiator of a Measurement Task is an MA, because only an MA interacts with a Controller and receives an Instruction that gets the ball rolling. Brian 2 extends th…

I’d prefer the word “instigated” or “enabled", because “initiated” to me implies that it opens a connection or sends the first packet in an exchange or similar, which is not necessarily the case. But this seems like getting down into terminological weeds, so I’ll stop. :)

> Barbara seems to be asking something different. An independently initiated measurement test from the access network to an RG, if it is to be consistent with Brian 1, should be traceable back to an…

This (final sentence) is how I understood what Barbara said.

Cheers,

Brian

---

From: KEN KO <[email-masked]>
Date: Wed, 12 Feb 2014 16:25:48 +0000

Brian, thanks. Following up below.
Ken

> From: Brian Trammell [mailto:[email-masked]]
> Sent: Wednesday, February 12, 2014 10:57 AM
> To: KEN KO
> Cc: Al Morton; STARK, BARBARA H; [email-masked]
> > This is a very helpful discussion. I need to drill down into what may or may
> not be an inconsistency below - please clarify.
> >
> > Brian 1: "... the main thing that distinguishes an MA from the point of view
> of the framework is that it's the component the Controller can send
> Instructions to. As long as sending an Instruction to an MA causes the right
> thing to happen, then what happens between the MA(s) and MP(s), how
> things are initiated internally and the direction of active measurement traffic
> within the measurement protocol, should to the extent possible be out of
> scope."
> >
> > Brian 2: "One could certainly envision active measurement protocols where
> the MPs poll active measurement control from the MAs."
> 
> To clarify: I mentioned polling here only as an example. The point is that the
> MA-MP relationship is completely out of the scope of LMAP's control
> protocol.

Understood that polling is an example. But is my focus on the phrase "As long as sending an Instruction to an MA causes the right thing to happen, ..." appropriate or misguided? My understanding of your comments is that within the scope of lmap, it is the Instruction sent to the MA that instigates/enables measurement activity. And by that reasoning, measurement activity instigated/enabled within the access network means that lmap would refer to that endpoint as the MA and to the RG as the MP, at least within the context of that activity.

The reason I'm harping on this is that I think Barbara (Barbara, I know you'll correct me if I'm wrong) is asking about a perspective in which the definition of MA is independent of where measurement activity is instigated/enabled - "... it is possible for the MP to initiate the active measurement to the MA ...". That's a valid perspective but I'm not sure whether it is how you are interpreting the draft.

> 
> > Barbara: "Does this mean that it is possible for the MP to initiate the active
> measurement to the MA, or is the MA always the initiator? For example:
> Sometimes service providers will initiate measurement tests from the access
> network to the service provider supplied residential gateway (RG). Before
> running the test, the RG is first configured to respond to the test
> appropriately."
> 
> Reading this, I presumed that the RG is an MP in this context, and that the RG
> is configured to become an MP out of band; i.e. by the time the Instruction is
> sent to the (central) MA, the MP is (from LMAP's point of view) "magically
> ready".
> 
> > I read Brian 1 as saying that the initiator of a Measurement Task is an MA,
> because only an MA interacts with a Controller and receives an Instruction
> that gets the ball rolling. Brian 2 extends that thought to what I would call a
> series of Measurement Tasks polled from an MP, but for it to be consistent
> with Brian 1 the series would still be initiated by an Instruction via an MA.
> 
> I'd prefer the word "instigated" or "enabled", because "initiated" to me
> implies that it opens a connection or sends the first packet in an exchange or
> similar, which is not necessarily the case. But this seems like getting down
> into terminological weeds, so I'll stop. :)
> 
> > Barbara seems to be asking something different. An independently
> initiated measurement test from the access network to an RG, if it is to be
> consistent with Brian 1, should be traceable back to an Instruction to an MA.
> That's fine if the access network source is acting as MA, but I wouldn't phrase
> it as coming from an MP (no Controller, no Instruction) to an MA, at least not
> as I read Brian's interpretation. And if the network source is acting as MA, I
> would refer the RG as acting in the role of MP.
> 
> > I think lmap can define this consistent with what Brian said or with what
> Barbara said, but not both. I also view the current wording in lmap to be
> consistent with Brian's statements.
> >
> > To take this a bit further, I think the main thing that distinguishes an MA
> from the point of view of the framework is that it's the component the
> Controller can send Instructions to. As long as sending an Instruction to an
> MA causes the right thing to happen, then what happens between the
> MA(s) and MP(s), how things are initiated internally and the direction of
> active measurement traffic within the measurement protocol, should to the
> extent possible be out of scope.
> >
> >> is not the same as the control messages that may be exchanged between
> >> a MA and MP.
> >
> >>> BARBARA H
> >>> the current scope of work, or is it inconsistent with others' ideas

---

From: Charles Cook <[email-masked]>
Date: Wed, 12 Feb 2014 17:41:33 -0700

This should generate some discussion.

Here is my crack at an MA vs MP comparison.  Note that in doing this
comparison, I made the assumption that in addition to the MA registering
with the Controller, an MP also needs to be made known to the Controller
so that the Controller can take into consideration the capabilities of
the MP in constructing Measurement Tasks.  This also makes it possible
for the Controller to suppress MPs.  Red text highlight differences
between MAs and MPs.

Device Functionality
--May have MA, MP, or both MA and MP functionality
MA Functionality
--Registers with a Controller
--Receives Instructions from a Controller
--Contacts a MP to execute Measurement Tasks
--Performs access control (if needed) with the MP
--Can either transmit or receive active measurement traffic (depending
on the Measurement Task)
--Must honor reception of suppression messages from a Controller
--May run certain tests against non-LMAP compliant targets (e.g., ping a
content server)
MP Functionality
--Registers with a Controller
--Does _not_receive Instructions from a Controller
--Responds to Measurement Task directed to it from an MA (MP does
_not_initiate contact with MA)
--Performs access control (if needed) with the MA
--Can either transmit or receive active measurement traffic (depending
on the Measurement Task)
--Must honor reception of suppression messages from a Controller

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: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 12 Feb 2014 22:16:53 -0500

Charles,

*         MP Functionality

-        Registers with a Controller

Not necessary, if I understand what you mean by registration (as MP to Controller communication)
- Controller can get a list of MP and capabilities through other means.

I think this is worth clarifying in the text.

Also, I don't see the MP as a recipient of Suppression message from Controller,
especially if there's no communications planned between them.
Al

From: Charles Cook [mailto:[email-masked]]
Sent: Wednesday, February 12, 2014 7:42 PM
To: KEN KO
Cc: Brian Trammell; [email-masked]; MORTON, ALFRED C (AL); STARK, BARBARA H
Subject: MA vs MP

Here is my crack at an MA vs MP comparison.  Note that in doing this comparison, I made the assumption that in addition to the MA registering with the Controller, an MP also needs to be made known to the Controller so that the Controller can take into consideration the capabilities of the MP in constructing Measurement Tasks.  This also makes it possible for the Controller to suppress MPs.  Red text highlight differences between MAs and MPs.

*         Device Functionality

-        May have MA, MP, or both MA and MP functionality

*         MA Functionality

-        Registers with a Controller

-        Receives Instructions from a Controller

-        Contacts a MP to execute Measurement Tasks

-        Performs access control (if needed) with the MP

-        Can either transmit or receive active measurement traffic (depending on the Measurement Task)

-        Must honor reception of suppression messages from a Controller

-        May run certain tests against non-LMAP compliant targets (e.g., ping a content server)

*         MP Functionality

-        Registers with a Controller

-        Does not receive Instructions from a Controller

-        Responds to Measurement Task directed to it from an MA (MP does not initiate contact with MA)

-        Performs access control (if needed) with the MA

-        Can either transmit or receive active measurement traffic (depending on the Measurement Task)

-        Must honor reception of suppression messages from a Controller

Charles

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

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

---

From: <[email-masked]>
Date: Thu, 13 Feb 2014 10:08:35 +0000

Agree with Al.
Suppression is part of the Instruction. The Instruction is the set of measurement methods, schedules and perhaps suppression information which the Controller tells the MA. if the controller was telling the MP about suppression, then it would be sending it an instruction

I don't think sending a suppress to the MP is really needed.
Suppress is (mainly) about not starting new Tasks. Since the MA starts the Task (potentially with a control msg to the MP asking it to start sending a file, say) then it doesn't help to tell the MP.

It's also been suggested to add to the current suppression description an option meaning "also stop Tasks that are in progress" (I am happy to add this as an option) (option = optional to use). I think it's Task specific how this would be done. For instance for a TCP file download from the MP to MA, the MA can end the TCP connection.

Similarly, I don't see the need for the MP to register with the controller.

Side note: often the same device will have both MA and MP functionality. Then there may well be the possibility of doing something clever. Don't think we should work on that in lmap1.0

phil

From: lmap [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C (AL)
Sent: 13 February 2014 03:17
To: [email-masked]; KEN KO
Cc: [email-masked]; STARK, BARBARA H; Brian Trammell
Subject: Re: [lmap] MA vs MP

Charles,

*     MP Functionality

From: Charles Cook [mailto:[email-masked]]
Sent: Wednesday, February 12, 2014 7:42 PM
To: KEN KO
Cc: Brian Trammell; [email-masked]<mailto:[email-masked]>; MORTON, ALFRED C (AL); STARK, BARBARA H
Subject: MA vs MP

*         Device Functionality

*         MA Functionality

*         MP Functionality

Charles

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Feb 2014 11:22:57 +0100

On Thu, Feb 13, 2014 at 10:08:35AM +0000, [email-masked] wrote:
 
> Side note: often the same device will have both MA and MP
> functionality. Then there may well be the possibility of doing
> something clever. Don't think we should work on that in lmap1.0

Perhaps we need to add text that clarifies that you can have an MA
configured to run an active measurement test originating measurement
traffic towards a second MA configured to run a passive measurement
test consuming the measurement traffic. My understanding is that the
current framework allows this. An MP, in contrast to an MA, is
something involved in a measurement but not under the control of an
LMAP controller.

/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: Brian Trammell <[email-masked]>
Date: Thu, 13 Feb 2014 11:28:45 +0100

Agree with Al and Phil on this onw. I'd go so far as to say that if you're registering what you think is an MP with a Controller, then it's actually an MA. That's what "agent" means: it acts on behalf of the controller to make things happen.

While it almost certainly makes sense for some edge devices to be able to be used as an MP or an MA depending on the measurement, it seems to greatly simplify the framework to (1) assume for any given measurement with an MA/MP infrastructure behind the controller-MA interface that there is a _single_ MA responsible for acting on instructions. 

As for suppression, if LMAP doesn't regulate the MA-MP protocol (which IMO it really shouldn't), this protocol must be capable of ensuring that any activity by the MP is suppressed when the MA is suppressed, so I don't see an issue here either.

To Juergen's point on preview:

> test consuming the measurement traffic.

Within the context of this particular measurement, isn't this second MA really an MP? In other words, is the fact that the MP is also in contact with the Controller (for other measurements) just a coincidence?

Cheers,

Brian

On 13 Feb 2014, at 11:08, [email-masked] wrote:

> I don’t think sending a suppress to the MP is really needed.
> Suppress is (mainly) about not starting new Tasks. Since the MA starts the Task (potentially with a control msg to the MP asking it to start sending a file, say) then it doesn’t help to tell the MP.
>  
> It’s also been suggested to add to the current suppression description an option meaning “also stop Tasks that are in progress” (I am happy to add this as an option) (option = optional to use). I think it’s Task specific how this would be done. For instance for a TCP file download from the MP to MA, the MA can end the TCP connection.
>  
> Similarly, I don’t see the need for the MP to register with the controller.
>  
> Side note: often the same device will have both MA and MP functionality. Then there may well be the possibility of doing something clever. Don’t think we should work on that in lmap1.0
>  
> phil
>  
> ·     MP Functionality
> –     Registers with a Controller
>  
> ·         Device Functionality
> –        May have MA, MP, or both MA and MP functionality
> ·         MA Functionality
> –        Registers with a Controller
> –        Receives Instructions from a Controller
> –        Contacts a MP to execute Measurement Tasks
> –        Performs access control (if needed) with the MP
> –        Can either transmit or receive active measurement traffic (depending on the Measurement Task)
> –        Must honor reception of suppression messages from a Controller
> –        May run certain tests against non-LMAP compliant targets (e.g., ping a content server)
> ·         MP Functionality
> –        Registers with a Controller
> –        Does not receive Instructions from a Controller
> –        Responds to Measurement Task directed to it from an MA (MP does not initiate contact with MA)
> –        Performs access control (if needed) with the MA
> –        Can either transmit or receive active measurement traffic (depending on the Measurement Task)
> –        Must honor reception of suppression messages from a Controller
> 
> Charles
> 
> -- 
>  
> Charles Cook 
> Principal Architect
> Network

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Feb 2014 11:59:31 +0100

> Within the context of this particular measurement, isn't this second MA really an MP? In other words, is the fact that the MP is also in contact with the Controller (for other measurements) just a…

If we use

MA = controlled by LMAP controller
MP = not controlled by LMAP controller

then both are MAs. The first one is running a somewhat degenerated
measurement test that generates traffic, the second one is running a
passive measurement test observing the traffic and generating results.
Measurement tests can vary widely and we do not make any specific
assumptions architecturally.

/js

---

From: Brian Trammell <[email-masked]>
Date: Thu, 13 Feb 2014 12:35:23 +0100

hi Juergen,

Sorry, I read this wrong. Yep, you’re right. But I’d still say from an architectural point of view, you’re running two measurements at the same time with two MAs which, due to a coincidence arranged by the controller, will have related results.

Cheers,

Brian

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 13 Feb 2014 13:53:00 +0000

Charles -

  We may have some hidden assumptions just undernieth the surface -

I'll offer this as a litmus test....

   IF the MA/MP are functions only - We may need a "entity" definition of a Probe
That's why I like MA responder / MA initiator functions early on..  and the MA itself was the entity ---  It sounds like we're discussing a split entity vs.  sub functionality...

Functionally - I think Al has a good point - Although the MA/MP's can act without getting permission from the controller per test cycle,  it would be advantageous to have them register with the Controller (self discovery type of thing).
It would also be good for the controller to set a "test policy" for MP's - in which the controller could tell the MP to "not respond" to certain tests ..

Of course this depends upon the existence of logic above the MA/MP function level... or are they equivalent (MA = Probe and functionally type or just the function and there is probe logic above it).

So are MA / MP to different entities or two different functions under an entity.. ?

Just checking to make sure I'm tracking

From: lmap [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C (AL)
Sent: Wednesday, February 12, 2014 9:17 PM
To: Cook, Charles; KEN KO
Cc: [email-masked]; STARK, BARBARA H; Brian Trammell
Subject: Re: [lmap] MA vs MP

Charles,

*         MP Functionality

*         Device Functionality

*         MA Functionality

*         MP Functionality

Charles

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Feb 2014 15:30:12 +0100

> It would also be good for the controller to set a "test policy" for MP's - in which the controller could tell the MP to "not respond" to certain tests ..

A controller does not talk to MPs.
 
> So are MA / MP to different entities or two different functions under an entity.. ?

An MA talks to a controller and receives and executes instructions
received from the controller.

An MP does not talk to a controller but may be involved in a
measurement. The MP and MA may coordinate/control a measurement via a
separate mechanism (e.g. TWAMP) or the MP may even be completely
unaware of being an MP.

LMAP is not definiting the semantics of specific tests and hence your
question is not possible to answer in general. If you want an MP
controlled by an LMAP controller, then it is an MA. KISS.

/js

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 13 Feb 2014 14:43:33 +0000

Juergen -

You state a controller doesn't talk to a MP ...

How about that Test server on the Internet that all the tests run too ?

  Would you classify that as a MA or a MP ?

Thanks,
Mike

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 8:30 AM
To: Bugenhagen, Michael K
Cc: 'MORTON, ALFRED C (AL)'; Cook, Charles; 'KEN KO'; 'Brian Trammell'; 'STARK, BARBARA H'; [email-masked]'
Subject: Re: [lmap] MA vs MP

On Thu, Feb 13, 2014 at 01:53:00PM +0000, Bugenhagen, Michael K wrote:
>    IF the MA/MP are functions only - We may need a "entity" definition 
> of a Probe That's why I like MA responder / MA initiator functions early on..  and the MA itself was the entity ---  It sounds like we're discussing a split entity vs.  sub functionality...
> 

> So are MA / MP to different entities or two different functions under an entity.. ?

An MA talks to a controller and receives and executes instructions received from the controller.

An MP does not talk to a controller but may be involved in a measurement. The MP and MA may coordinate/control a measurement via a separate mechanism (e.g. TWAMP) or the MP may even be completely unaware of being an MP.

LMAP is not definiting the semantics of specific tests and hence your question is not possible to answer in general. If you want an MP controlled by an LMAP controller, then it is an MA. KISS.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Feb 2014 15:52:55 +0100

>   Would you classify that as a MA or a MP ?

If it talks to a Contoller and receives and executes instructions, it
is an MA. Otherwise, it is an MP. I really do not understand why this
is complicated.

/js

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 13 Feb 2014 15:13:13 +0000

So here I agree with Al.

I want to register the MP with the Controller so I can -

1) Tell the Controller my capabilities (especially when the change - like a port goes down)
	
	Examples - So that I can 
	-  Tell the Controller which tests my test server can support so the controller doesn't create non-runnable tests
	-  So the Controller has some state awareness of the test server(s) state - remember scale means we could have many test servers going up and down, especially in cloud platforms
	-  So I can tell the Test server what MA's we like vs. don't want to talk to (host the world or only my MA's)

Getting users to state their requirements is always tough... but shouldn't be...

IMO -- Somewhat of a cap statement -

    MC to MA/MP -- Scheduling goes to MA's only,  but admin and control goes to both

  Does this sound agreeable ?

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 8:53 AM
To: Bugenhagen, Michael K
Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; [email-masked]'; 'KEN KO'; 'STARK, BARBARA H'; 'Brian Trammell'
Subject: Re: [lmap] MA vs MP

>   Would you classify that as a MA or a MP ?

If it talks to a Contoller and receives and executes instructions, it is an MA. Otherwise, it is an MP. I really do not understand why this is complicated.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Feb 2014 16:22:52 +0100

>     MC to MA/MP -- Scheduling goes to MA's only,  but admin and control goes to both

By definition, the LMAP controller does not talk to an MP and hence
the above statement is false.

You are talking about a case where the controller talks to two MAs
that carry out a measurement between them. I believe the framework
allows for this.

/js

---

From: <[email-masked]>
Date: Thu, 13 Feb 2014 15:25:21 +0000

Al said: "Not necessary, if I understand what you mean by registration (as MP to Controller communication) - Controller can get a list of MP and capabilities through other means". So NOT what you are proposing.

I think everyone understands both sides of the discussion. Just that a group of us want to keep things simple and don't see it as a requirement to standardise how a Controller knows about Measurement Peers and therefore certainly don't want to get into a subsequent discussion about controlling them.

Some re-iterated reasons:
- a MP is often a basic server with standard functionality (e.g. web server, router)
- if the MAs and MPs are under one domain, MA control is completely sufficient to stop testing
- if the MP is under another domain, then it certainly won't be talking to your controller anyway
- MPs can be considered to have their own control infrastructure already (e.g. network or server management)

Trevor.

Trevor Burbridge
Network Infrastructure & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 640929

This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails. 
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000 

>From: lmap [mailto:[email-masked]] On Behalf Of Bugenhagen, Michael
>K
>Sent: 13 February 2014 15:13
>To: 'Juergen Schoenwaelder'
>	-  Tell the Controller which tests my test server can support so the
>controller doesn't create non-runnable tests
>	-  So the Controller has some state awareness of the test server(s) state -
>remember scale means we could have many test servers going up and down,
>especially in cloud platforms
>If it talks to a Contoller and receives and executes instructions, it is an MA.
>Otherwise, it is an MP. I really do not understand why this is complicated.
>
>/js
>
>--

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 13 Feb 2014 15:28:08 +0000

Juergen -

    If we are academically bound to a definition vs. use case requirements you are correct.
This also indicates that MP's are just an abstract name for anything that responds to a test that isn't under the control of the MC (if you follow use case requirements).
  So MP's are existing artifacts like ping responders, TWAMP responders, ... anything that can be a test peer that isn't talking to the MA...

So MP's are not LMAP artifacts per say in your definition ?

   Agreed ? - I'm ok with that 

However - many people classify the MP as ALL and ANY test peer so that definition breaks in that context and use...

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 9:23 AM
To: Bugenhagen, Michael K
Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; [email-masked]'; 'KEN KO'; 'STARK, BARBARA H'; 'Brian Trammell'
Subject: Re: [lmap] MA vs MP

>     MC to MA/MP -- Scheduling goes to MA's only,  but admin and 

By definition, the LMAP controller does not talk to an MP and hence the above statement is false.

You are talking about a case where the controller talks to two MAs that carry out a measurement between them. I believe the framework allows for this.

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 13 Feb 2014 15:34:51 +0000

> > Within the context of this particular measurement, isn't this second MA
> really an MP? In other words, is the fact that the MP is also in contact with
> the Controller (for other measurements) just a coincidence?
> >
> 
> If we use
> 
> measurement test that generates traffic, the second one is running a passive
> measurement test observing the traffic and generating results.

I think this is a workable definition, but in order to consider multiple options before settling on any particular, I'd like to suggest something just a little different.
MA = as defined in framework: "The function that receives Instructions from a Controller, performs Measurement Tasks (perhaps in concert with a    Measurement Peer) and reports Measurement Results to a Collector."
MP = any endpoint that an MA communicates with as part of an Active Measurement Task.

In this context, the MP is defined from the perspective of the MA as being "the other end of an Active Measurement Task from me (the MA)".
As such, the MP is not a function that has "functional requirements" of any sort nor is it a role that an MA has (because the MP is *always* not in the MA we are looking at). If we focus our attention on an MA and look at things from its perspective, then the MA is "here" and the MP is "not here". MP is an unknown (other than the IP address) "something". This "something" might not even really know how to do the Active Measurement Task. The MA can make no a priori assumptions about this "something" and a robust MA should be designed with that in mind. This "something" and the fact that details about it are unknown to the MA is an important concept.

Whether the MA's Controller (or the entity operating the MA's Controller) knows about these "somethings" is unknown to the MA. The MA doesn't know what the Controller or the entity knows.

Now consider 2 MAs (MA1 and MA2), each living in its own little world. Each knows who its Controller is, knows its Measurement Methods, Reports and Measures according to Instructions, and in all ways behaves like a perfect little MA. There is an Active Measurement Task that occurs with these 2 MAs as endpoints. What I am proposing is that MA1 sees MA2 as its MP, and MA2 sees MA1 as its MP. MP has no functional requirements and cannot be embodied as a role or function, because whatever MA we are focusing our attention on (designing, Controlling, Instructing, getting Reports from, etc.), the MP is somewhere else.

If these 2 MAs are controlled by the same Controller, then that's fine. Neither MA knows or cares. The Controller sees "MPs" as being whatever one of its MAs is interacting with for an Active Measurement Task.

It's also fine if the 2 MAs have different Controllers operated by distinct entities. Neither MA cares or knows.

If an entity wants to ensure that all endpoints involved in Active Measurement Tasks are well-behaved and appropriately Controlled and Instructed (i.e., they are all MAs), then that is something the entity has to do. How the entity does this is not in scope of lmap. And MAs do not care or know whether its operating entity is doing this.
Barbara

---

From: "Sharam Hakimi" <[email-masked]>
Date: Thu, 13 Feb 2014 10:46:03 -0500

All,
I agree with Al, MP is a responder function and not under control of MC
or MA. MA uses an MP to perform a measurement task. 

However, I would caution greatly on having a same device to have a MA
and MP function. These are two independent functions with no
communications between them. Two TCP-throughput test running at the same
time can easily overwhelm the network if not the single device and the
two functions (MA,MP ) will not have any information that the other one
is running.

Sharam

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Bugenhagen,
Michael K
Sent: Thursday, February 13, 2014 10:28 AM
To: 'Juergen Schoenwaelder'
Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; [email-masked]'; 'KEN KO';
'STARK, BARBARA H'; 'Brian Trammell'
Subject: Re: [lmap] MA vs MP

Juergen -

    If we are academically bound to a definition vs. use case
requirements you are correct.
This also indicates that MP's are just an abstract name for anything
that responds to a test that isn't under the control of the MC (if you
follow use case requirements).
  So MP's are existing artifacts like ping responders, TWAMP responders,
... anything that can be a test peer that isn't talking to the MA...

However - many people classify the MP as ALL and ANY test peer so that
definition breaks in that context and use...

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 9:23 AM
To: Bugenhagen, Michael K
Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; [email-masked]'; 'KEN KO';
'STARK, BARBARA H'; 'Brian Trammell'
Subject: Re: [lmap] MA vs MP

>     MC to MA/MP -- Scheduling goes to MA's only,  but admin and 

By definition, the LMAP controller does not talk to an MP and hence the
above statement is false.

You are talking about a case where the controller talks to two MAs that
carry out a measurement between them. I believe the framework allows for
this.

/js

---

From: KEN KO <[email-masked]>
Date: Thu, 13 Feb 2014 15:46:17 +0000

+1

I do think that if this interpretation has a consensus in lmap, it will need a few text edits beyond just the definition of a Measurement Peer in Terminology. Figure 1 and other instances in the draft have led some of us (or at least one of us) to interpret MA and MP in lmap as functions that may (or may not) coexist side by side in a measurement "container." 

Ken

> From: STARK, BARBARA H [mailto:[email-masked]]
> Sent: Thursday, February 13, 2014 10:35 AM
> To: Juergen Schoenwaelder; Brian Trammell
> Cc: [email-masked] EARDLEY; [email-masked];
> MORTON JR., AL; KEN KO; [email-masked]
> Subject: RE: [lmap] MA vs MP
> 
> > > > configured to run an active measurement test originating
> > > > measurement traffic towards a second MA configured to run a
> > > > passive measurement test consuming the measurement traffic.
> > >
> > really an MP? In other words, is the fact that the MP is also in
> > contact with the Controller (for other measurements) just a coincidence?
> > >
> >
> > If we use
> >
> I think this is a workable definition, but in order to consider multiple options
> before settling on any particular, I'd like to suggest something just a little
> different.
> MA = as defined in framework: "The function that receives Instructions from
> a Controller, performs Measurement Tasks (perhaps in concert with a
> Measurement Peer) and reports Measurement Results to a Collector."
> In this context, the MP is defined from the perspective of the MA as being
> "the other end of an Active Measurement Task from me (the MA)".
> As such, the MP is not a function that has "functional requirements" of any
> sort nor is it a role that an MA has (because the MP is *always* not in the MA
> we are looking at). If we focus our attention on an MA and look at things
> from its perspective, then the MA is "here" and the MP is "not here". MP is
> an unknown (other than the IP address) "something". This "something"
> might not even really know how to do the Active Measurement Task. The
> MA can make no a priori assumptions about this "something" and a robust
> MA should be designed with that in mind. This "something" and the fact that
> details about it are unknown to the MA is an important concept.
> 
> Whether the MA's Controller (or the entity operating the MA's Controller)
> knows about these "somethings" is unknown to the MA. The MA doesn't
> know what the Controller or the entity knows.
> 
> Now consider 2 MAs (MA1 and MA2), each living in its own little world. Each
> knows who its Controller is, knows its Measurement Methods, Reports and
> Measures according to Instructions, and in all ways behaves like a perfect
> little MA. There is an Active Measurement Task that occurs with these 2 MAs
> as endpoints. What I am proposing is that MA1 sees MA2 as its MP, and MA2
> sees MA1 as its MP. MP has no functional requirements and cannot be
> embodied as a role or function, because whatever MA we are focusing our
> attention on (designing, Controlling, Instructing, getting Reports from, etc.),
> the MP is somewhere else.
> 
> If these 2 MAs are controlled by the same Controller, then that's fine.
> Neither MA knows or cares. The Controller sees "MPs" as being whatever
> one of its MAs is interacting with for an Active Measurement Task.
> 
> If an entity wants to ensure that all endpoints involved in Active
> Measurement Tasks are well-behaved and appropriately Controlled and
> Instructed (i.e., they are all MAs), then that is something the entity has to do.
> How the entity does this is not in scope of lmap. And MAs do not care or
> know whether its operating entity is doing this.
> Barbara

---

From: KEN KO <[email-masked]>
Date: Thu, 13 Feb 2014 15:55:07 +0000

Sharam,

I think the view you are expressing exposes a problem with interpreting MA and MP as functions that are isolated from each other, more so than a caution about whether to implement them in the same device. Even if you interpret them as functions (and I think a better model is the one proposed recently by Barbara), if they are implemented together there should be nothing preventing them from coordinating with each other.

Ken

> From: Sharam Hakimi [mailto:[email-masked]]
> Sent: Thursday, February 13, 2014 10:46 AM
> To: Bugenhagen, Michael K; Juergen Schoenwaelder
> Cc: Cook, Charles; MORTON, ALFRED C (AL); [email-masked]; KEN KO; STARK,
> BARBARA H; Brian Trammell
> I agree with Al, MP is a responder function and not under control of MC or
> MA. MA uses an MP to perform a measurement task.
> 
> However, I would caution greatly on having a same device to have a MA and
> MP function. These are two independent functions with no communications
> between them. Two TCP-throughput test running at the same time can easily
> overwhelm the network if not the single device and the two functions
> (MA,MP ) will not have any information that the other one is running.
> 
> Sharam
> 
> 
> 
> This also indicates that MP's are just an abstract name for anything that
> responds to a test that isn't under the control of the MC (if you follow use
> case requirements).
>   So MP's are existing artifacts like ping responders, TWAMP responders, ...
> anything that can be a test peer that isn't talking to the MA...
> 
> You are talking about a case where the controller talks to two MAs that carry
> out a measurement between them. I believe the framework allows for this.
> 
> /js
> 
> --

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 13 Feb 2014 15:56:20 +0000

I wish we hadn't called it a Measurement Peer (MP)...
   Contextually that stomps all over different naming conventions and defies logic for many 

MP is a very high level abstraction... that covers too much
   I would prefer some naming that actually reflects what it does -  AMP (autonomous Measurement Peer)... 

Which means it acts on it's one...

So you'd have 
  LMAP MP's (which are MA's under the controller)
  Autonomous MP's (Which aren't under a MA or the Controller)

Tongue in cheek -   Depends how much job security you want - if they can't understand it with plane old semantics don't change it :)

I'm good now that we're all on the same page -
What are the group's druthers (what definition does the group want  / think is appropriate).

Mike

-----Original Message-----
From: Sharam Hakimi [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 9:46 AM
To: Bugenhagen, Michael K; Juergen Schoenwaelder
Cc: Cook, Charles; MORTON, ALFRED C (AL); [email-masked]; KEN KO; STARK, BARBARA H; Brian Trammell
Subject: RE: [lmap] MA vs MP

All,
I agree with Al, MP is a responder function and not under control of MC or MA. MA uses an MP to perform a measurement task. 

However, I would caution greatly on having a same device to have a MA and MP function. These are two independent functions with no communications between them. Two TCP-throughput test running at the same time can easily overwhelm the network if not the single device and the two functions (MA,MP ) will not have any information that the other one is running.

Sharam

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Bugenhagen, Michael K
Sent: Thursday, February 13, 2014 10:28 AM
To: 'Juergen Schoenwaelder'
Cc: Cook, Charles; 'MORTON, ALFRED C (AL)'; [email-masked]'; 'KEN KO'; 'STARK, BARBARA H'; 'Brian Trammell'
Subject: Re: [lmap] MA vs MP

Juergen -

-----Original Message-----

/js

---

From: "Sharam Hakimi" <[email-masked]>
Date: Thu, 13 Feb 2014 11:15:17 -0500

Ken,
Maybe it would be good to have three entities:

	MA
	MP 
	MA and MP Combination

Cautions, or warnings will not work in my opinion and forcing users to
only use one function in a single device will most likely not be
acceptable.

This way a combination device will be aware of the other and effectively
execute one test at a time (internally sequenced).

Sharam

-----Original Message-----
From: KEN KO [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 10:55 AM
To: Sharam Hakimi; Bugenhagen, Michael K; Juergen Schoenwaelder
Cc: Cook, Charles; MORTON, ALFRED C (AL); [email-masked]; STARK, BARBARA
H; Brian Trammell

Sharam,

I think the view you are expressing exposes a problem with interpreting
MA and MP as functions that are isolated from each other, more so than a
caution about whether to implement them in the same device. Even if you
interpret them as functions (and I think a better model is the one
proposed recently by Barbara), if they are implemented together there
should be nothing preventing them from coordinating with each other.

Ken

and
>     If we are academically bound to a definition vs. use case
requirements you
> are correct.
that
> By definition, the LMAP controller does not talk to an MP and hence
the
> You are talking about a case where the controller talks to two MAs
that carry

---

From: <[email-masked]>
Date: Thu, 13 Feb 2014 17:51:50 +0000

I don't think we need to define a combined MA-MP function.

In a subsequent phase of LMAP we might work on an intra-device interface, ie between MA & MP on the same device - think it's quite likely this could enable some fun things (such as sharam's example). 
At the moment we're not working on such an intra-device interface, so I don't see the need to define a combined MA-MP function.

re sharam's problem scenario - I think this will largely be avoided because we assume single party control (and that party designs the measurement system carefully).

Best wishes
phil

> From: lmap [mailto:[email-masked]] On Behalf Of Sharam Hakimi
> Sent: 13 February 2014 16:15
> To: KEN KO; Bugenhagen, Michael K; Juergen Schoenwaelder
> Cc: STARK, BARBARA H; Brian Trammell; Cook, Charles; MORTON, ALFRED C
> (AL); [email-masked]
> This way a combination device will be aware of the other and
> effectively execute one test at a time (internally sequenced).
> 
> 
> Sharam
> 
> 
> 
> MA and MP as functions that are isolated from each other, more so than
> a caution about whether to implement them in the same device. Even if
> you interpret them as functions (and I think a better model is the one

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 13 Feb 2014 18:11:21 +0000

What we do is up to the group -- but just a thought...

  When choosing naming - some advice for Cloud...

Cloud API's use "abstractions" to handle when two different vendors, SDO's, or Service providers naming don't align for a given network function or role...
So IF... IF you want to grab the "cloud" API place holder you MUST have very, very tight hierarchical naming conventions that bind very clearly to specific levels and roles.
As they told Indiana Jones in the Movie -  Choose well....

Example -
  EVC generically covers all VLANS of all types...

	The MEF assigned EVC as being terminated ONLY on UNI's... 
	So when they added Ethernet ACCES we had to say it's an OVC.

BUT - in the API object model used between companies a EVC was the abstract construct for everything.
So now we're faced with fixing that mess as we move to a NaaS API ... what to call an Ethernet Segment - EVC ?  one of the SDO's used that abstract contextually so we have breakage.

So....

 Sorry for the preaching - but choose naming ("abstractions") nomenclature very carefully - if it doesn't fit as ubiquitous in the industry it will fail when applied in a Service Construct API,
.which is why I offered the Hierarchical view of doing the naming convention - Given NFV is about to break loose
 - I think all going for the ride should keep their arms and legs inside the car at all times...  

Which is a great metaphor for an amusement park ride rules for observing non-cloud portable abstractions that could get sheared off - you can do it... the result may be fun, or not so fun.
Maybe my example will be lost in translation - but it might be worth observing.

I have said enough on it so unless someone asks specifically I'm good.
Thanks,
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 11:52 AM
To: [email-masked]; [email-masked]; Bugenhagen, Michael K; [email-masked]
Cc: [email-masked]; [email-masked]; Cook, Charles; [email-masked]; [email-masked]
Subject: RE: [lmap] MA vs MP

Best wishes
phil

> Cc: Cook, Charles; MORTON, ALFRED C (AL); [email-masked]; STARK, 
> I think the view you are expressing exposes a problem with 
> interpreting MA and MP as functions that are isolated from each other, 
> more so than a caution about whether to implement them in the same 
> device. Even if you interpret them as functions (and I think a better 
> model is the one proposed recently by Barbara), if they are 
> implemented together there should be nothing preventing them from coordinating with each other.
> 
> Ken
>

---

From: "Sharam Hakimi" <[email-masked]>
Date: Thu, 13 Feb 2014 14:13:40 -0500

Phil,
We can kick the can down the road and try to deal with it later,
however, even if one entity is designing the network this is a very easy
thing to do. All one would have to do is to set the device to be an MP
and that device is at the mercy of all other MAs that will use it as a
responder at any time. When that device is set to be an MA also, then we
are asking the user to coordinate all other schedules that use that
device as an MP to not to clash with the MA schedule running on that
device. Are you still following me?

I personally do not believe that the user will have the necessary
information to be able to make that decision even if they really tried,
but that is my opinion.

Cheers,
Sharam

-----Original Message-----
From: Bugenhagen, Michael K
[mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 1:11 PM
To: [email-masked]'; Sharam Hakimi; [email-masked]';
[email-masked]'
Cc: [email-masked]'; [email-masked]'; Cook, Charles;
[email-masked]'; [email-masked]'
Subject: RE: [lmap] MA vs MP

Cloud API's use "abstractions" to handle when two different vendors,
SDO's, or Service providers naming don't align for a given network
function or role...
So IF... IF you want to grab the "cloud" API place holder you MUST have
very, very tight hierarchical naming conventions that bind very clearly
to specific levels and roles.
As they told Indiana Jones in the Movie -  Choose well....

Example -

BUT - in the API object model used between companies a EVC was the
abstract construct for everything.
So now we're faced with fixing that mess as we move to a NaaS API ...
what to call an Ethernet Segment - EVC ?  one of the SDO's used that
abstract contextually so we have breakage.

So....

 Sorry for the preaching - but choose naming ("abstractions")
nomenclature very carefully - if it doesn't fit as ubiquitous in the
industry it will fail when applied in a Service Construct API,
.which is why I offered the Hierarchical view of doing the naming
convention - Given NFV is about to break loose
 - I think all going for the ride should keep their arms and legs inside
the car at all times...  

Which is a great metaphor for an amusement park ride rules for observing
non-cloud portable abstractions that could get sheared off - you can do
it... the result may be fun, or not so fun.
Maybe my example will be lost in translation - but it might be worth
observing.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 11:52 AM
To: [email-masked]; [email-masked]; Bugenhagen, Michael K;
[email-masked]
Cc: [email-masked]; [email-masked]; Cook, Charles;
[email-masked]; [email-masked]
Subject: RE: [lmap] MA vs MP

In a subsequent phase of LMAP we might work on an intra-device
interface, ie between MA & MP on the same device - think it's quite
likely this could enable some fun things (such as sharam's example). 
At the moment we're not working on such an intra-device interface, so I
don't see the need to define a combined MA-MP function.

re sharam's problem scenario - I think this will largely be avoided
because we assume single party control (and that party designs the
measurement system carefully).

Best wishes
phil

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 13 Feb 2014 21:06:21 +0000

> We can kick the can down the road and try to deal with it later, however,
> even if one entity is designing the network this is a very easy thing to do. All
> one would have to do is to set the device to be an MP and that device is at
> the mercy of all other MAs that will use it as a responder at any time. When
> that device is set to be an MA also, then we are asking the user to coordinate
> all other schedules that use that device as an MP to not to clash with the MA
> schedule running on that device. Are you still following me?
> 
> I personally do not believe that the user will have the necessary information
> to be able to make that decision even if they really tried, but that is my
> opinion.

I didn't think we were asking the user to do anything at all. We have specified things we expect of an MA. For example, we want an MA to either report if "other" things happened during a Measurement Task that could impact the Measurement Task (e.g., other packets were transmitted/received during this Measurement Task) or to hold off starting a scheduled Measurement Task if "other" things are happening or to refuse to participate in a Measurement Task with some other MA if it is busy doing its own Measurement Task. Such behavior might be hard-coded (in a simple MA) or a configuration option in a more capable MA. If it could be a configuration option, then this would need to be reflected in an Information Model of some sort.

For example, let's say MA1 is participating in an Active Measurement Task that was initiated by MA2. MA1 is now MA2's MP and MA2 is MA1's MP (according to my proposed viewpoint). MA1 told its Controller that it was capable of participating in this Active Measurement Method in this manner and was configured by its Controller to enable such participation, and also to collect and subsequently report certain passive measurements when it was participating in a Task of this Method. MA2 told its Controller about its ability to do this Active Measurement Method and its Controller scheduled it to initiate an Active Measurement Task at a particular time and report results. MA1 may also be scheduled to initiate a different Active Measurement Task while it is busy with MA2. MA1 knows it is busy with MA2. MA1 is hard-coded to delay its own scheduled Tasks in such an event and to refuse any requests to participate in other Tasks that it receives during its own scheduled Tasks. This isn't that hard to code, as long as the MA knows everything it's doing (and the functionality isn't split unnecessarily into separate Functions that potentially have no visibility into what the other is doing).

A simpler MA may not support any Active Measurement Methods initiated by other MAs. That's ok. Or it may only support Active Measurements initiated by other MAs and have no ability to initiate (schedule) its own Measurement Tasks. That's ok, too. There is no mandatory-to-implement Measurement Method.

Now consider the case where MA1 and MA2 are within the same operational domain (and potentially, but not necessarily, under the same Controller). The operator of this domain could potentially configure the 2 MAs so MA1 is able to authenticate MA2 before proceeding with a Measurement Task (if that's something that can be done for that Measurement Method). Or so that MA1 and MA2 schedules are coordinated and won't overlap. Nothing in lmap defines how the operator coordinates the schedules of its MAs (because it's not in scope of lmap). But nothing in lmap precludes an operator from doing this. It's left as an exercise to the operator. (Not the end user.)

We don't need functional requirements for a second Measurement-Method-capable, Controller-managed, Collector-reporting function. One term (MA) is enough. More than one is redundant and confusing.
Barbara

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Feb 2014 08:18:21 +0100

> I do think that if this interpretation has a consensus in lmap, it will need a few text edits beyond just the definition of a Measurement Peer in Terminology. Figure 1 and other instances in the dr…

It is a feature to be agnostic about how things are packaged.

Yes, MAs and MPs may (or may not) coexist side by side. This is a
feature, not a bug. It is an implementation and deployment decision
whether you want them to coexist side by side or not.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Feb 2014 08:04:48 +0100

> This also indicates that MP's are just an abstract name for anything that responds to a test that isn't under the control of the MC (if you follow use case requirements).

Yep.

>   So MP's are existing artifacts like ping responders, TWAMP responders, ... anything that can be a test peer that isn't talking to the MA...

Nope. A ping responder talks to the MA. Perhaps you meant MC.

>    Agreed ? - I'm ok with that 

Depends how you define "LMAP artifacts". They are surely not involved
in any LMAP 1.0 protocols. This is what the current framework says.

> However - many people classify the MP as ALL and ANY test peer so
> that definition breaks in that context and use...

But this is not the LMAP definition of MP as written down in the
framework document. If people come with different definitions of terms
in their heads and then start debates because the framework seems odd,
then we do not really make progress. There is a reason why the LMAP
terminology got written down as part of the framework document - so
lets simply use it.

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 14 Feb 2014 13:30:18 +0000

> responds to a test that isn't under the control of the MC (if you follow use

So only Ken said +1 for my alternative suggestion of MP as simply being whatever an MA interacts with for an Active Measurement Task.
While Ken may curse me for doing this, let me see then if I can make an alternate suggestion that would take my interpretation of Juergen's statements a bit further.

Going back to a previous posting where Juergen said:
MA = controlled by LMAP controller
MP = not controlled by LMAP controller

This to me means that an Active Measurement Task could occur between any combination of 2 or more MAs and MPs (because an Active Measurement Task shouldn't be dependent on whether or not an endpoint is Controlled). In a 2-endpoint Active Measurement Task, this could be MA-MA, MA-MP, or MP-MP. I recognize that lmap doesn't care about MP-MP (active measurement task between uncontrolled measurement endpoints), but part of the problem we're facing is the desire on the part of some to harmonize BBF and LMAP terminology. BBF service providers care about understanding the impact that active measurements between uncontrolled measurement endpoints has on the network and on other measurements and traffic running across the network. So we need terminology that allows us to talk about this. I think perhaps that defining Active Measurement Methods (Tasks) in lmap in a way that does not make it depend on one of the endpoints being controlled and the other not being controlled could solve our BBF / LMAP terminology issue.

If the Active Measurement Method (Task) definition were changed from
   Active Measurement Method (Task): A type of Measurement Method (Task)
   that involves a Measurement Agent and a Measurement Peer (or possibly
   Peers), where either the Measurement Agent or the Measurement Peer
   injects Active Measurement Traffic into the network destined for the
   other, and which involves one of them measuring some performance or
   reliability parameter associated with the transfer of the traffic.

To something along the lines of
   Active Measurement Method (Task): A type of Measurement Method (Task)
   that involves any combination of two or more Measurement Agents and Measurement Peers , 
   where any endpoint
   injects Active Measurement Traffic into the network destined for the
   other(s), and which involves at least one of them measuring some performance or
   reliability parameter associated with the transfer of the traffic.

MAs and MPs are only distinguished by their controllability and can potentially support identical Measurement Methods.

The MA definition would change slightly from
   Measurement Agent (MA): The function that receives Instructions from
   a Controller, performs Measurement Tasks (perhaps in concert with a
   Measurement Peer) and reports Measurement Results to a Collector.
to
   Measurement Agent (MA): The function that receives Instructions from
   a Controller, performs Measurement Tasks (perhaps in concert with one or more other Measurement Agents or 
   Measurement Peers) and reports Measurement Results to a Collector.

And MP would change from
   Measurement Peer: The function that receives control messages and
   Active Measurement Traffic from a Measurement Agent and may reply to
   the Measurement Agent as defined by the Active Measurement Method.
to
   Measurement Peer: A function that has no Controller interface and 
   performs Measurement Tasks (perhaps in concert with one or more other Measurement Peers or 
   Measurement Agents).

Would this work?
Barbara

---

From: KEN KO <[email-masked]>
Date: Fri, 14 Feb 2014 14:05:25 +0000

> So only Ken said +1 for my alternative suggestion of MP as simply being
> whatever an MA interacts with for an Active Measurement Task.
> While Ken may curse me for doing this, let me see then if I can make an
> alternate suggestion that would take my interpretation of Juergen's
> statements a bit further.

No cursing. Maybe a little muttering, but that only relates to the minor wordsmithing I would suggest if this leads towards consensus.

> MP = not controlled by LMAP controller

Brian said something similar that resonated with me: "That's what 'agent' means: it acts on behalf of the controller to make things happen."

If MA and MP can be defined strictly in terms of their relationship or lack thereof to the Controller, without any dependency on who does what in a Measurement Task:
- It eliminates unnecessary restrictions (real or implied) in the definition of Measurement Methods.
- It leads the way to clarifying the draft. As recent emails on the list show, the current language seems to allow too many interpretations.

Ken

---

From: Charles Cook <[email-masked]>
Date: Fri, 14 Feb 2014 08:05:41 -0700

I can work with Barbara's proposed definitions.  I would like to hear
what others have to say.  Bottom line is that, like Ken, I want to see
something that leads to consensus.

Charles

-- 

Charles Cook 
Principal Architect
Network

---

From: "Sharam Hakimi" <[email-masked]>
Date: Fri, 14 Feb 2014 10:57:33 -0500

MPs are effectively Measurement Responders. Two Measurement responders
could not perform a test by the current definitions. This would mean
that I could assign a test to two entities that I do not even control.

Can we call a spade  a spade. MP should really be called a measurement
Responder (MR) and I believe the term Responder is well understood ( it
does not initiate tests).

As an example two OWAMP or TWAMP responders cannot initiate a test
between themselves. Nor can a TWAMP initiator can start a test between
two TWAMP Responders.

In my opinion the current definitions are ok and Measurement tasks are
sent to the MA and the test is between the MA and the MP (MR).
The main question is what happens when these two functions within the
same device. I believe we need to solve that and provide either control
or text as to the consequences.

Thanks,
Sharam  

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Charles Cook
Sent: Friday, February 14, 2014 10:06 AM
To: STARK, BARBARA H
Cc: MORTON JR., AL; [email-masked]'; Juergen Schoenwaelder; Bugenhagen,
Michael K; 'KEN KO'; 'Brian Trammell'
Subject: Re: [lmap] MA vs MP

Charles

that
> So only Ken said +1 for my alternative suggestion of MP as simply
being whatever an MA interacts with for an Active Measurement Task.
> While Ken may curse me for doing this, let me see then if I can make
an alternate suggestion that would take my interpretation of Juergen's
statements a bit further.
> This to me means that an Active Measurement Task could occur between
any combination of 2 or more MAs and MPs (because an Active Measurement
Task shouldn't be dependent on whether or not an endpoint is
Controlled). In a 2-endpoint Active Measurement Task, this could be
MA-MA, MA-MP, or MP-MP. I recognize that lmap doesn't care about MP-MP
(active measurement task between uncontrolled measurement endpoints),
but part of the problem we're facing is the desire on the part of some
to harmonize BBF and LMAP terminology. BBF service providers care about
understanding the impact that active measurements between uncontrolled
measurement endpoints has on the network and on other measurements and
traffic running across the network. So we need terminology that allows
us to talk about this. I think perhaps that defining Active Measurement
Methods (Tasks) in lmap in a way that does not make it depend on one of
the endpoints being controlled and the other not being controlled could
solve
  our BBF
  / LMAP terminology issue.
> MAs and MPs are only distinguished by their controllability and can
potentially support identical Measurement Methods.

-- 

Charles Cook 
Principal Architect
Network

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Feb 2014 17:13:06 +0100

> does not initiate tests).

This is not true or may be confusing. You can have an MA using a
non-LMAP control protocol to trigger an MP sending traffic to an MA.

> or text as to the consequences.

I fail to see why it matters how you bundle stuff into devices.

/js

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 14 Feb 2014 11:27:48 -0500

> non-LMAP control protocol to trigger an MP sending traffic to an MA.

yes, said this just recently:  "OWAMP can do it."
Al

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 14 Feb 2014 16:51:34 +0000

> MPs are effectively Measurement Responders. Two Measurement
> responders could not perform a test by the current definitions. This would
> mean that I could assign a test to two entities that I do not even control.

I disagree with this definition of MP. I believe lmap is an operational framework and that its key functions need to be defined in operational terms, and not in terms of their roles in active measurement tasks.

I find Juergen's proposed distinction between MA and MP (whether or not they have a Controller interface) to be very workable. But this means that an MA and an MP can potentially perform identical roles in an active Measurement Task. The set of Measurement Methods that can be implemented in an MA and MP are the same. The Information Model should take into account that not all Measurement Tasks are scheduled -- some may occur in reaction to external stimuli. It will need to be possible for the Controller to enable/disable these.
Barbara

---

From: "Sharam Hakimi" <[email-masked]>
Date: Fri, 14 Feb 2014 12:12:19 -0500

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 11:28 AM
To: Juergen Schoenwaelder; Sharam Hakimi
Cc: [email-masked]; STARK, BARBARA H; [email-masked];
Bugenhagen, Michael K; KEN KO; Brian Trammell
Subject: RE: [lmap] MA vs MP

> > MPs are effectively Measurement Responders. Two Measurement
responders

My point was between an MP and another MP, not between an MP and MA. 

Sharam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Feb 2014 18:31:17 +0100

> I find Juergen's proposed distinction between MA and MP (whether or not they have a Controller interface) to be very workable. But this means that an MA and an MP can potentially perform identical…

You schedule a passive measurement task - I believe the information
model is just fine with that. This is even better than enable/disable
because I can control during which times it is enabled. ;-)

/js

---

From: "Sharam Hakimi" <[email-masked]>
Date: Fri, 14 Feb 2014 12:34:07 -0500

MC controls MA

	MC does not control  MP

	MA does not control MP

	MA sends Requests to MP

    	MA cannot initiate task  for  MP <-> MP  test

	MP cannot initiate task  for MA <-> MA or MP  test  ( MP can
originate a test after it is initiated by an MA)

	MA cannot initiate task  for MA <-> MA  test

	MA  Can initiate task    for   MA <-> MP test

This tells me that MP is a Responder.

Thanks,
Sharam

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 11:52 AM
To: Sharam Hakimi; [email-masked]
Cc: MORTON JR., AL; [email-masked]; Juergen Schoenwaelder; Bugenhagen,
Michael K; KEN KO; Brian Trammell
Subject: RE: [lmap] MA vs MP

> mean that I could assign a test to two entities that I do not even
control.

I disagree with this definition of MP. I believe lmap is an operational
framework and that its key functions need to be defined in operational
terms, and not in terms of their roles in active measurement tasks.

I find Juergen's proposed distinction between MA and MP (whether or not
they have a Controller interface) to be very workable. But this means
that an MA and an MP can potentially perform identical roles in an
active Measurement Task. The set of Measurement Methods that can be
implemented in an MA and MP are the same. The Information Model should
take into account that not all Measurement Tasks are scheduled -- some
may occur in reaction to external stimuli. It will need to be possible
for the Controller to enable/disable these.
Barbara

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Feb 2014 20:49:05 +0100

> This tells me that MP is a Responder.

I do not know the definition of initiate but I think some of the above
statements are wrong and hence the conclusion does not hold. In particular,
I believe an MA can initiate task for MA <-> MA test.

/js

---

From: KEN KO <[email-masked]>
Date: Fri, 14 Feb 2014 20:08:57 +0000

+1

> Sent: Friday, February 14, 2014 2:49 PM
> To: Sharam Hakimi
> Cc: STARK, BARBARA H; [email-masked]; MORTON JR., AL;
> [email-masked]; Bugenhagen, Michael K; KEN KO; Brian Trammell
> In particular, I
> believe an MA can initiate task for MA <-> MA test.
> 
> /js
> 
> --

---

From: "Sharam Hakimi" <[email-masked]>
Date: Fri, 14 Feb 2014 15:40:36 -0500

That would mean that an MA has a silent responder built inside it,
because without a responder function two senders cannot perform a test.

Sharam

-----Original Message-----
From: KEN KO [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 3:09 PM
To: Juergen Schoenwaelder; Sharam Hakimi
Cc: STARK, BARBARA H; [email-masked]; MORTON JR., AL;
[email-masked]; Bugenhagen, Michael K; Brian Trammell
Subject: RE: [lmap] MA vs MP

+1

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Feb 2014 21:50:38 +0100

> because without a responder function two senders cannot perform a test.

You seem to assume that MA is a sender and an MP is a receiver, which
is not what the text says. Hence you draw wrong conclusions. And a
measurement between to MAs does not even require that there are any
responses at all. It is perfectly fine that one MA generates a traffic
train that is received by another MA. The LMAP framework tries to stay
generic. It is the concrete measurement tests you run that make the
difference.

/js

PS: If I do something as simple as sending ICMP echo requests, then
    pretty much every IP implementation has a built-in responder.
    Claiming this would not be the case would be kind of in conflict
    with how basic IP works.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 14 Feb 2014 15:51:10 -0500

No at all, you are assuming measurement functionality
along with the LMAP system functions.

There is nothing that prevents a device with an MA to
also be equipped to act as either a TWAMP sender or reflector.

Al

> Sent: Friday, February 14, 2014 3:41 PM
> To: KEN KO; Juergen Schoenwaelder
> Cc: STARK, BARBARA H; [email-masked]; MORTON, ALFRED C
> (AL); [email-masked]; Bugenhagen, Michael K; Brian Trammell

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 14 Feb 2014 20:58:29 +0000

+1
I also see nothing (other than the current terminology definitions of Active Measurement Method (Task), MA, and MP -- which I believe all need to be changed to reflect whatever we agree upon) that precludes:
MA (either one) "initiates" MA <-> MA test
MA2 "initiates" MA1 <-> MA2 test
MA "initiates" MA <-> MP test
MP "initiates" MA <-> MP test
MP (either one) "initiates" MP <-> MP test (not that anyone cares)
There needs to be nothing in the definitions of MA, MP, and Active Measurement Method (Task) that limits, restricts, or proscribes the "role" an MA or MP can play in Active Measurement Tasks an MA or MP participates in.
Most importantly, none of the actual requirements of the framework are impacted by not restricting the "roles".
Barbara

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Fri, 14 Feb 2014 21:24:18 +0000

OWAMP is an Agent function ..  It Just may not be a LMAP MA... 

   But if LMAP assumes to run agents under MA LMAP agents -  ... 

Tongue in cheek - confusing ?  

Sent from my iPhone

---

From: "Sharam Hakimi" <[email-masked]>
Date: Fri, 14 Feb 2014 16:49:23 -0500

Al,
My assumption is that the device only has an MA function. I agree that
it can have other functions, MP included, but if it only has an MA
function then in order for it to be able to respond, it would have to
have a silent responder built into its MA function.

Sharam

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 3:51 PM
To: Sharam Hakimi; KEN KO; Juergen Schoenwaelder
Cc: STARK, BARBARA H; [email-masked]; [email-masked];
Bugenhagen, Michael K; Brian Trammell
Subject: RE: [lmap] MA vs MP

Al

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Mon, 17 Feb 2014 15:06:03 +0000

Juergen - 

   Just to clarify- I don't the we've defined the actual scientific catoregizational differences

Specifically -

  The BBF MA - Rests above all other MA levels on that device and all the test and probe functions are controlled by it (with the exception of normal protocol interactions).
    It does this specifically so it knows how many tests are running at one time.

  I don't think the MA in LMAP assumes tracking all tests as stated above, and unless I miss understand it - the LMAP MA would do some type of resource check - but not track all tests..

Cheers,
Mike

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 2:51 PM
To: Sharam Hakimi
Cc: KEN KO; STARK, BARBARA H; Cook, Charles; MORTON JR., AL; [email-masked]; Bugenhagen, Michael K; Brian Trammell
Subject: Re: [lmap] MA vs MP

> because without a responder function two senders cannot perform a test.

You seem to assume that MA is a sender and an MP is a receiver, which is not what the text says. Hence you draw wrong conclusions. And a measurement between to MAs does not even require that there are any responses at all. It is perfectly fine that one MA generates a traffic train that is received by another MA. The LMAP framework tries to stay generic. It is the concrete measurement tests you run that make the difference.

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 17 Feb 2014 15:18:19 +0000

>   The BBF MA - Rests above all other MA levels on that device and all the test
> and probe functions are controlled by it (with the exception of normal
> protocol interactions).

I disagree with this characterization of the BBF MA. There is no such assumption in BBF. then  
Barbara

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Mon, 17 Feb 2014 15:53:48 +0000

It's part of the "test admission schema" -

  Operationally multiple probes that don't know about each other and can use resources don't work.

So if we want to put multiple probes (which would also require multiple management ports) on a single device both projects will have to add a "CPU / Resource" utilization cross hold monitoring during testing...

At the moment both documents suggestion a "pre-test" resource Check - if you have a collision space that two probes can test, and then collide we have another problem.

So I would say again - the 304 approach has one resource check without other probes using resources as peer who can break that schema.

So I'll have to go back and check our text, but I think the statement is true.  

I definitely believe this "one probe" view is definitely an ISP op's requirement - they've been fighting the Video probe, VoIP probe, Broadband Probe thing for multiple years... 

So I'm going to stick with one probe view is a delta... 

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Monday, February 17, 2014 9:18 AM
To: Bugenhagen, Michael K; 'Juergen Schoenwaelder'; 'Sharam Hakimi'
Cc: 'KEN KO'; Cook, Charles; MORTON JR., AL; [email-masked]'; 'Brian Trammell'
Subject: RE: [lmap] MA vs MP

>   The BBF MA - Rests above all other MA levels on that device and all 
> the test and probe functions are controlled by it (with the exception 
> of normal protocol interactions).

I disagree with this characterization of the BBF MA. There is no such assumption in BBF. then Barbara

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Mon, 17 Feb 2014 15:58:23 +0000

Do you guys think there is any chance of having a Joint meeting with whiteboards to knock these out ???

BBF is in Denver in June / July I think ...

Mike

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 17 Feb 2014 19:46:07 +0000

> So if we want to put multiple probes (which would also require multiple
> management ports) on a single device both projects will have to add a "CPU /
> Resource" utilization cross hold monitoring during testing...

Assuming that by Probe you mean MA or MP (I would prefer to use "official" terminology)...
An MA (under BBF or LMAP) cannot be assumed to have knowledge of any other functionality that may reside on a physical device. For an MA to know what's going on before and during a Measurement Task, it would need to access the underlying OS to determine network interface, memory, and processor utilization. In general, OSs provide APIs that give access to this info.

How an MA is designed to react in the event of certain network interface, memory, and processor utilization will be something I would not expect BBF or LMAP to try to mandate. It will vary based on the measurement method, the percentage of utilization, the purpose of the measurement (regulatory, just for the service provider, just for the end user, etc.), and other factors. For example, if the task is to do a ping and the utilization of all 3 (network interface, memory, processor) is around 10%, then there's no need to stop the ping test. If the task is a bandwidth test of some sort, and memory/processor is relatively low and network interface utilization is < 1% (as a percentage of measured bandwidth, perhaps), then this may be good enough for an end user to be satisfied with the result, but maybe it's not good enough for a regulator. Maybe for a regulator you'd want < 0.1% network interface utilization. I suspect 0% would be unrealistic. On the other hand, perhaps > 1% network interface utilization indicates the user is doing something and bandwidth measuring should be immediately halted. Less intensive measurement tasks may proceed. VoIP tests that only require around 100kbps could easily proceed on a 10Mbps down / 1Mbps up connection with 10% utilization. But not on a 256 kbps down / 128 kbps up connection with 10% utilization.

Note that whether the cause of this "other" utilization is another MA or some other function is completely irrelevant. An MA does not need to know the cause of utilization or be able to interact with or control that cause in order to know about and react appropriately (per whatever design) to utilization.

<snip>
> So I would say again - the 304 approach has one resource check without
> other probes using resources as peer who can break that schema.

[For IETFers, 304 = BBF WT-304 draft on performance measurements.]
Huh?

<snip>
> I definitely believe this "one probe" view is definitely an ISP op's
> requirement - they've been fighting the Video probe, VoIP probe,
> Broadband Probe thing for multiple years...
> 

If you are in control of the device as a whole (e.g., it's your network element or your STB or your RG or your whitebox or dedicated measurement box), and you are able to design the MA within it, then do so. Design it the way you want. I completely agree that putting multiple MAs on a device under your control that you can design is a really inefficient and complex thing to make work well. If bashing your head against the wall hurts, don't do it.

If you are a 3rd party designing an MA to run on a PC or smartphone (as an app), then you need to accept that you have no control over whatever else is running on that platform. Design the MA appropriately. 

LMAP and BBF allow for both of these models. Because neither tries to dictate the underlying platform. There is no difference between the 2 views of MA in this regard.

What BBF does have in its draft are requirements for service parameters and test environment parameters that get reported with various test result data. It *may* also have guidance (suggestions) regarding when not to do certain tests, and how to interpret results together with the service and test environment parameters (if someone decides to write such guidance). The existence of such requirements or guidance does not make a BBF MA some sort of super MA that rules over all other MAs.  
Barbara