[ih] inter-network communication history

[John Day]

Snip

> 
> RFC1109 also identified a key missing piece:
> 
> "It was acknowledged that the present service interfaces of both SNMP
> and CMIS have limitations (e.g., neither has any sense of time other
> than "now"; this makes it impossible to express queries for historical
> information, or to issue command requests of the form: Do X at device Y,
> beginning in 30 minutes)”

Things like that belong in the object models.  That is why there was an Action in CMIP. (I would have preferred limiting it Start and Stop.) Or the Manager schedules it and sends the Do X in 30 minutes.  Not everything has to be in the protocol.

This is something I have looked at several times.  If you do the fundamental operators: Create/Delete, Read/Write, and Start/Stop. It is to some degree too rudimentary and you have what I call the "Turing Machine problem," i.e. you can do it but it is like using a Turing Machine to do it.  This was SNMP’s biggest problem. Not only was it a Turing Machine, but it had severe limits on each “action” imposed by UDP.  The problem turns out to be there doesn’t seem to be any half-way point. You either do the minimum or you have a full blown programming language.  In that case, the protocol may as well download a script and start it. It would be more efficient than trying to do the language over a connection.

The one thing that CMIP had that did save a lot of overhead was scope and filter.  One could say, “Set X to 0 on all (1000) objects in this part of the MIB tree with Y <  Z.” That would be one Request/Response in CMIP. It would be a lot more in SNMP.
> 
> Well, at a database company, "impossible to express queries" is a
> challenge.  When we cobbled together our adhoc management system, it
> turned out that databases are really good at handling time and queries
> for historical information, for performing actions on schedules or
> demand (see TRIGGER in database lingo, or for simple stuff just use
> cron) and for collecting and distributing data as needed.  Melding SNMP
> and a database with a little Shell-script and SQL glue was pretty
> straightforward and turned out to be very useful for managing the
> intranet.  

Correct.  MIBs were databases. That was the whole point. That is why those things were easy in HEMS and CMIP where the MIB was a database (or made to look like one) as opposed to SNMP where it wasn’t. The other thing you had to know which most people didn’t was for network management don’t use a relational database. You want either an E-R model or an object-model or one of the so-called graph models, which is a shadow of the E-R model. (Why not relational?  Network management structures have a lot of ‘bill of materials’ structures (trees). I use to argue with Bachman (who invented the E-R model. He would say you can’t do one in a relational database, and I would say, you can, but who would want to!!  ;-) It would be like writing a COBOL compiler for a Turing Machine. You can do it, but gawd I wouldn’t want to!  ;-)  I remember DEC tried relational database and went all the way back to Index-Sequential files!!  We never made the mistake but we had a new hire from MIT who had their head filled with the current fad. So we said, go try it. When we finally asked what happened with it, it turned out that in the best case, the relational database was only 19 times slower.

I should have mentioned before, OSI didn’t achieve much commonality in their MIB work. They went about it wrong. We achieved much more in the product I mentioned earlier.  Contrary to what RFC1109 says MIB structure for things below IP were quite straightforward and had a lot of commonality.

> 
> We even mused about scattering databases around the net to limit traffic
> loads by collecting high-volume SNMP data locally, and all of that
> scattered data would be automatically aggregated using standard
> distributed database techniques.  It worked for industries managing
> sales, inventory, shipments, orders, etc., so it would work for network
> data.   I'm not sure if we ever did that though.  What we did in a few
> days was enough to put out the fires.
> 
> Those observations in 1109 were very wise and accurate.  What happened
> in the thirty years since...?  A timeline/history of Network Management
> in the Internet might be fascinating - Tools, not meetings, protocols
> and documents.

Not much of anything. Most everything is home-grown tools with various sorts of hacks.

The problem that network management ran into was that the last thing vendors wanted was effective common network management.  He who controls the network management controls the account. If it is necessary to use the vendor’s network management solution, then the vendor controls the account and it is a barrier to entry.  A common effective network management solution would have made network equipment (routers, stat muxes, etc.) interchangeable. Not good.

> 
> I think somebody hit my hot button... I'll stop typing.....
> 
> /Jack
> 
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history