[ih] Monitoring, Operating, Controlling ...

[Miles Fidelman]

the keyboard of geoff goodfellow via Internet-history wrote:
> beggin' your pardon Alex, but IIRC, the ARPANET was
> managed by what was called Network Control Center (NCC)
> not Network Operations Center (NOC), viz.:
> https://www.rfc-editor.org/rfc/rfc356.txt
> https://www.beylebooks.com/read/the-arpanet-network-control-center-program
> with a host named BBN-NCC, viz.:
> http://www.faqs.org/rfcs/rfc289.html
> in addition to there also being the NCC-TIP, viz.:
> https://www.rfc-editor.org/rfc/rfc619.html
>
> geoff
>
> On Sun, Apr 3, 2022 at 9:51 AM Alex McKenzie via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>>   Indeed, a better name for the ARPAnet center at BBN would have been the
>> Network Monitoring Center.  We didn't pick that name because the acronym
>> NMC was already taken by the Network Measurement Center at UCLA.
>> Eventually we switched to the name Network Operations Center which I think
>> better described the function.
>> Cheers,Alex
>>
>>      On Saturday, April 2, 2022, 09:19:57 PM EDT, John Day via
>> Internet-history <internet-history at elists.isoc.org> wrote:
>>
>>   Thanks,
>>
>> I can see that it is an argument for it. Pretty weak in my estimation, but
>> it seems to misunderstand the problem.
>> Given that was at the height of the silly ‘everything has to be
>> connectionless’ fad, I am sure that had a lot to do with it too. With the
>> overhead of BER that didn’t leave a lot of room for much useful in the
>> packet.
>>
>> So you send a flurry of UDP packets and some get through and you hope that
>> the ones that do are useful.  Doesn’t sound great. Now if this flurry is
>> commands to agents, the likelihood of random commands arriving in some
>> order sounds more dangerous than useful. It could easily make a bad
>> situation worse. If they are responses, then the manager is getting bits
>> and pieces of information (and small ones at that) and trying to assemble
>> some sort of picture of what is going on.
>>
>> GetNext was a pretty lame excuse for being able to retrieve a large
>> structure in one operation. Sure it generated more than 2 packets but
>> considerably less than GetNext would require and the Get/Read would be a
>> snapshot, where with GetNext the information could change out from under
>> you.
>>
>> Let me tell a story:
>> In the 70s and early 80s, this was called network control. Starting with
>> the ARPANET, I was always a firm believer that management was more
>> appropriate, that events in the network were happening too fast for a human
>> in the loop. The most one could do was *manage* it. To capture that, by
>> 1984 I had adopted the phrase, “Monitor and Repair, but not Control.”
>>
>>
Interesting use of words.  In the military, Command & Control is usually 
NOT considered real-time, while "Battle Management" is the term of art 
for the real-time activity.  (Unless things have changed recently.)

When it comes to the ARPANET, and the DDN - "monitor & repair" was very 
much the operating model for the NOCs.  At the same time, "control" took 
the form of performance tuning and other such not-quite-real-time 
configuration activities.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown