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

On 5/5/12 16:43 , Jérôme Benoit wrote:
> On Sat, 05 May 2012 12:22:15 +0200
> Philip Homburg<philip.homburg at ripe.net>  wrote:
>
>> I don't know about SamKnows, but for RIPE Atlas, talks contain a lot
>> of details about how the system works. To the extent that there is a
>> well defined road map, we talk about it.
> 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
  * DNSMON gets moved to Atlas
  * 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)
  * Measurements for IPv6 launch
  * Better UDM interface
  * UDM for all RIPE members (instead of just probe hosts and sponsors)

>> As much as I like open source projects, I really don't see it working
>> for the current Atlas system.
> It work very well, we do it since age but we took a very different
> approach :
>
> The measurement agent is designed as a standalone component with that
> requirement :
>
> * Must be portable, that mean all measurements must be implemented
>    natively.
> * Datagram-based measurement are divided in four components
>      - packets forge
>      - packets injection
>      - packets capture
>      - packets filter
> Each component work is mapped to a dedicated thread (an Lwt job more
> precisely, which bring in a very nice way to manipulate packets in a
> asynchronous fashion).
Note that for Atlas, it has to work on an underpowered CPU without MMU 
and with 8 MB of memory.
> * Other measurement can be mapped with a plugin dynamically loaded (the
>    API is not stable yet)
> * 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.
>> Probe are just too fragile, the whole
>> system is too complex.
> ?
>
> I fail to understand this argument.
> Every single piece of software is a complex system, that has never ever
> be an argument to not opensource it.
> And for the fragility, probably a design issue of the probe (but I
> can't known for sure, no source code to review).

Running an open source project is not a goal of the RIPE NCC. If that's 
supposed to be a goal then the members will have to ask for it through 
the appropriate channels.
>>   Does releasing the Atlas source benefit the
>> RIPE community? I don't know. Fortunately, that is not my decision to
>> make.
> RIPE call. I think RIPE have made a mistake by not going opensource
> since the beginning.
I guess opinions differ there.
>
>> If you have a dedicated team in an open
>> source project, then you should be able to duplicate our work. You
>> can always for feedback on any design, or ask how we do things.
> I do not know the list of active measurements an Atlas probe cover.
>
At the moment, ping, traceroute, tdig (dns), httpget, sslgetcert.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ripe-atlas/attachments/20120507/636e8f4e/attachment.html>