On 5/7/12 21:44 , Jérôme Benoit wrote:

On Mon, 07 May 2012 14:15:26 +0200
Philip Homburg <philip.homburg@ripe.net> wrote:


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.

TTM boxes have GPS devices for time synchronization. That allows them to perform accurate one-way measurements. This capability will be lost.

The TTM network is relatively small and static. Atlas can easily handle that, except you will be limited to two-way measurements.

In what Atlas call a "probe" (and what I call the measurement agent) ?

Yes. Except that an Atlas probe tends to be a physical device as well.

  * 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.

We still have to figure out where we want to document meta-data. It doesn't make much sense to put all data about a probe in each and every measurement result.

  * Better UDM interface
  * UDM for all RIPE members (instead of just probe hosts and
sponsors)

Eye candies.

No, it is not eye candy. UDM allows users of the Atlas system to measure their own targets using remote probes.

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.

Commands for the probes are not in JSON. For output we are still transitioning to JSON. Currently the output is a mix of JSON meta data and free form ASCII output. In the next firmware upgrade that should become just JSON. For example for ping:

{

"id":"1001",

"fw":4414,

"time":1331729380,

"name":"193.0.14.129",

"addr":"193.0.14.129",

"srcaddr":"193.0.10.135",

"mode":"ICMP4",

"ttl":62,

"size":20,

"result": [

{ "rtt":49.101000 },

{ "rtt":6.899000 },

{ "rtt":4.139000 }

]

}

        

        We have this as internal documentation, but it should be
        published some time.



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 ...

Our security policy goes further than just protecting the probe. We also try to avoid getting the probe hosts in trouble. For example, having a probe visit certain web sites may be a bad idea.

    

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 :)

Yes.

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 ?

Natively implemented. Creating lots of new processes turned out to be a bad idea on a system without an MMU.