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
On 5/7/12 21:44 , Jérôme Benoit wrote: 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.
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
No, it is not eye candy. UDM allows users of the Atlas system to measure their own targets using remote probes. 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.