Subject: [Research-funding] network management research funding text

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Jul 2003 11:39:36 +0200

Below is some text for section 3.5 of the IAB research funding draft.
I basically took the text from <draft-iab-research-funding-01.txt>
and rearranged it and added a few pieces here and there. I understand
that the idea is to not be comprehensive and so I tried hard to not
add lots of additional research topics people actually work on.

/js

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

---

From: Frank Strauß <[email-masked]>
Date: Wed, 09 Jul 2003 21:54:23 +0200

> add lots of additional research topics people actually work on.

Thanks for picking this document up again! Here are some additional
comments...

> ------------------------------------------------------------------------
> 
> 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?

>    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
              ^^
>    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.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.)

> 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.

> 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.

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.

_______________________________________________
Research-funding mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/research-funding

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Jul 2003 10:32:53 +0200

> 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.

> >   network of instead of isolated devices. Current network management

fixed

> titles of both subsections denote. (Sorry, I have to concrete suggestion

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?

> 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?

> 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

   more work is needed to improve the automation achieved by network

Any other suggestions?
 
> 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.

> Sorry, again no concrete proposal yet.

Can you please write something up?

[Attached is the revised version of the text.]

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Jul 2003 16:52:50 +0200

On Mon, Jul 14, 2003 at 01:34:04PM +0200, Frank Strau? wrote:
 
> I agree that there are different intentions to be expressed by the
> two sections (and by any of the other sections). Just reading the text
> from a certain distance (like potential people that are addressed by
> this document) lets me think that there are some common arguments.
> The same is true for my initial comment on 3.5.4.

Any concrete proposals for changes?

>                                                ^ plural?

fixed
 
> Either "or other mechanisms" or "for example", not both, I suggest.

fixed
 
>                                                      ^the

fixed
 
> Sounds good to me.

[...]
 
> Ok. How do you think about this...?
> 
> Analysis of Current Network Management Application
> 
> In the past much work has been spent on the specification and
> implementation of a network management architecture. However, most
> administrators use far less components of this architecture than
> possible. There are only vague estimations about the reasons for
> this reluctance. A better understanding of what is used for which
> purpose and what is not for which reasons is highly disirable.
> This can be done by an automated analysis of network management
> protocol traffic and applications at operators' sites and enhanced
> by additional conversations with the operators.

What about this rewrite:

3.5.6 Analysis of Current Management Protocol Usage

   In the past, much work has been spent on the specification and
   implementation of the current Internet network management
   architecture. However, operators reported that they use only a
   subset of this architecture.  A better understanding of what is
   used for which purpose (and what is not used) is highly desirable.
   This issue can be addressed by automated network management
   protocol traffic measurements and subsequent analysis in close
   cooperation with operators.

[Attached is the complete current version.]

/js

---

From: Frank Strauß <[email-masked]>
Date: Tue, 15 Jul 2003 17:22:31 +0200

>    cooperation with operators.

D'accord. Sounds better to me.

---

From: Frank Strauß <[email-masked]>
Date: Mon, 14 Jul 2003 13:34:04 +0200

> [...] I have added the sentence:
> 

I'm fine with that.

> [...] What about this:

                                                ^ plural?

Sounds good to me.

                                                      ^the

Sounds good to me.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Jul 2003 17:55:12 +0200

Attached is the revised text for section 3.5 of the IAB research funding 
draft which includes the changes made during the 13th NMRG meeting in
Vienna. 

This is the last call to submit your input. If I do not receive any
additional comments by August 10th, I consider this version to be in
concens with the NMRG views.

/js