J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) (09/20/90)
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. -------- I am sure there are more - if any of these are covered by any of the public domain management tools accumulated by IETF i'd be verra interested thanks jon
Makey@Logicon.COM (Jeff Makey) (09/22/90)
J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes: >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). All of the other problems seem to be Hard, but this one should be solvable by ordinary Operations Research techniques. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
Z.Wang@CS.UCL.AC.UK (Zheng Wang) (09/22/90)
>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
rpw3@rigden.wpd.sgi.com (Rob Warnock) (09/26/90)
In article <9009221327.AA25351@ucbvax.Berkeley.EDU> Z.Wang@CS.UCL.AC.UK (Zheng Wang) writes: +--------------- | 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.... +--------------- This is exactly what SGI's new "NetVisualyzer" product does, that is, the "netlook" program (one of the NetVisualyzer subsystems). [See it at Interop.] +--------------- | ... Different traffic can be represented by different | colors (eg. Yellow Page traffic is yellow :-) +--------------- Hmmm... Good idea. Except that we already use colors for "the more traffic passes, the [brighter] the line is". You can do most of the selective viewing by enabling/disabling filters for different traffic type, but I suppose there might be times when you'd want to see the ebb and flow of two different kinds of traffic... [Have to talk to the implementers...] +--------------- | We also need some buttons so we can choose to average the traffic | at different intervals. +--------------- Got that already ("rescaling interval" and "timeout interval" knobs). +--------------- | Yes, we need a camera to get a snap shoot from time to time. +--------------- Or just save the captured/displayed data in a log file? For later replay? [Got that.] +--------------- | With the visulization of the complete traffic, a human brain | can easily answer some of the 9 questions. +--------------- Yeah, and sometimes it's startling! The first time you see a "timed" update on your LAN, you say, "Wha' th' hell was thayet thayer?!?" [At least, I did... ;-} ] +--------------- | 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. +--------------- "NetVisualizer" lets you select a remote station to do the snooping, while displaying on the local system. [To be fair, I believe there are other products out there that support remote monitoring, too, though without the fancy graphics...] Still, that doesn't solve the problem completely for a large internet, since gathering the real-time data can itself become a significant traffic load. -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
newbery@rata.vuw.ac.nz (Michael Newbery) (09/27/90)
In article <70311@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes: >In article <9009221327.AA25351@ucbvax.Berkeley.EDU> Z.Wang@CS.UCL.AC.UK >(Zheng Wang) writes: >+--------------- >| 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.... >+--------------- > >This is exactly what SGI's new "NetVisualyzer" product does, that is, the >"netlook" program (one of the NetVisualyzer subsystems). [See it at Interop.] Yes, it's very nice (at least the video I saw was impressive---pity my TV screen isn't as high res as the Iris :-) but it requires an Iris workstation on every segment to collect data! Great for SG if they want to sell lots of Iris's but a little out of our range I'm afraid. Also, in the case of Point to Point ethernet over fibre links (router-router) it's not even theoretically possible. Now, if the product collected data from SNMP agents it would be rather more generally useful. -- Michael Newbery<newbery@rata.vuw.ac.nz> Levitation: Joseph of Cupertino (1603-1663) was the subject of such frequent levitation that he was forbidden by his superiors to attend choir.
mrose@CHEETAH.CA.PSI.COM (Marshall Rose) (09/27/90)
Hmmm... A network management product that does not use SNMP. Well, that's certainly an *interesting* direction to take... (I'm far too polite to spell-out what I mean by *interesting*). In any event, discussion on this thread: 1. Has gotten away from the main topic of Jon's original message. 2. Is getting dangerously close to product advertisement. Perhaps we might get back to the original topic? /mtr
mogul@wrl.dec.com (Jeffrey Mogul) (10/05/90)
In article <9009210641.AA20321@ucbvax.Berkeley.EDU> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes: >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... > This is similar to research reported on by Bruce L. Hitson in "Knowledge-Based Monitoring and Control: An Approach to Understanding the Behavior of TCP/IP Network Protocols", Proc. SIGCOMM '88. This was a rule-based system, not a "specification-based" system, but perhaps that is not such a big difference. >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... Jon sent his message before he attended SIGCOMM '90 last week, where I gave a paper that touched on this topic. This is "work in progress" so it will be a while before I can publish a detailed paper. >7. Interpret auto-correllation between packets from/to and/or >same src/dst in a sensible fashion... I suppose this depends on one's definition of "sensible", but I've seen a few papers on this. For example, Mark J. Lorence and M. Satyanarayanan, "IPwatch: A Tool For Monitoring Network Locality", Operating Systems Review 24:1 (January 1990). These all seem to be fertile areas for research, as Jon has pointed out. -Jeff