Subject: [lmap] Comments on draft-schulzrinne-lmap-requirements-00

From: Shane Amante <[email-masked]>
Date: Tue, 25 Sep 2012 10:06:03 -0600

I'd say this is a good start at a IETF draft to discuss the LMAP work.  Here are some additional thoughts for your consideration:
1)  It seems critical to look at creation of a data model and/or file format that allows this architecture to bundle together *both* the measurement parameters/criteria used as input to a measurement test /and/ the measurement results collected as part of that particular measurement run.  This will be critical if/when measurement results are analyzed historically, particularly by third-parties (e.g.: researchers) who may not have originally initiated the tests.
2)  Similar to #1, it seems that for the "Network parameter server", it might be more helpful to assert that what's really needed is a data model to store and, more importantly, exchange key information about, say, a client's access technology or other characteristics (wireless, WiFi, etc.).  At this stage, it shouldn't matter if the information is encoded in XML, JSON or both ... but, certainly those details should eventually get worked out if/when the WG is chartered.
3)  The draft doesn't appear to mention anything about providing an ability for entities to query for and attain historical measurements that have already been collected.  (With respect to "query for", again, it would be nice to have a data model that represented the measurement parameters used as input to a test so those could help winnow down the data sets that match a given criteria of interest that is to analyzed.  See #1.)  Presumably, this would be a valuable capability.  Is this within the purview of the draft/architecture?
4)  The draft also doesn't discuss how conflict resolution among tests requested to be scheduled will be performed. Specifically, is the client allowed to decide, on its own, how to deconflict two tests that may have been scheduled at/near the same time?  If so, how?  Presumably a single algorithm could be used for conflict resolution at either the measurement controller or the client-end ... or, both ...  Likewise, if a measurement controller has asked a client to perform a test, but the client is unable to do so because of a conflict, then it should report that to the measurement controller so the controller can: stop asking the client to do the test, re-schedule it at a different time or take some other action, e.g.: select a wholly different client.
5)  Finally, it might be nice to consider that for redundancy and/or performance reasons a singular measurement test may simultaneously write results to several measurement data collectors.  Alternatively, is the vision that a single measurement data collector will receive results and, in the background?, distribute that to multiple measurement data collectors?  Ultimately, this is a discussion about the necessity of caching of measurement data, which becomes important to consider as either: a) the data set inevitably grows larger (into millions of nodes?); and/or, b) entities wish to consume historical data-sets that inevitably will be extremely large.

Anyway, it might be nice to put these on the table and decide if they are in scope for the present effort or if it's necessary to defer them to a later stage.

Thanks,

-shane