[mat-wg] RIPE Atlas / UDM as a replacement for TTM

On 18.06.2012, at 16:23, Philip Homburg wrote:

> It is not clear to me how a ping target in your network can fake anything.
> A probe in your network is a different story, but a target?
> Probes just report how quickly and reliably they can access the target.
> If have no idea how you could fake that by controlling the target.
> 
>> - and that are not part of the normal network churn that 
>> www.space.net or one of our routers might have.  So far we use the TTM
>> boxes for that - but they might die of old age some day...  Which brings 
>> back the topic of the Atlas Anchor boxes...  any news on that?
> 
> I leave it to somebody else to comment on the anchor boxes. They will come,
> but when and where, I have no idea.

I fully understand the value of being able to say "All the measurement infrastructure including the targets is managed by a neutral and impartial third party".

Coming back to the anchor boxes: the idea of RIPE Atlas anchors is to have a bigger probe for deployment inside network infrastructure. This will complement the standard probes that are typically deployed nearer to the edge of the network. Atlas Anchors will have a higher capacity and more bandwidth, so they will be able to do more measurements than the standard probe.

In addition to being high capacity probes Atlas Anchors will also serve as targets for active measurements: they will be well-known, willing and cooperating targets for active measurements from the standard probes. The active measurement traffic from the standard probes can be monitored at the Anchors. One possible use of that
is to diagnose asymmetries in the path. We will not get one-way delay back because of the lack of GPS time, but some of the benefits of one-way will be possible.

We are currently working out the details and a plan for an initial deployment. In particular we want to avoid the mistakes we made with TTM, specifically in the hardware/software life-cycle area. The straw-man currently looks like this:

	- RIPE NCC members only
	- hardware bought and owned by the host
	- initially a very specific but widely available configuration including OOB access etc.
	- hardware capable of supporting additional services, like f.i. a local K-root instance
	- hardware installed and network configured by host
	- once hardware installed and connected, RIPE NCC takes over operations (like Gert wants ;-)
	- no GPS clock, but as accurate NTP as possible
	- formal agreement about hosting and operations
	- agreed hardware replacement cycle

We are evaluating widely available hardware for this and developing the probe software. We will ask for beta testers after the summer. In the meantime all input about this is welcome!

Does this answer your questions Gert?

Daniel