[atlas] Feature-suggestion: "round-robin" probes

On Mon, 07 May 2012 14:15:26 +0200
Philip Homburg <philip.homburg at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </ripe/mail/archives/ripe-atlas/attachments/20120507/ef2a82e3/attachment.sig>