Path: utzoo!attcan!uunet!snorkelwacker!usc!sdd.hp.com!ucsd!ucbvax!CS.UCL.AC.UK!Z.Wang
From: Z.Wang@CS.UCL.AC.UK (Zheng Wang)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: 9 interesting & challenging problems for Netman
Message-ID: <9009221327.AA25351@ucbvax.Berkeley.EDU>
Date: 22 Sep 90 11:50:07 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 59


 >Here are what we consider to be 9 interesting & challenging problems for
 >network management (these are based on
 >real requirements, not tedious exhaustive MIB definitions):

 >1. given the trace of packets between two end points on a LAN,
 >and a FSM, petri net, lotos/csp/ccs/Estelle spec for the protocol,
 >detect protocol (elements of procedure) errors. (easier, do the same
 >given ASN or XDR for packet formats:-)

 >2. Given same data, automatically ascribe performance problems
 >to incorrect packet size, timeout, window etc...

 >3. given a traffic matrixfor a LAN, automatically find the best place
 >to partitionm the net with a bridge/switch/router (subject to any
 >sensible topographical/logical or other constraints).

 >4. Find a good way to visualise the "closeness" of hosts based on the
 >frequency with which they communicate (this is non-trivial)

 >5. Automatically draw a "tube" map (friendly/Metro) of the net given
 >the topography...

 >6. Given a general traffic trace, detect patterns of communication
 >involving more > than 2 parties (e.g. YP or DNS lookup followed by
 >telnet is triv. case).

 >7. Interpret auto-correllation between packets from/to and/or
 >same src/dst in a sensible fashion...

 >8. Given a trace of packets between 2 protocol entities at layer 4,
 >invent a pleasant and efficient programming language to describe &
 >enable the reconstruction of application level exchanges.

 >9. Do all of the above for an Internet.

To solve all the problems by machines can be very hard. We may have
to wait a couple of years for neural nets to grow and to learn.
But human brains are the best to do those jobs. What is needed
is a tool for us to see the traffic inside the cables.

I imagine what we need is a huge screen (as seen at some city
traffic control centers) with all the nodes and links. Each
connection is represented by a thin line. When traffic passes,
it leaves a trace on the line. So the more traffic passes, the darker
the line is. Different traffic can be represented by different
colors (eg. Yellow Page traffic is yellow :-) We also need some
buttons so we can choose to average the traffic at different
intervals. Yes, we need a camera to get a snap shoot from time
to time.

With the visulization of the complete traffic, a human brain
can easily answer some of the 9 questions.

For a LAN, to collecting the data at a reasonable interval may
not be a problem. But for an Internet, we may have to put all the
snap shoots together to see the whole picture.

Zheng