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

On 5/7/12 21:44 , Jérôme Benoit wrote:
> On Mon, 07 May 2012 14:15:26 +0200
> Philip Homburg<philip.homburg at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ripe-atlas/attachments/20120509/1c81c190/attachment.html>