Subject: Re: [ippm] A One-way Active Measurement Protocol Requirements draft

From: Victor Reijs <[email-masked]>
Date: Thu, 09 Aug 2001 11:58:38 +0100

Hello all of you,

A good initiative and could map quiet well on the ideas we have within
TF-NGN (see attached draft paper).

Some of my initial comments to the draft RFC:
General:
I see in the text 'OWDP' (like end section 3 and the file name), while
the title of the document is One-way Active Measurement Protocol, so why
not use 'OWAMP' (as in section 2)?

section 2
"With growing availability of good time sources to network nodes, it
   becomes increasingly possible to measure one-way IP performance
   metrics with high precision."
Why is it a one-way protocol? And why not active and passive? 
I think we need a protocol for any measurement to be done in a network,
so I would not restrict it to one-way and active. I would like to see at
leats a try to make a uniform measurement protocol. 
We can of course focus implementations on one-way measurements, but we
need to be open to others ones (active and passive). So lets call it MP:
Measurement Protocol instead of OWAMP.

Section 3
"With the increasingly wide availability of affordable global
   positioning system (GPS) and CDMA based time sources, hosts
   increasingly have available to them very accurate time
   sources--either directly or through their proximity to NTP primary
   (stratum 1) time servers. "
I don't think this is the driving force behind MP. For one possible
measurement (OWD) this could indeed be handy, but I would think that
this is an attribute of the protocol (MP-Control?) to find out if 'time'
can be measured in absolute terms on the systems in measurement.
So I would remove this from this section, but get it in section 4.5
(determine the capabilities of the systems).

Section 4
"Non-singleton characteristics (such as those related to trains of
   packets, back-to-back tuples, and so forth)"
But what about the loss pattern? The results here are not a singleton,
is it? In general, I think non-singletons should be allowed in this
protocol. Or is there a reason why this is not possible?
I think that section 4.1 also needs the possibility of transporting
non-singleton info. (or do I misunderstand the word?)

" and application traffic
   simulation aren't areas that the protocol(s) need to address."
I my view the MP should also be able to do this (perhaps we don't
concentrate on this, but never the less). I see two processes important
here:
. the measurement methodology code (MP-Code???)
. the measurement itself (OWAMP-Test/MP-Test)

It would be nice that measurement methodology code (so the real code of
the test done) could be downloaded to the measurement points and used
within the measurement (perhaps a few standard one are available like
OWD, RTT, OWPL, etc.). 
So in some way I see e.g. an OWD measurement almost as an application
traffic simulation.

Section 4.1
"by endpoint"
I am glad the term 'endpoint' is introduced, but I think it is needed in
some section on the proposed architecture of the system (perhaps just
infront of section 4.1).

Section 4.3
"These protocols are further referred to as OWDP-Test and
   OWDP-Control, respectively."
I think we need another protocol for downloading code to the endpoints:
MP-Code (and also be part of MP-Control).

Section 4.4
"Since the protocol needs to be able to measure individual packet
      delivery time and has to run on various machines, it needs to
      support UDP as transport protocol."
What is the relation between 'various machines' and 'UDP'? Are this not
two separate characteristics?

Section 4.5
"schedule zero or more OWDP-Test sessions (which do not have to be
      between the peers of OWDP-Control conversation);"
Part of this (or perhaps part of MP-Test) is that resource control of
the measurement system is evaluated/monitored/reported a) before the
test is done (perhaps re-schedule test) and b) during the test.

Hope this are useful comments.

All the best,

Victor

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Fri, 10 Aug 2001 10:51:44 +0200 (CEST)

Hi all,

I finally had time to read this in detail.  Basically, I like the draft,
it reflects what we want, most of my comments are minor, and we should
(IMHO) try to push this ahead so we can continue with the OWDP draft. So:

Title: The title says "1 way active measurements protocol". However, there
is already a RFC on 2-way delays and I don't see why the control part
cannot be used to set up measurement sessions for round trip measurements
that require action on the destination side. So, I propose to drop the
1-way from the title.

Section 2: The abstract introduces the term OWAMP but this is about the
only time that I see that mnemonic being used.  The rest of the text uses
OWDP or just protocol.  This has to be cleaned up everywhere.

Section 3, 1st paragraph: I think we should explicitly state that this
draft is aimed at defining a protocol that allows users to do measurements
using devices from different vendors at both ends and get meaningful
results.  This is what is new in this document. There are already various
studies showing that devices from various implementors give the same
results when measuring the same path.  From this, it follows that I can
use device A to measure from X to Y, and device B to measure from X to Z
and compare the results.  This can be considered interoperability as well,
but it is not what we are after.

Section 3, 2nd paragraph: "very accurate" doesn't say much without a
reference.  I suggest to replace "very accurate time sources" by "time
sources that allow hosts to time-stamp packets with accuracies smaller
than the delays seen on the Internet".

Section 3, 2nd paragraph: Add that not all measurements that can be
controlled by this protocol need time-stamps (loss, connectivity) or
synchronization to a global time standard (roundtrip).

Section 4, 1st paragraph:  I think that a requirement should be that the
standards defined in the framework document (RFC2330) should be followed
and implemented.

Section 4, 1st paragraph: even though nobody has implemented it, shouldn't
this protocol also be able to deal with the connectivity or round trip
metrics, as well as other metrics that we might invent in the future?

Section 4, 2nd paragraph: at the moment, we have the basic metrics (delay,
loss) and derived metrics (jitter, percentiles over distribution).  The
derived metrics can always be calculated later, off-line.  However, it
appears to me that you want to include the possibility that OWAMP can set
up sessions where the only result is a derived metric.  Is this what
you/we want?

Section 4, 3rd paragraph: but then why should the protocol exclude the
possibility to do packet trains?  

Section 4.1: "by endpoint" should be "by the endpoint" (and has endpoint
been defined somewhere?).

Section 4.1: Depending on implementation details, a minimum amount of
post-processing will often be necessary, so I suggest to change the first
sentence ("To facilitate... post-processing") into

  To facilitate the broadest possible use of the obtained measurement
  results, all post-processing required by the implementation, should
  be carried out automatically before the results are made available.

Section 4.2: The second paragraph is a special case of the first
paragraph: if I can distribute the results anywhere, I can also distribute
them to their final destination.

Section 4.3: Since we can control different measurements with
OWAMP-control, do we allow for more OWAMP-test protocols or do we define
one OWAMP protocol that can be tuned of the specific measurement.  In both
cases, this should be stated in 4.3.

Section 4.4: Additional requirements:
 + Packets should contain all quantities specified in the relevant RFC's, 
   or needed to calculate these quantities.
 + Data to calculate experimental errors on the final
   result should be included in the packets.
 + Time stamps should be expressed using RFC1305 (the NTP standard), to
   allow for easier further processing of the results.

Section 4.4: Advance warning: there will be a paper at the November ACM
workshop on measurments proposing a completely different (but quite sensible)
 approach to OWD-test.

Section 4.5: I don't see the need for setting up 0 session.

Section 4.5: Additional requirement:
 + The protocol should be able to cope with common problems in a large
   measurement environment without human interference.  (Machines going
   down, broken cables, etc).

Section 4.5: Why should OWAMP-control be able to retrieve results, 4.2
   pushes this to another domain.

Section 5. State that which measurements will be done is up to a human to
   decide and thus not an issue

Section 6: Swap 6.5 and 6.4: 6.5 explains time-stamp encryption used in
6.4

Section 6.1: "Hard to detect" doesn't cover it, I don't see a problem with
people detecting that things are being measured, the problem starts when
they attempt to modify the packet.  The requirement should be called "Hard
to interfere with the measurement".

Section: 6.1, 6.2 optional for measurements inside an organization

Section 6.3: Shouldn't we just pick a method?  They probably all have
their pros and cons.  

----

Final comment: I'll give this draft to one of our security guys, ask him 
to have a look at section 6 and report back to the list if necessary.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: [email-masked]
RIPE Network Coordination Centre     WWW: http://www.ripe.net/home/henk
Singel 258                         Phone: +31.20.5354414
1016 AB Amsterdam                    Fax: +31.20.5354445 
The Netherlands                   Mobile: +31.6.55861746  
------------------------------------------------------------------------------

As long as you don't tell your friends how I played the hand,
then I won't tell my friends how you defended it.                 (Anonymous)

_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: stanislav shalunov <[email-masked]>
Date: 10 Aug 2001 18:14:36 -0400

> not use 'OWAMP' (as in section 2)?

Late name change, sorry about the confusion.  Will correct.

> Why is it a one-way protocol? And why not active and passive? 

I think passive measurements are way outside of scope of the activity
here.  (Not to imply that they're less valuable.)  I see little scope
for interoperable remote passive measurements.  I wouldn't be the one
to write security considerations section for that.  "Could you show me
the first data packet of each POP session on your network?" :-)

> can be measured in absolute terms on the systems in measurement.

(Relatively) accurate timestamps are required for more than delay
measurements.  For example, loss metrics are defined in a way that
requires specifying the time when each loss event occurs.

> But what about the loss pattern?

Since you get the raw measurement data, you can analyze the loss
patterns to a certain extent...

> In general, I think non-singletons should be allowed in this protocol.

Sure.  But should they be made a requirement?

> concentrate on this, but never the less).

That's a big can of worms.  Placing it in the requirements document
seems to be a good way to never arrive even at a more modest protocol
that'll measure standard metrics.

> some section on the proposed architecture of the system (perhaps just

Will address.

> MP-Code (and also be part of MP-Control).

What do you mean by "code"?  As in, "source code" or "executable
code"?  Or do you mean something else?

> two separate characteristics?

UDP is the only things that'll let you easily do measurements with
arbitrary machines.

> test is done (perhaps re-schedule test) and b) during the test.

I don't understand.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Democracy is a form of government that substitutes election by the incompetent
many for appointment by the corrupt few.                         -- G. B. Shaw
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: stanislav shalunov <[email-masked]>
Date: 10 Aug 2001 19:59:59 -0400

"Henk Uijterwaal (RIPE-NCC)" <[email-masked]> writes:

> (IMHO) try to push this ahead so we can continue with the OWDP
> draft.

Thanks!

> Title: The title says "1 way active measurements protocol". However,
> there is already a RFC on 2-way delays and I don't see why the
> control part cannot be used to set up measurement sessions for round
> trip measurements that require action on the destination side. So, I
> propose to drop the 1-way from the title.

It seems that the 'net already has a widely implemented (in kernel
space!) way to measure round-trip characteristics.  However, if so
desired, having a protocol that'll measure one-way characteristics
will give one ability to measure two-way characteristics as well,
wouldn't it?  Having "one-way" in the title appear to me to underscore
an increase of functionality over Echo Request.  Is it not so?

> OWDP or just protocol.  This has to be cleaned up everywhere.

Thanks.  Replaced 21 occurrences of OWDP with OWAMP.

> Section 3, 1st paragraph: I think we should explicitly state that
> this draft is aimed at defining a protocol that allows users to do
> measurements using devices from different vendors at both ends and
> get meaningful results.

Thanks, I'll steal that almost verbatim:

	This requirements document is aimed at defining a protocol
	that allows users to do measurements using devices from
	different vendors at both ends and get meaningful results.

> than the delays seen on the Internet".

Thanks.  Replaced with
	time sources that allow hosts to time-stamp packets with accuracies
	substantially better than the delays seen on the Internet

> synchronization to a global time standard (roundtrip).

But loss and connectivity (well, that's not yet defined) do need to be
accurately tied to particular times.

Here's what I added:

	Even without very accurate timestamps one can measure
	characteristics such as, e.g., loss with acceptable for many
	practical purposes quality.

> standards defined in the framework document (RFC2330) should be followed

I don't quite understand this.  RFC2330 provides a framework for
defining metrics.  OWAMP itself defines no metrics and simply provides
a common protocol for collection of data suitable for computation of
metrics that are defined in RFC2330 framework (as well as, possibly,
other metrics--at data consumer's option).  It's stated that it should
be possible to measure particular metrics defined in RFC2330 framework
(RFC2679 and RFC2680), non-exclusively.

Can you clarify this point?

> Section 4, 1st paragraph: even though nobody has implemented it,
> shouldn't this protocol also be able to deal with the connectivity
> or round trip metrics, as well as other metrics that we might invent
> in the future?

The second paragraph of same section currently includes:

	It should be possible to measure arbitrary one-way singleton
	characteristics (e.g., loss, median delay, mean delay, jitter, 90th
	percentile of delay, etc.).

Further specification of this requirement (the requirement to make raw
measurement results rather than cooked values available) attempts to
generalize the protocol and widen its area of applicability further.

I believe that we should concentrate on defining primitives that'll
allow measurement of other, potentially more complex, metrics, rather
than attempt to cover the full range of possible metrics of our
primitives per se.

> Section 4, 2nd paragraph: at the moment, we have the basic metrics
> (delay, loss) and derived metrics (jitter, percentiles over
> distribution).  The derived metrics can always be calculated later,
> off-line.  However, it appears to me that you want to include the
> possibility that OWAMP can set up sessions where the only result is
> a derived metric.  Is this what you/we want?

Actually, we want exactly the opposite: the protocol should just give
the raw data (sequence of received packets with send/receive
timestamps) and leave it up to the data user to decide how to use it.

> possibility to do packet trains?  

I don't want to exclude them.

There are two different issues here:

* Session scheduling (e.g., asking for packet trains or whatever else
  to be sent);

* Session results retrieval (e.g., getting the spacing of your packet
  train after it was delivered).

Having the latter is easy in its most general case.  (Just give all
the data.)  Having the former is a more complex proposition in a
general case.  I'd very much like to have it even though it would not
measure any currently defined metric (and there were many requests for
similar capabilities on the list).  However, given the lack of
understanding of the method of doing this, I'd like to not make it a
strict requirement.

To make this more clear, I've included the following in the very end
of the section:

	(However, they can be addressed if considered practical and
	not contradicting other design goals.)

> been defined somewhere?).

Replaced "endpoint" with "the data consumer".  I guess it expresses
what we want better.

>   be carried out automatically before the results are made available.

But one needs to be able to interpret the results in a universally
meaningful fashion.  What this requirement tries to exclude is a
situation when you conduct a measurement session to a remote host and
all the remote host tells you about the results is a fixed set of
metrics (e.g., "loss was .56%, mean delay was 45ms, jitter was 15ms")
and you're left without the data that you could use to extract, say,
95th percentile of delay.

Do you agree with the goal?

If so, is there a better way to say this than currently in the draft?

> paragraph: if I can distribute the results anywhere, I can also
> distribute them to their final destination.

There's the word "directly" there that makes it not a special case.  A
protocol that makes you always send data back to whoever originated
OWAMP-Control session once the OWAMP-Test session is complete doesn't
prevent you from getting the data to your central database--but only
with an additional transfer.

> OWAMP-control, do we allow for more OWAMP-test protocols or do we
> define one OWAMP protocol that can be tuned of the specific
> measurement.  In both cases, this should be stated in 4.3.

I wanted to say the latter.

Changed first paragraph to:

	Since measurement session setup and the actual measurement
	session (i) are different tasks; (ii) require different levels
	of functionality, flexibility, and implementation effort;
	(iii) may need to run over different transport protocols,
	there should exist a protocol for conducting the actual
	measurement session on one side and a protocol for session
	setup/teardown/confirmation/retrieval on the other.  These
	protocols are further referred to as OWAMP-Test and
	OWAMP-Control, respectively.

Does this sound good?

>    or needed to calculate these quantities.

I don't understand this.  What quantities?  In what RFCs?  It's
possible that when the measurement session is conducted neither the
client nor the server know what metric(s) would be computed from the
raw data.  What RFCs are relevant?  Even if they somehow knew that,
e.g., only jitter would be computed later at a central processing
site, surely *all* quantities from jitter definition RFC would be
excessive (and some would be unknown at the time of the test).

>    result should be included in the packets.

Included.

>    allow for easier further processing of the results.

We haven't received any input from the community of hardware
measurement node vendors.  It'd be nice to know more about what's good
for them.

Additionally, the following requirement

+	It should be possible to make packets generated by OWAMP-Test
	as small as possible, to be able to accurately measure paths
	where packet-splitting technologies such as ATM are used.

can be conflicting with others.  The exact timestamp format seems to
be a relatively minor protocol design detail; I'd propose to leave it
to OWAMP discussion itself.

> Section 4.4: Advance warning: there will be a paper at the November
> ACM workshop on measurments proposing a completely different (but
> quite sensible) approach to OWD-test.

Naturally, there can be a number of different approaches, many of them
being equally valid, and some providing properties that others don't
provide and vice versa.

> Section 4.5: I don't see the need for setting up 0 session.

If you just want to retrieve the results of a OWAMP-Test session in
your current OWAMP-Control session, you don't need to set up any more
OWAMP-Test sessions.

>    down, broken cables, etc).

I was trying to be more specific in the requirements.  For example,
``[OWAMP-Control] should provide peers with the ability to always
distinguish between network and peer failures'' attempts to address
one aspect of this problem while ``confirm graceful completion of
session or abort them prematurely (for both sides)'' attempts to
address another.

Could you please be more specific?

>    pushes this to another domain.

I don't think I understand.  We want to have interoperable retrieval
mechanism.  It could be made into a (yet-third) protocol, but there
seems to be no advantage to doing so.  Do you agree with the goal?

If so, what can we change to say it more clearly?

>    decide and thus not an issue

Added paragraph:

	It is the protocol user's responsibility to decide how to use
	the protocol and which measurements to conduct.

> Section 6: Swap 6.5 and 6.4: 6.5 explains time-stamp encryption used in

Moved "Modes of Operation" to the top of "Security Considerations"
section.

> Section 6.1: "Hard to detect" doesn't cover it, I don't see a
> problem with people detecting that things are being measured, the
> problem starts when they attempt to modify the packet.  The
> requirement should be called "Hard to interfere with the
> measurement".

So, if all measurement traffic by design was between UDP ports 6743,
you'd not have a problem?  I see it as a problem: it makes it
trivially easy for an ISP to put just the measurement traffic into the
priority queue (threat that's more real than anything requiring packet
modification).

> Section: 6.1, 6.2 optional for measurements inside an organization

``Should make it possible to run,'' ``should be possible to make it
infeasible'' and ``should be possible to authenticate'' seem already
optional to me--within an organization or anywhere else.

> Section 6.3: Shouldn't we just pick a method?  They probably all have

Picking a method would involve actually describing it.  That level of
detail doesn't look like a requirement to me--it's already protocol
specification, isn't it?

> Final comment: I'll give this draft to one of our security guys, ask
> him to have a look at section 6 and report back to the list if
> necessary.

This would be very much appreciated.  If they don't find it necessary
to report to the list, you might still wish to report that they found
nothing to correct.

"The power of accurate observation is commonly called cynicism by
those who have not got it."			-- G. B. Shaw
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Mon, 13 Aug 2001 13:29:28 +0200 (CEST)

Stas,

I've removed everything I agree with.

> an increase of functionality over Echo Request.  Is it not so?

No, not to me.  1-way refers to direction of the measurements, not the
extra functionality.  The title, IMHO, should stress that this is a
protocol to control active measurements with equipment at both ends that
has to be controlled.

> Can you clarify this point?

I'm mainly looking at the smaller things such as how to report results,
time stamps, how to do sampling, etc.  2330 sets standards for those and I
think we should state that we will follow those standards whenever
applicable.

It also makes the collection of RFC's a bit more logical: 2330 provides
the framework, 26xx implement specific metrics, OWAMP the control of
measuring the metrics.  

> than attempt to cover the full range of possible metrics of our

This is not what I meant, I simply wanted to add that the list 2679 and
2680 can be extended with other metrics.

> timestamps) and leave it up to the data user to decide how to use it.

In that case, we should remove the derived metrics from the list in this
paragraph.

> If so, is there a better way to say this than currently in the draft?

Yes, I agree with the goal and I think the second sentence covers that. I
was thinking more about post-processing work like appling calibration
constants or such.  (For example, the device measures time-stamps in
clockticks midnight, before reporting, one wants to convert these into UTC
times).  This should be done automatically.

> with an additional transfer.

OK.

> excessive (and some would be unknown at the time of the test).

This was a bit too brief.  Basically, I want to say that a OWAMP-test
packet should contain everything to calculate the metric, without the need
to access any other sources.

For example: the accuracy of the time-stamps of the source should be in
the packet, I don't want to set up a second channel of communication with
the source to get that.

> Could you please be more specific?

Basically what (I think) we want is that OWAMP-control will be able to
automatically recover anytime something unexpected happens.
Thinking about the correct words.

> seems to be no advantage to doing so.  Do you agree with the goal?

Yes.  Now that I have thought about this a bit more, I agree, leave the
text as is.

> priority queue (threat that's more real than anything requiring packet

I agree with that. I don't have a problem though if people see that we are
measuring throught their networks without the possibility to interfere
with the measurements.

It is mainly a wording issue: the requirement is (IMHO) that it should be
hard to interfere with the measurements, so that should be the title of
the paragraph.  

> detail doesn't look like a requirement to me--it's already protocol

No, I just want to state that we are going to select what we believe is
the best one based on discussion in the implementation phase, and not make
it optional and end up with N different methods.

Henk

---

From: Victor Reijs <[email-masked]>
Date: Thu, 30 Aug 2001 14:47:49 +0100

Hello Stas,

I am back in business...

stanislav shalunov wrote:

> > Why is it a one-way protocol? 

I agree fully with Henks remarks here. I think we need to make an open
protocol and this should include e.g. the future pings or other two way
measurements. I don't understand why the measurment protocol will change
much, because of this demand.

> And why not active and passive?
> 

Passive measruement are most of the time easier to ask for than active
measurements with some network managers! 
Active measurements load the network, CPU, disks, while passive
(possible;-) don't. So the security issues with active measurements
(like resource control) are much more important than for passive
measurements. 
For passive measurement, I can understand that network managers don't
want to disclose some information, but for that we also have security
control inplace (can be precisely the same one as for resource security
mentioned in 6, I would say).

So I see no intrinsic differances between active and passive measurement
looking at the measurement protocol and the security side.

> requires specifying the time when each loss event occurs.

Understand, so it is not mandaroty for doing measurements. Still an
attribute for the protocol, I would say.

> Sure.  But should they be made a requirement?

What is a singleton? Is e.g. 'raw measurment data' a non-singleton? And
the result for a OWD measurement a singleton (one figure). Again,
perhaps I don't understand the word singleton.

> that'll measure standard metrics.

I see even e.g. testing OWD or packet loss as an application! So I don't
think the can of worms is that big (you already have it;-). 
The main advantage of seeing it as an 'application', is that you have to
build in the protocol a method of downloading the
application/measurement. But I think you always need to do this; I don't
think that a protocol that does not have this download function in it,
will survive a fast increasing number of tests and their upgrades. So
upgrading could help keep this measurement infrastructure manageable.
I know there are some worms, but lets tackle them!

> code"?  Or do you mean something else?

Good point! That is part of this can of worms (isn't it). Say a code
that can be understood by any endpoint (irregardless which operating
system), something like Java?
Java is not that lightweight, I understand, so perhaps we need to make
it optional...
Perhaps scripting if possible (like done by Chariot of NetIQ, is not
fully what I want though...).

(although I don't like the optional part, because then it will not be
implemented and will result in a measurement infrastructure which will
not be managable).

> UDP is the only things that'll let you easily do measurements with

And if you want to do e.g. BTC measurements? I have no problem that the
MP-Control protocol also has this as an attribute (so that you can find
out which protocols are supported).

> > test is done (perhaps re-schedule test) and b) during the test.

Active measurements will load your resource (disk, CPU, link, etc.), so
you will have to be able to manage this (certainly as the network
manager that has granted access to others to do these tests). So you
need to do resource control before doing the test (estimates) and when
actually doing the test (and you have to report back on the load of
these resource towards the test initiator).
Passive measurements don't have this problem at this level, but still
yuu want to control there e.g. the disk load).

Hope this makes it more clearer.

All the best,

Victor

---

From: Victor Reijs <[email-masked]>
Date: Thu, 30 Aug 2001 15:02:37 +0100

Hello Stas,

> timestamps) and leave it up to the data user to decide how to use it.

Indeed a very good decision (and the raw data can be a lot of data or a
sigle byte of data).

> Do you agree with the goal?

Both are nice I would say, but is that nor part of the measurement
'code' (instead of the measurement protocol)?

> provide and vice versa.> 

So we indeed need to be able to download a new 'test protocol' (or as I
call it: test 'application').

All the best,

Victor