[ih] inter-network communication history

[Craig Partridge]

Hi John:

Thanks for the nice words about HEMS!

It is hard to make the assessment of which would have been more simpler and
smaller now, some 30 years later, but since this list is about rethinking
and understanding the past I'll take a swing at it.

Both HEMS and SNMP had similar MIB structures -- a named tree with data
formatted in ASN.1.  Both would have required similar amounts of software
to locate, manage, and configure MIB variables.  Not surprising as SNMP was
designed to be a stripped down HEMS.  So the issue is how much the features
that SNMP stripped out of HEMS came back to bite the SNMP implementers.
Clearly proxies, which HEMS handled seamlessly, required more code in
SNMP.  Also HEMS handled private MIBs seamlessly (you just added your
private variables to the MIB -- HEMS leveraged ASN.1 to make those
variables self-describing), while incorporating private MIB definitions is
a continuing pain for SNMP management stations.  But HEMS had a (simple)
language interpreter that SNMP did not and a much richer system for traps.
In the balance, I'd guess management station code for SNMP would be bigger
and more complex and that SNMP on the managed device would be about equal
except for the simplest of devices (where SNMP would win).  Your mileage
may vary.

Thanks!

Craig

On Fri, Nov 8, 2019 at 8:00 AM John Day <jeanjour at comcast.net> wrote:

> And from what I understand, the HEMS implementation turned out to be
> simpler and smaller than the SNMP implementation.
>
> > On Nov 8, 2019, at 09:56, Craig Partridge via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > Hi Jack:
> >
> > You're crossing network management streams.
> >
> > SNMP had nothing to do with NMP except, perhaps, some influences on Marty
> > Schoffstall.  You are probably thinking of HMP (Host Management
> Protocol).
> >
> > Around 1983, network management work at BBN started going down two paths.
> > One was the stuff that Hinden's team was doing for the NOC.  The other
> was
> > Jil Wescott's distributed network management system (I think called
> NOMS?)
> > with Charlie Lynn and I think Ross Callon and Karen Seo and, briefly me,
> > working on it.  Then DCA funded a large project (name I've forgotten)
> > trying to build a better suite of tools (but not protocols as I recall)
> for
> > the MILNET NOC. That work never made it out of BBN.
> >
> > In 1987, NSF realized the cupboard for multi-vendor network management
> > protocols was bare.  Steve Wolff asked me to come up with a solution,
> which
> > become HEMS and was based on my experience with NOMS and discussions at
> > IETF and some great ideas from Glenn Trewitt (who had been dealing with
> > Stanford's substantial internet).  Jeff Case and Marty Schoffstall (and
> > others) felt HEMS was too complex to deploy ASAP (and ASAP was the need
> --
> > NSFNET was growing like topsy) and devised SGMP (Simple Gateway
> Management
> > Protocol) which the IETF then evolved into SNMP.
> >
> > Thanks!
> >
> > Craig
> >
> >
> > On Thu, Nov 7, 2019 at 4:33 PM Jack Haverty via Internet-history <
> > internet-history at elists.isoc.org> wrote:
> >
> >> On 11/7/19 1:35 PM, Vint Cerf wrote:
> >>
> >>> Don't forget CMIP, HEMS AND SNMP
> >>
> >> Hmmm.   Well, what I remember is:
> >>
> >> SNMP was instantiated as a first step toward a comprehensive NMP
> >> (Network Management Protocol).   As I recall, NMP was more of a concept
> >> than a protocol.  It was an umbrella covering a lot of pieces.
> >>
> >> As we were struggling to make the Internet 24x7, we did a lot of
> >> cogitating about what it meant to manage a network, which went well
> >> beyond basic real-time monitoring and control.   In addition to the
> >> Internet "core gateways", at BBN we were managing and/or operating a
> >> variety of networks, so we had a fairly broad view of the issues that
> >> crop as you operate and evolve networks over 5 or 10 years.
> >>
> >> One dimension of that exploration was into life-cycle management.  That
> >> involved things like how to measure traffic statistics and patterns,
> >> identify and predict trends, plan for topology alterations to handle
> >> future traffic, plan for changes needed to add new users or
> >> applications, etc.
> >>
> >> It also included operational disturbances.  How do you deploy a new
> >> major software release without disrupting users' activities?  How do you
> >> add a large number of new users with a new application without
> >> disrupting current activity?   How do you debug problems, without
> >> disrupting other users?
> >>
> >> In the DDN context, a memorable one of those was the release of a major
> >> new IMP version.  To make that run smoothly, we had to create a lot of
> >> mechanisms and processes even beyond those needed within the IMPs
> >> themselves to smoothly convert to the new release.  E.G., we created a
> >> service product called "TestNet" which allowed systems integrators to
> >> test and debug their software in the new environment via a dial-up link
> >> and get it all running smoothly before going live in the users'
> >> environment.
> >>
> >> I recall one motivation for that was some Army system -- the one that
> >> provided payroll services and issued the soldiers' checks.  If it didn't
> >> work the week after the software transition.... well, those guys have
> >> some serious capability to protest such disrespect.
> >>
> >> At one point an ARPANET clone was involved in the systems that are used
> >> by the officers at points of entry into the US.  When something was
> >> wrong... well, it seemed like having a BBN identifier on your paperwork
> >> made you much more likely to be randomly selected for extra scrutiny at
> >> the airport.
> >>
> >> Another dimension of network management was into management of resources
> >> - i.e., respecting the "boundaries" Dave mentioned.  This came up in the
> >> context of SATNET and the VAN Gateway (ARPANET connected to the public
> >> X.25 world).   Whoever owned something, and paid for its operation,
> >> wanted it used for their purposes only.   So ARPA research traffic could
> >> use SATNET, but other stuff should use the X.25 service (and getting the
> >> bill to go to the right place depended on quirky details like which side
> >> "dialed the phone" to establish the X.25 connection between gateways.)
> >> In the technical environment, this requirement appeared as "policy
> >> routing" and related technologies, protocols, etc.
> >>
> >> Resource management extended into the security world as well, i.e.,
> >> making sure that only authorized "people" (humans, computers, software,
> >> whatever) were able to access only the appropriate resources.   It also
> >> impacted functionality like TOS - how do you make traffic go down the
> >> most appropriate path for the kind of service it required.
> >>
> >> All of that kind of "management" was folded under "Network Management".
> >> It was, and is, a huge area.   It went far beyond the basic
> >> monitoring/control of SNMP.  But to get something quickly for the
> >> network we were trying to operate, SNMP was created.
> >>
> >> SNMP was Simple Network Management Protocol.  I remember we had
> >> discussions about exactly which noun the adjective "Simple" was
> >> modifying.   My thought was that it really should have been Simple
> >> Protocol for Simple Management of Simple Networks - i.e., SPSMSN or
> >> something like that.
> >>
> >> Anyway, SNMP was an "interim" solution while the larger issues were
> >> sorted out.  I recall that Bob Kahn and I circa 1983 initiated a new
> >> project area called "Automated Network Management" where we would
> >> explore the more esoteric resource management ideas aligned with ARPA's
> >> charter.  We also put together (got funded) projects from several of the
> >> various "operational" clients we had, who were pretty desperate for
> >> near-term pragmatic tools to help them manage their own stuff (those
> >> research guys never write the Users' Manual!).   All of that combined
> >> would make a foundation project for further NMP development.
> >>
> >> Sometime in late 1983, I lost track of the "NMP" work.   BBN reorganized
> >> and those various projects and contracts ended up scattered around to
> >> different divisions after the upheavals settled.  I think that
> >> separation of the  "research" and "operational" worlds might have had a
> >> noticeable effect on the history of the Internet, by breaking the
> >> "pipeline" from research to operations that Vint started when he moved
> >> the gateways to become 24x7 services.
> >>
> >> I don't know anything about HEMS.  It may be what later came out of the
> >> Automated Network Management project as a protocol part of NMP, but I'm
> >> not sure if it ever got deployed or transitioned and used in any of the
> >> operational network environments.
> >>
> >> I know even less about CMIP.  I could never get my teeth into ISO
> >> technology.  There wasn't any code to play with, and every time I tried
> >> to read those stacks of documents I'd fall asleep.
> >>
> >> Fun times though,
> >>
> >> /Jack Haverty
> >>
> >>
> >>
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org
> >> https://elists.isoc.org/mailman/listinfo/internet-history
> >>
> >
> >
> > --
> > *****
> > Craig Partridge's email account for professional society activities and
> > mailing lists.
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > https://elists.isoc.org/mailman/listinfo/internet-history
>
>

-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20191108/750ce8f8/attachment.htm>