perfsonar development work

[Joe Metzger <>]

Jeff & Andreas,
Just out of curiosity, has anybody looked at how the approach being  
developed here compares
to the netdimes.org approach? Do they have any algorithms that we  
should be leveraging and extending?

--Joe

On May 8, 2008, at 11:24 PM, Jeff W. Boote wrote:

> On May 8, 2008, at 9:47 AM, Andreas Hanemann wrote:
>
> > Hi Jeff,
> >
> > Jeff W. Boote schrieb:
> > > Hi Andreas,
> > >
> > > I fully agree with Stephan here. Also - I added some additional  
> > > comments in the document regarding the 'neighborhood' information  
> > > registered by a service, and the new messages you have created.
> > >
> > > The 'neighborhood' information needs to be abstracted into more  
> > > of a general rule for all services. It should not rely on the  
> > > fact that the HADES MA is 'usually' near a router. I suggest  
> > > having the web admin derive a NURN based on where it is in  
> > > topology space (perhaps even communicate with the topology  
> > > service to figure it out), and absent that it could run several  
> > > traceroutes to known divergent locations on the network and  
> > > register all the first N hops it sees (including 0). N could  
> > > default to something like 3-5, but could be administratively  
> > > configurable to a number large enough to get off the NREN for  
> > > example.
> > This generalization of the location seems to be a good idea, but  
> > we need to invest some thoughts into its details. The description  
> > that you are mentioning is the first step, but we also need a  
> > reliable query mechanims.
> >
> > Let me at first rephrase a bit what you are suggesting. There is a  
> > HADES box (or any other kind of "MP") located somewhere in the  
> > network, maybe near an NREN router, maybe somewhere "deeply" in a  
> > campus LAN. There should then be global reference locations (e.g.  
> > DANTE office, Internet2, somewhere in Asia) and traceroutes should  
> > be run from the box location to these well-known reference  
> > locations. You are suggesting then to store information about 3 or  
> > 5 hops per path which are near the location to represent each of  
> > the paths. It is the question how we should represent the hops. My  
> > proposal would be to store the router host names rather then the  
> > IP addresses, because this may be rather unique(?). For routers in  
> > campus LANs such a resolution via a topology service may not be  
> > possible which would be a good reason to extend the representation  
> > to more hops. All this information should then go into the LS.
> >
> > If there is the situation that a path should be investigated, we  
> > need a mechanism to filter out those boxes that are relevant to  
> > the path. This could be done in a manner that we convert the path  
> > representation to router host names and ask the LS to return all  
> > measurement box locations where the router host name is mentioned  
> > as part of the paths. Maybe we can sort the result according to  
> > the hop where is found (prefering nearer hops). The box locations  
> > are then used to query a "Traceroute MA" to get the actual  
> > measurement paths between the candidate boxes and then to decide  
> > what is relevant. These data can then be requested from HADES MA.
>
> Hi Andreas,
>
> I think this captures the general idea. In terms of determining how  
> many 'hops' away from the service to store and register, it might  
> make more sense to do something a bit more adaptive. Say, keep N+3  
> hops, where N is the number of hops that are the 'same' between the  
> 3 or so divergent locations that you try. That would ensure that  
> you get something of a network topology triangulation to your  
> divergence point. Now, this kind of breaks down a bit once you have  
> circuit connections close to the host since the 'next' hop could be  
> halfway across the globe, but I don't see much around this other  
> than to go the full-blown topology service and storing/registering  
> NURN locations for the service.
>
> As to how the hop information can be stored/communicated in the LS  
> service registration... I suspect we might know someone who has  
> ideas on this. (This is far more complicated than we need for this  
> - but some of the general ideas on how this could be done can be  
> found at: http://tools.ietf.org/html/draft-ietf-ippm- 
> storetraceroutes-08 )
>
> jeff