On Mon, 07 May 2012 14:15:26 +0200 Philip Homburg <philip.homburg@ripe.net> wrote:
I'm having hard time to find the roadmap and the talks on the RIPE Atlas web site as a public user with no account. But I might have not searched enough. Where are they ?
There is not a single comprehensive road map. What is there, is just bits and pieces. Most of it was discussed during the most recent RIPE meeting. The talks by Robert and Daniel should be online.
To list some things that have been mentioned:
* TTM shutdown, Atlas is expected to provide functionality similar (but not identical) to what TTM provides
You plan to change the measurement control protocol used in TTM ? I do not know which protocol TTM is using but if it's OWAMP ou TWAMP, that will not fit the needs for large scale measurement campaign runt from network edge.
* DNSMON gets moved to Atlas
In what Atlas call a "probe" (and what I call the measurement agent) ?
* Roll out of Atlas Anchor boxes (regular PCs at well connected locations that can serve as the target of measurements and as a more powerful Atlas probe)
Sound like a good idea :) You then should add a tag to the measurement result that will permit to distinguish the type of box running the measurement agent, like "generated": atlas-probe "generated": atlas-box for example.
* Better UDM interface * UDM for all RIPE members (instead of just probe hosts and sponsors)
Eye candies.
* A syntax (that is not yet finished) permit to express what a measurement will do. The syntax is thought as a way to express what the software functionalities are and how each component interact with each other. I give a working example just to show the idea :
However, I think this would be a great area the community can work on. Plenty of people has expressed interest in something more general than what is currently implemented in Atlas.
So if people can come up with a design that is both secure and can work on 8 MB probes, then maybe that can be used to create a common interface to the different measurement platforms.
If you have any document describing the JSON syntax used in Atlas, I can write the code for your measurement agent that will de-/serialize the probe definition to begin with. If you have the same for the REST API, the implentation be done also. grenouille_config (the component that permit to read the probe definition) is modular and pluggable; just like grenouille_sample (the component that send the result). The 8MB limit will be the hard part, since your agent is written is OCaml, it will mainly à matter of tuning the GC and profiling the data structure defined to avoid large allocation of chunk. We do not have securities problem because of OCaml choice on the implementation side. Securities mechanism will probably be the same as of the one you can find on most "web services" (shared secret salted and hashed) to ensure that a REST transaction is legit. I have to think about it some more ... For API and JSON syntax standardisation, the first step is to write the specifications we(grenouille.com) plan to use and Atlas use and plan to use, then discuss and factor out the best of each. We have some writings but most of them are in French :)
I do not know the list of active measurements an Atlas probe cover.
At the moment, ping, traceroute, tdig (dns), httpget, sslgetcert.
Natively implemented or run via a external binary and CLI options ? Regards, -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D