perfsonar development work

[Jochen Reinwand <>]

Hi Andreas, hi all,

I don't like the complexity introduced for BWCTL MP and Hades MA. Keep in 
mind 
that it is the same for all similar service we might have to look at in the 
future (OWAMP MP, Ping MP, Traceroute MP, Pinger MA and so on).

Instead of analysing this top to bottom we should go from bottom to top.
Instead of dreaming about what we would like to get from our services as 
information, we should answer one simple question: What information can a 
perfSONAR service give us that can be of use?

Nearly every measurement done has to deal with IP addresses. For Hades and 
BWCTL (and most other similar tools) this address is attached to a network 
interface that also has a next hop (default route). This information (and 
possible all similar network interface configuration information, like 
netmasks) can be made available. No other information should be artifically 
created! We are releasing our software! Such internal hacks are a mess!

How to collect this information? Of course, using perfSONAR capabilities!

- For the BWCTL MP (and similar MPs like OWAMP, Traceroute...) it is simple. 
It already announces the interface IP to the LS.
We should think about adding the next hop (and similar network interface 
configuration) information here.

- For the Hades MA we have one step in between. We do not need the address of 
the MA, but the addresses of the measurement interfaces. The Hades MA knows 
all interface addresses it can provide measurements for. Question here is: 
Should the Hades MA register all these addresses to the LS? I think it 
should! RRD MA is doing the same. But there are also other possibilities, if 
we do not want to use the LS this way. I don't know if this LS usage is 
really OK for the perfSONAR architecture. Is it for RRD MA? Anyway, it is 
e.g. also possible that the Hades MA provides the list directly if requested.
Once again the next hop (and similar) information has to be added here.

Just one note about the next hop information: I think we do not really need 
it! It can be difficult and error prone to determine it! It would be better 
to extract this information directly from a traceroute. I see the traceroute 
information as very important in any way.

So how to retrieve this traceroute information? Andreas is writing about a 
Traceroute MA. I don't like this. It is too vague. What kind of data is this 
MA collecting? Who sets it up? Where is it located? Does it have all required 
information?
The simple and common solution: On every MP a Traceroute MP is running 
additionally. Now you can easily ask this MP to do a traceroute to 
"well-known global network locations", or every other location that might be 
useful. Important here is that this information can indeed be done statically 
scheduled and collected in a Traceroute MA. I would even prefer this. But in 
the end it should not really matter, because MAs and MPs have nearly the same 
perfSONAR interface you can get the desired information from.

Now all the required information should be available for a client or a 
topology service to get a good picture of the network topology.

greetings,
Jochen

On Wednesday 14 May 2008 11:18, Andreas Hanemann wrote:
> Hi,
>
> For your information I have put a first update of the "Finding closest
> MP" document on the wiki which is updated until page 5. This first part
> should be the major point where the discussion of today's conf call
> should relate to.
> http://wiki.perfsonar.net/jra1-wiki/index.php/Finding_Related_MPs_Conf_Call
>_14_may_2008
>
> I am going to work on the schema issues and will provide another update
> until the call.
>
> Best regards
> Andreas

-- 
Jochen Reinwand, DFN-Labor
Friedrich-Alexander-Universität Erlangen-Nürnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstraße 1, 91058 Erlangen, Germany
Tel. +49 9131 85-28689, -28800, Fax +49 9131 302941

www.win-labor.dfn.de