Subject: [lmap] comments on lmap-requirements

From: Brian Trammell <[email-masked]>
Date: Tue, 25 Sep 2012 18:08:40 +0200

Greetings, all,

and thanks to the authors for the LMAP requirements draft; have been looking forward to this discussion for a while. Having worked in network measurement for quite some time, mainly on the passive side of things, I've seen a need for a standard, cross-vendor/cross-domain measurement control plane for a while. Indeed, there will be political hurdles to clear as well as technical ones to make such a thing work (to say the least), but this is a very good start.

I have a couple of questions and observations about choices made thus far in the architecture, as some of these would seem to limit the applicability of the final protocol(s) to the stated use cases.

Is the intention of LMAP to design new measurement methodologies and protocols, to overlay control on an existing set of measurement protocols, or to provide a framework/control system for controlling existing measurement systems? The assumption seems to be the first, though I'm not sure it's a good idea to start from scratch. There's a lot of work in internet measurement (both protocols and tools, including already-deployed active and passive measurement systems) that could be leveraged to make an LMAP-based infrastructure more quickly deployable.

In these cases, as Marcelo and Al point out, the definition of client and server are probably not quite right / too specific. Indeed, if the measurement protocol itself is a "pluggable" thing, then the measurement client and server aren't really part of the LMAP architecture; there's simply a measurement _point_ -- if that's an active client, or an active server, or a passive observation point isn't really relevant, and the other side of the measurement is simply a parameter of the request to the measurement point.

Second, is there a reason that direct connections from a measurement controller to a measurement point are not supported? This argument that this reduces DoS potential is not convincing, given that the direction of connection initiation and the final decision to authorize and initiate a measurement need not be dependent. What it does do is keep a measurement controller from being able to do iterative measurement: i.e., using the results of a prior measurement to direct the parameters of a subsequent measurement, as would be useful when trying to isolate an intermittent connection failure in the user diagnostics use case.

Third, the role of the network parameter server is confusing to me as well. There is simply knowledge about a network, and separating this among a collector (which itself needs to know network parameters for certain measurements to be interpretable) and a separate parameter server seems arbitrary. It also makes it impossible for the lmap infrastructure to update network parameters automatically through observation.

Also, I realize the proposal is rather initial with respect to security and privacy issues, but I think that data integrity should at least be addressed: in any environment in which the entity initiating measurement does not control the measurement points, there must be some mechanism for detecting, rejecting, and/or correcting maliciously incorrect measurements. Especially in cases where LMAP will be used to verify compliance with regulations or SLAs, if there is something to be gained by a measured entity trying to game the results. This probably happens at the data level as opposed to the architectural level, but this class of attacks should at least be mentioned, declared out of scope, and treated in a future document.

Best regards,

Brian