[Research-funding] Re: [nmrg] network management research funding text

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Jul 09, 2003 at 09:54:23PM +0200, Frank Strau? wrote:
> >------------------------------------------------------------------------
> >
> >3.5.  Network Management
> >
> >   The Internet had early success in network device monitoring with
> >   the Simple Network Management Protocol (SNMP) and its associated
> >   Management Information Base (MIB).  There has been comparatively
> >   less success in managing networks, in contrast to the hierarchical
> 
> What do you mean by "hierarchical"? How about just removing this word?

This word was in the original text and this is why it is there. I am
fine with taking this out.

> 
> >   monitoring of individual devices. Furthermore, there are a number
> >   of operator requirements not well supported by the current Internet
> >   management framework.  An enhanced network management architecture
> >   that more fully supports real operational network management needs
> >   is desirable.
> >
> >   Unfortunately, network management research has historically been
> >   very underfunded, because it is difficult to get funding bodies to
> >   recognize this as legitimate networking research.
> >
> >3.5.1.  Managing Networks, Not Devices
> >
> >   At present, there are few or no good tools for managing a whole
> >   network of instead of isolated devices. Current network management
>              ^^

fixed

> >   protocols such as SNMP are fine for reading status of well-defined
> >   objects from individual boxes. But managing networks instead of
> >   isolated devices requires to view the network as a large
> >   distributed system. Research is needed on scalable distributed data
> >   aggregation mechanisms, scalable distributed event correlation
> >   algorithms, and distributed and dependable control mechanisms.
> >
> >   Applied research into methods of managing sets of networked devices
> >   seems worthwhile.  Ideally such a management approach would support
> >   distributed management, rather than being strictly hierarchical.
> >
> >   As an example, the current set of network management tools for
> >   managing multimedia (voice and video) IP networks is inadequate, and
> >   research would be useful in this area.  The lack of appropriate
> >   network management tools has also been cited as one of the major
> >   barriers to the deployment of IP multicast [Diot00, SP03].
> >
> >3.5.2.  Configuration Management
> >
> >   Operators at the IAB Network Management Workshop [RFC-3535] held in
> >   2002 reported that scalable distributed configuration management
> >   for sets of network devices is a significant challenge today.  In
> >   particular, it is desirable to execute configuration transactions
> >   across a number of connected devices, which requires protocols that
> >   support distributed transactions.  Furthermore, configuration data
> >   should be represented in a way which simplifies the processing and
> >   generation of configurations with standard tools.
> >
> >   Even individual improvements in configuration management for sets
> >   of networked devices would be very welcome.  Such improvements
> >   would need to include an integrated approach to security for the
> >   configuration data.
> 
> I think there is quite some overlap with aspects already explained in
> 3.5.1. However, I regard it reasonable to differentiate what the
> titles of both subsections denote. (Sorry, I have to concrete suggestion
> for a change.)

3.5.1 is a general statement that more work has to be done to manage
networks rather than devices. 3.5.2 is more specific on configuration
management since operators told us that this is the most pressing issue
from their perspective. This section is also more concrete in that it
mentions the need for transaction support across a network of devices.
Does this make sense?

> 
> >3.5.3.  Enhanced Monitoring Capabilities
> >
> >   SNMP does not scale very well to monitoring large numbers of
> >   objects in many devices in different parts of the network.  Some
> >   implementations also show inaccuracies (especially when monitoring
> >   on shorter time scales) or they lack support for the objects that
> >   operators are interested in. An alternative approach worth
> >   exploring is how to provide scalable and distributed monitoring,
> >   not on individual devices, but instead on groups of devices and
> >   networks-as-a-whole.
> 
> Sorry, I cannot imagine what you mean by monitoring a network here?
> Wouldn't that be comprised of monitoring multiple individual devices
> combined with adequate correlation/aggregation? (I don't mind to go
> into discussions on solutions on this forum.)

Sure, you always at the end talk to devices. However, there is a need to
aggregate data in meaninful ways. You really want to have monitoring
data on the AS level. Similarily, in IPv6 networks, monitoring all
interfaces a la mrtg is kind of useless since you have much more
interfaces. I have added the sentence:

   This requires adequate and scalable data aggregation techniques.

Does this help?

> 
> >3.5.4.  Improving the Scalability of Network Management
> >
> >   Current approaches to network management do not scale sufficiently,
> >   so network operators often have difficulty operating their
> >   network(s) as successfully and economically as desired.  Hence,
> >   more work is needed to improve the scalability of network
> >   management systems.  This might involve application of control
> >   theory, artificial intelligence, expert systems technology, or
> >   other mechanisms, for example.
> 
> Again some degree of overlap with 3.5.1, I think.

I do not see the overlap with 3.5.1 - perhaps the title of this section
is not the best one? A real hype title would perhaps be "Disappearing
Network Management" or a bit more conservative "Autonomous Network 
Management".  Any better suggestions? What about this:

3.5.4.  Autonomous Network Management

   Current approaches to network management do not scale sufficiently,
   so network operators often have difficulty operating their
   network(s) as successfully and economically as desired.  Hence,
   more work is needed to improve the automation achieved by network
   management systems.  This might involve application of control
   theory, artificial intelligence, expert systems technology, or
   other mechanisms, for example.

Any other suggestions?
 
> >3.5.5. Customer Network Management
> >
> >   An open issue related to network management is helping users and
> >   others to identify and resolve problems in the network.  If a user
> >   can't access a web page, it would be useful if the user could find
> >   out, easily, without having to run ping and traceroute, whether the
> >   problem was that the web server was down, that the network was
> >   partitioned due to a link failure, that there was heavy congestion
> >   along the path, that the DNS name couldn't be resolved, that the
> >   firewall prohibited the access, or something else.  
> 
> I think this paragraph misses a final sentence, just stating what kind
> of research is required to address this well described problem.

You basically need a good model of the network and a reasoning engine
to give users explanation. Another approach would be to have specific
automated diagostic tests which can be triggered by customers and which
generate explanations understandable by customers. Sure, such tools
should not reveal any information that is considered a secret by the
network operator. What about adding the following:

   Applied research is needed how to translate data that exists in a
   network or a network management system into terms understandable by
   customers. This also requires to be able to determine which
   customers are affected and how if something breaks. Of course,
   customer network management mechanisms must not reveal any
   internals that are considered to be secrets of organization
   operating a network.

> Maybe, we should have a subsection to address research not only on what
> new ideas should be evolved in the future but also on what we have to
> better understand about the past. The plans on NM traffic measurements
> we had during recent NMRG meetings belong to this kind of research.
> Sorry, again no concrete proposal yet.

Can you please write something up?

[Attached is the revised version of the text.]

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany