[lmap] more comments on draft-akhter-lmap-framework

[<[e-mail]>]

My final batch of comments

First, I think some of the material in Section 3 could be helpful expansion (on what was rather briefly mentioned in draft-eardley-lmap-framework). Sections 4 & 5 have lots of interesting stuff - question is whether this is a general framework for large-scale measurements (where we need to talk in detail about the tests) or whether it's a framework for LMAP WG (which only needs a brief mention of areas outside the scope of lmap wg, and so wouldn't have much about the tests, as this is ippm).

Secondly, there were several comments about multiple measurement agents (& peers?) acting together. (Section 3.2 & 6.2.1). you mention several different cases, I'm not sure I understood properly or got them all.
(1) I'm sure there's a case where one test triggers another (say, the dns result followed by request to website) - this is ok.
(2) I think you have a 'latency under load' test (S3.2), where the latency is measured for a pkt/file being sent between MA & Measurement Peer, but another Peer is generating other traffic so that a bottleneck queue is loaded. I haven't thought about this much - do you think there are other tests involving a second Peer? or even 3rd, 4th...? Or is it just 'latency under load'?  I'm wondering whether it would be best to think about the specifics of how to do the 'latency under load' test, rather than a general capability for coordinating multiple Peers in one test.
(3) you mention (S6.2.1) a case where multiple Measurement Agents submit results all with the same Measurement Task ID. I guess this is a test where lots of coordinated measurements are made. You also mention a shared key between multiple MAs, which I think must be related. I don't understand this case, please explain more.
Am interested to understand this whole area better, regardless of where the WG decides to draw the line between in scope & out.

Third, you have some stuff about task scheduling where it seems important to have highly synchronised time between the controller, MAs and collector (and measurement peer?). why would this be needed? You mention about NTP and the issue that NTP doesn't give very accurate time sync to a device on the end of an access line (because you can't triangulate to multiple time servers). I suppose the error might be a few millisecs - the sorts of cases I had in mind it would easily be accurate enough. Incidentally I don't see why your solution (NTP clock sent from controller) helps, since you still have the lack of triangulation on the end of an access line.

Thanks
Best wishes
phil