Subject: [lmap] measurement agent terminology in draft-eardley-lmap-terminology-00.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Apr 2013 21:14:59 +0200

Hi,

I have an issue with the terms Measurement Agent, Remote Measurement
Agent and Complete Measurement Agents as defined in the I-D. I do not
really see why we need all three and I am concerned that we make the
most frequently needed term the most complex to write and spell out.

My understanding is that LMAP defines Control Protocol and a Report
Protocol between a Controller / Collector and - well the rather ugly
term "Complete Measurement Agent". Note that these specifications will
have to talk a lot about this entity - which has the weirdest and
longest name.

Furthermore, I see little value of the term Measurement Agent because
the Remote Measurement Agents and the Complete Measurement Agents
really do very different things from an LMAP protocol perspective (The
Remote Measurement Agent does not nothing, the Complete Measurement
Agent does all.) I also think the current definition of Measurement
Agent is likely misleading - instead of 'performs' one should perhaps
use 'is involved in'. (If I throw a packet at a DNS server of an HTTP
server, I consider this server to be involved in the test, not to
perform this test.)

Bottom line is that I think we simplify the terminology a lot if we
remove the current definition of a Measurement Agent, a Complete
Measurement Agent, and Remote Measurement Agent and instead use this:

  Measurement Agent: A function that receives Instructions from a
  Controller, performs Measurement Tasks and reports Measurement Results
  to a Collector.

  Measurement Peer: A function that receives control messages and test
  packets from a Measurement Agent and may reply to the Measurement
  Agent as defined by the Measurement Method.

Well, Measurement Peer is a new invention and not necessarily the best
term one could come up with. In other contexts, this has been called a
measurement server (I tried to avoid 'server'). The key of this note,
however, is to just have to two simple to understand and use terms and
to avoid a generalization that I do not see useful for writing specs.

/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: Tue, 16 Apr 2013 09:12:18 +1200

Hi, Juergen, all.

+1. Comments inline.

> server, I consider this server to be involved in the test, not to

Agree completely.

LMAP sits between the Controller and the <thing which does measurement>. How that <thing> does measurement is _only_ in scope to the extent that a Controller has to know about it in order to coordinate its actions. I can't think of any arrangement of such components requiring the Controller to manage distributed parts of a <thing> that is less complicated and more robust than one in which the Controller has a single part of the <thing> to which it delegates the distributed arrangement. 

(There may be complexities of measurement device _management_ -- upgrading software, collecting load stats and other metadata, and so on -- that might be simplified by a Controller knowing about every subcomponent, but this is also questionably in scope.)

> to avoid a generalization that I do not see useful for writing specs.

Yep. As far as I'm concerned we could blend the two into one, to further underscore the fact that we _really don't care_ how a Measurement Agent performs the measurements it does:

    Measurement Agent: A function that receives Instructions from a
    Controller, performs Measurement Tasks and reports Measurement Results
    to a Collector; perhaps in concert with other components distributed
    throughout the observed network, which it itself controls.

Best regards,

Brian

---

From: "MORTON JR., ALFRED C (AL)" <[email-masked]>
Date: Tue, 16 Apr 2013 09:28:04 -0400

Brian wrote:
> 
> Yep. As far as I'm concerned we could blend the two into one, to further
> underscore the fact that we _really don't care_ how a Measurement Agent
> performs the measurements it does:
> 

This single name is closer to what I was thinking "terminologically" last October.
There will be cases (I believe) where one MA is Instructed to perform
some measurements, but is simply a measurement peer for other measurement sessions.

After initialization and instruction, different MAs can be distinguished by the
named roles of the measurement protocol they use to execute the instructions.
Some MAs may only be initialized, then sit and wait to be contacted by other MAs.

A small tweak at the end:
     Measurement Agent: A function that receives Instructions from a
     Controller, performs Measurement Tasks and reports Measurement Results
     to a Collector; perhaps in concert with other components distributed
     throughout the observed network, with which it coordinates as needed.

(either MA can reject a test session, following the CAC discussion yesterday)

Al

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian Trammell
> Sent: Monday, April 15, 2013 5:12 PM
> To: Juergen Schoenwaelder
> Cc: [email-masked]
> Subject: Re: [lmap] measurement agent terminology in draft-eardley-lmap-
> terminology-00.txt
> 
> Hi, Juergen, all.
> 
> +1. Comments inline.
> 
> LMAP sits between the Controller and the <thing which does measurement>.
> How that <thing> does measurement is _only_ in scope to the extent that a
> Controller has to know about it in order to coordinate its actions. I
> can't think of any arrangement of such components requiring the Controller
> to manage distributed parts of a <thing> that is less complicated and more
> robust than one in which the Controller has a single part of the <thing>
> to which it delegates the distributed arrangement.
> 
> (There may be complexities of measurement device _management_ -- upgrading
> software, collecting load stats and other metadata, and so on -- that
> might be simplified by a Controller knowing about every subcomponent, but
> this is also questionably in scope.)
> 
> 
> Yep. As far as I'm concerned we could blend the two into one, to further
> underscore the fact that we _really don't care_ how a Measurement Agent
> performs the measurements it does:
> 
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: <[email-masked]>
Date: Wed, 17 Apr 2013 12:08:15 +0100

I much prefer Juergen's suggestion of Measurement Agent and Measurement Peer. Thanks!

two suggestions:

1. think worth the definitions saying, "Colloquially, a Measurement Agent (/Peer) is a physical device that performs this function."

2. 
>      throughout the observed network, with which it coordinates as
After the ; could we simply have
"perhaps in concert with a Measurement Peer"
Or do you have something else in mind?

phil

> MORTON JR., ALFRED C (AL)
> Sent: 16 April 2013 14:28
> To: Brian Trammell; Juergen Schoenwaelder
> Cc: [email-masked]
> Subject: Re: [lmap] measurement agent terminology in draft-eardley-
> lmap-terminology-00.txt
> 
> Juergen wrote:
> > > Controller, performs Measurement Tasks and reports Measurement
> > > Results  to a Collector.
> > >
> > >  Measurement Peer: A function that receives control messages and
> > > test  packets from a Measurement Agent and may reply to the
> > > Measurement  Agent as defined by the Measurement Method.
> > >
> > > Well, Measurement Peer is a new invention and not necessarily the
> > > best term one could come up with. In other contexts, this has been
> > > called a measurement server (I tried to avoid 'server'). The key of
> > > this note, however, is to just have to two simple to understand and
> > > use terms and to avoid a generalization that I do not see useful
> for writing specs.
> 
> Brian wrote:
> >
> > Yep. As far as I'm concerned we could blend the two into one, to
> > further underscore the fact that we _really don't care_ how a
> > Measurement Agent performs the measurements it does:
> >
> After initialization and instruction, different MAs can be
> distinguished by the named roles of the measurement protocol they use
> to execute the instructions.
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Brian Trammell
> > Subject: Re: [lmap] measurement agent terminology in
> > draft-eardley-lmap- terminology-00.txt
> >
> > Hi, Juergen, all.
> >
> > +1. Comments inline.
> >
> > On 16 Apr 2013, at 7:14, Juergen Schoenwaelder
> > <j.schoenwaelder@jacobs- university.de> wrote:
> >
> > > Hi,
> > >
> > > Agent and Complete Measurement Agents as defined in the I-D. I do
> > > not really see why we need all three and I am concerned that we
> make
> > > the most frequently needed term the most complex to write and spell
> out.
> > >
> > > term "Complete Measurement Agent". Note that these specifications
> > > will have to talk a lot about this entity - which has the weirdest
> > > and longest name.
> > >
> > > Furthermore, I see little value of the term Measurement Agent
> > > because the Remote Measurement Agents and the Complete Measurement
> > > Agents really do very different things from an LMAP protocol
> > > perspective (The Remote Measurement Agent does not nothing, the
> > > Complete Measurement Agent does all.) I also think the current
> > > definition of Measurement Agent is likely misleading - instead of
> > > 'performs' one should perhaps use 'is involved in'. (If I throw a
> > > packet at a DNS server of an HTTP server, I consider this server to
> > > be involved in the test, not to perform this test.)
> >
> > Agree completely.
> >
> > How that <thing> does measurement is _only_ in scope to the extent
> > that a Controller has to know about it in order to coordinate its
> > actions. I can't think of any arrangement of such components
> requiring
> > the Controller to manage distributed parts of a <thing> that is less
> > complicated and more robust than one in which the Controller has a
> > single part of the <thing> to which it delegates the distributed
> arrangement.
> >
> > (There may be complexities of measurement device _management_ --
> > upgrading software, collecting load stats and other metadata, and so
> > on -- that might be simplified by a Controller knowing about every
> > subcomponent, but this is also questionably in scope.)
> >
> >
> > > Controller, performs Measurement Tasks and reports Measurement
> > > Results  to a Collector.
> > >
> > >  Measurement Peer: A function that receives control messages and
> > > test  packets from a Measurement Agent and may reply to the
> > > Measurement  Agent as defined by the Measurement Method.
> > >
> > > Well, Measurement Peer is a new invention and not necessarily the
> > > best term one could come up with. In other contexts, this has been
> > > called a measurement server (I tried to avoid 'server'). The key of
> > > this note, however, is to just have to two simple to understand and
> > > use terms and to avoid a generalization that I do not see useful
> for writing specs.
> >
> > Yep. As far as I'm concerned we could blend the two into one, to
> > further underscore the fact that we _really don't care_ how a
> > Measurement Agent performs the measurements it does:
> >

---

From: "Sharam Hakimi" <[email-masked]>
Date: Wed, 17 Apr 2013 16:59:20 -0400

I am going to through a little monkey wrench in this. I am going to
suggest: 

Measurement TEST Agent      With the same definition as the Measurement
Agent below  and 

Measurement Response Agent      instead of Measurement Peer. Peering has
specific meanings and any Measurement Test Agent can choose any
Measurement Response agent to perform the required measurement.

Thanks,
Sharam 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, April 17, 2013 7:08 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: [lmap] measurement agentterminology in
draft-eardley-lmap-terminology-00.txt

I much prefer Juergen's suggestion of Measurement Agent and Measurement
Peer. Thanks!

two suggestions:

1. think worth the definitions saying, "Colloquially, a Measurement
Agent (/Peer) is a physical device that performs this function."

2. 
> Results

phil

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Results
> Results
> Results

---

From: "MORTON JR., ALFRED C (AL)" <[email-masked]>
Date: Wed, 17 Apr 2013 17:35:42 -0400

Thanks for your suggestion Sharam, but:
 
- we were trying to avoid using "test" at first, and now we're reserving it for a specific type of metric with binary outcome.

- the measurement "peer" might be controling certian aspects of the measurement according to
  the active measurement protocol in use, so it's better to keep names as generic as possible in the LMAP
  space and let the supporting protocols decide the roles.

anyway, there's my thoughts on the proposed names,
Al

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Sharam Hakimi [[email-masked]]
Sent: Wednesday, April 17, 2013 4:59 PM
To: [email-masked]; MORTON JR., ALFRED C (AL); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [lmap] measurement agentterminology        in      draft-eardley-lmap-terminology-00.txt

Thanks,
Sharam

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

two suggestions:

2.

phil

Of

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Apr 2013 07:47:24 +0200

> Measurement Response agent to perform the required measurement.

I do not see that Measurement Peer can be confused with Peering. The
noun peer is already heavily used in contexts that have nothing to do
with peering (e.g. Peer-to-Peer networks).

I also do not see that TEST adds anything relevant to Measurement
Agent.

/js

---

From: "Sharam Hakimi" <[email-masked]>
Date: Thu, 18 Apr 2013 09:11:20 -0400

The point would be that a Measurement Agent can comprise of a "Test"
and/or a "Response" Agent. As mentioned here before a responder is
called a server in many other areas.   

The TEST agent would be the test initiator and test data collector for
the specific measurement and the RESPONDER would be the equivalent of a
server.

This way there is no confusion as to who initiates the measurement and
who is the Responder for that measurement.

That was my thought.

Sharam  

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Thursday, April 18, 2013 1:47 AM
To: Sharam Hakimi
Cc: [email-masked]
Subject: Re: [lmap] measurement agentterminology in
draft-eardley-lmap-terminology-00.txt

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Apr 2013 16:31:52 +0200

> who is the Responder for that measurement.

But that assumption may not necessarily always true. The MA might
engage in other protocols with peer(s) such as OWAMP or TWAMP.  And 
by the very definition, the MA is the one that interacts with the
Controller and Collector, the MP does not.

/js