Re: Network Control Architecture

["Eric L. Boyd" <eboyd@xxxxxxxxxxxxx>]

Hi all,

Sorry to join the discussion late.

Before comparing Monalisa and perfSONAR, it might help to define exactly 
what perfSONAR is.

First, perfSONAR is primarily a set of services and protocols (schema) 
for sharing performance data. The specific data schemata are extensible 
making it possible to share any kind of data that fits in the general 
architecture. (Basically performance data.)

Second, perfSONAR is a project made up of individuals and institutions 
that are actively developing tools, libraries, and schema in support of 
this data sharing. (Active participants include Internet2, ESnet, the 
GEANT2 JRA1 project [including many European NRENs], RNP, UDel, and Fermi.)

Third, there are several perfSONAR implementations - of clients and 
services. But, it would be a mistake to call any one of them 'the' 
perfSONAR implementation. The advantage of the open source effort is 
that there is a best-of-breed competition for nearly all components. The 
only truly important thing is that all components understand the same 
protocols - syntax (schema) and semantics (business logic). (These are 
being standardized in the context of the OGF NM-WG and the OGF NML-WG.)

It is true that monaLISA (mL) currently has more functionality than the 
current set of pS applications. However, due to the open-source nature 
of the perfSONAReffort (there are 10's of developers working on the many 
aspects of perfSONAR) I would expect that to change over time. (We 
originally wanted to work with Cal Tech to enhance mL but we were not 
willing to sign the licensing contract.)

Architecturally, the two frameworks are very similar. They are both 
Service Oriented Architectures (SOA) with a defined set of services. 
perfSONAR is still growing and not all aspects of the distributed 
services model have been implemented. (For example, current services use 
a global single point of failure Lookup Service (LS). However, the 
multi-LS has already been alpha tested and is likely to be in the next 
major release.

The primary differences:

MonaLISA is written in Java and makes use of some Java only technologies 
like JINI. I do understand that MonaLISA can access non-Java services. 
But, if I understand correctly, to truly 'join' the SOA network of 
services, you would need some Java.

perfSONAR is an open-source development project. There is good and bad 
to this. Even those of us that have been involved from the beginning do 
not have very much central authority or control over it. This can cause 
problems with interoperability, which is why the aforementioned 
standards process is so important. However, if someone wants their 
favorite new network metric made available to others - they can make it 
happen. They don't need to get someone else to do it for them, or sign 
away their ability to develop related software in the future. Since the 
point of implementing and deploying this software is to share the data - 
it is usually not too difficult to get people to agree on shared schemata.

Most perfSONAR applications are currently focused on network hardware 
and statistics. This is only natural since the first participants (and 
still the largest constituency) is networking organizations. However, I 
would like to make it clear that perfSONAR can absolutely go all the way 
to the desktop. There are already services written to run arbitrary 
command-line tools (CL-MP). The only thing required to return something 
like cpu utilization (or any other host statistic) is to define a schema 
for that type of data. (I agree that is is critically important to 
collect host performance issues to be able to differentiate host and 
network performance.)

Hope this helps inform the discussion. I'm happy to answer questions.

--Eric

Harvey Newman wrote:
> PerfSONAR is just beginning to develop a fraction of the services and 
> functions
> that MonALISA has had in operation for a long time.
>
> It is also not obvious that PerfSONAR will engage a full time systems 
> architect to
> try to reproduce the real-time services architecture with a 
> sufficiently powerful
> multithreaded engine to schedule and drive the services, a fully 
> distributed services
> architecture that has no single point of failure, a mutually-aware set of
> agents, a robust high - performance messaging infrstructure, etc. It 
> would not
> be easy and it has rarely, if ever, been done before. In case how a 
> fully fledged
> PerfSONAR would compare to ML is a future consideration. It won't be
> sufficiently function by the time the LHC is starting to do physics, 
> by mid-2008.
> And ML will conitnue to advance and grapple with the real situation at 
> the LHC.
>
> PerfSONAR will not touch the end systems. ML does cover this aspect 
> fully, as we need to
> distinguish end-system performance, load and configuration issues from 
> network issues.
>
> Since PerfSONAR is the agreed upon direction, and the services it 
> fields will be
> relatively simple, we are sure we can interface to those and provide 
> the interfaces
> as needed. That is already the case for the PerfSONAR monitoring sone 
> today.
>
> Regards
> Harvey
>
> Gigi Karmous-Edwards wrote:
> > Hi Harvey,
> >
> > How does MonAlisa compare with the effort of PerfSONAR 
> > (www.perfsonar.net).?
> >
> >
> > Gigi
> >
> > --------------------------------------------
> >
> > Gigi Karmous-Edwards
> > Principal Scientist
> > Advanced Technology Group
> > http://www.mcnc.org
> > MCNC RTP, NC, USA
> > +1 919-248 -4121
> > gigi@xxxxxxxx
> > --------------------------------------------
> >
> >
> >
> > Harvey Newman wrote:
> >
> > > Hi,
> > >
> > > We strongly recommend using MonALISA real-time, fully distributed 
> > > services to do this.
> > > We need non-stop real-time operations that are proven to be robust 
> > > and globally scalable,
> > > with no single point of failure. Also the intelligence in the agents 
> > > both in the network and end-systems
> > > allow us to understand what is going on, and take action end-to-end.
> > > .
> > > Hence our technology choices for US LHCNet and UltraLight.
> > >
> > > Regards
> > > Harvey
> > >
> > > PS ML is currently monitoring and updating > 1M parameters at 340 
> > > sites.
> > >
> > > Gigi Karmous-Edwards wrote:
> > >
> > > > Dear All,
> > > >
> > > > At the last GLIF control plane meeting in Minneapolis (meeting 
> > > > minutes will be sent tomorrow to the list) we had several 
> > > > discussions on interoperability between the different networks. We 
> > > > drew a diagram on the white board with input from the participants. 
> > > > The outcome was an action item on me to send out a high level 
> > > > functional diagram on the framework for interoperability (sorry for 
> > > > the delay). We expanded the notion of network resource in the 
> > > > control plane working group to include other resources as well, 
> > > > such as compute, storage, instruments, etc.
> > > >
> > > > Enclosed are three very high level slides discussing the framework 
> > > > and the high level functional components included  in a "Resource 
> > > > Broker " and a "Network Resource Manager". Several of you in the 
> > > > meeting had comments on the interfaces we need to standardize. I 
> > > > propose we start with the "Grid Network Interface"  GNI, first.
> > > >
> > > > We also agreed to work with both the GLIF community and standard 
> > > > bodies like OGF to develop these interfaces. I look forward to your 
> > > > comments.
> > > >
> > > > Kind regards,
> > > > Gigi

--
Eric Boyd, Director
Internet2
eboyd@xxxxxxxxxxxxx
office: +1-734-352-7032

Make high-performance connections in person:
The Spring 2007 Internet2 Member Meeting
http://events.internet2.edu/2007/spring-mm/