Subject: Re: [lmap] About draft-schulzrinne-lmap-requirements-00 - controller scheduling

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 5 Nov 2012 00:45:28 +0000

As a general comment which may color some of the perceptions: 

There are probably two kinds of measurement infrastructures: full-time ("professional") and occasional. ATLAS and the current FCC system are examples of full-time, i.e., the clients are measuring and gathering data all the time. However, as we scale up these systems and build them into every device (modem, mobile, ...), each individual box is going to do measurements only rarely: for example, it might get randomly "drafted" if it volunteered to be part of a broader measurement study, the user might suspect that something isn't working right or the ISP is debugging a particular end system. You need coordination for the full-time case, but for the occasional one, it's probably sufficient and much less complex for the client that gets asked by chance by a second controller to just say "sorry, I'm busy already".

Measurement coordination gets close to some of the GENI protocols and scheduler work, and might require much fancier algorithms, such as prioritization, calendar-like scheduling ("please let me use your nodes on Tuesday") and resource allocation ("Dear controller: I need 500 measurement nodes"). GENI is developing and deploying a number of generic experimental resource control protocols and interfaces (ORCA is one), and those may well be applicable for those cases.

May I also suggest that we start separate threads for new topics, to keep the messages focused?

Henning

________________________________________
From: [email-masked] [[email-masked]] on behalf of marcelo bagnulo braun [[email-masked]]
Sent: Tuesday, September 25, 2012 3:46 AM
To: [email-masked]
Subject: [lmap] About draft-schulzrinne-lmap-requirements-00

Hi,

Thanks for posting the draft and starting the discussion.

Some comments and questions.

About the Multi-provider network measurements support. In the draft you
mention that you want to support this, even though it is beyond the
scope of the document. I guess that the way the architecture is defined
will implicitly enable some forms of collaboration and made other forms
of collaboration harder. As per the protocols defined in the current
document, I understand you could support that Measurements clients
(M-clients for short) interacting with M-servers and M-controllers and
even Data collectors from different organizations. This would allow for
different organizations to schedule tests in the M-clients.
However, there is no protocol for the interaction between Data
collectors from different entities. I guess this would be abohter way to
enable interaction between different providers, where they coordiante
through the M-controller to M-controller protocol a set of tests to be
executed in different (disjoint) sets of clients and then the data
collectros exchange the results of the tests. I guess you could achieve
the same thing by allowing the M-clients to report to multiple data
collectors, but i would assume you want to minimize the traffic sent by
the M-clients.
This would allow for a sort of federation of multiple measurement
platforms, that i would find appealing at first sight. So, I guess my
question is whether you discarded this type of scenario for some reason,
or you simply believe that the data collector to data collector protocol
could reuse an existent protocol or else?

About the Network paramenter server. I am not sure I understand what is
the role you have in mind for this element.
In the definition, you state that:
"   In some of the use cases, it is necessary for the analysis to compare
    the measured against the nominal network performance, or correlate
    measured parameters with the type and key parameters of the userOs
    network connection."

This may lead to think that the network parameter server provides
information that is relevant for the analysis of the data rather than
for the performance of the tests. However, the only protocol defiend
involving the network parameter server is with the M-client, which
implies that the parameters are needed to actually perform the tests
rather than analyzing the data. I think this should be clarified.
Even in the case the parameters are needed to perform the tests, it is
not clear to me why should the clients retrieve the parameters directly
from the Network parameters server rather than obtain it from the
M-controller along with the tests. I mean, defining a protocol between
the M-controller and the Network parameter server rather than a protocol
between the network parameter server and the M-cllients. Could you
expnad on the rationale for this?

Regards, marcelo

_______________________________________________
lmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lmap