[ih] History of Naming on The Internet - is it still relevant?

[Jack Haverty]

My personal opinion is that networks, and technology in general, has 
often oversimplified its various "interfaces".  It's human nature to 
seek simplicity.

Einstein once opined (I'm paraphrasing) that "Everything should be as 
simple as possible.  But not simpler."

I still vaguely recall some discussions that happened about 45 years 
ago.   I can't remember who was there, but it was probably at some hotel 
bar or chinese restaurant after a long day of arguments about what 
should be in the "new" IP header.  This occurred when TCP2.5 was being 
morphed into TCP/IP4.   The contents of the IP header were essentially 
the "API" to The Internet.

At the time, more than a decade before the Web and personal computers, 
workstations, and phones proliferated, usage of the ARPANET was 
dominated by interactive terminal traffic (Telnet) and bulk transfers 
(FTP).   The Internet, i.e., the set of computers exploring TCP, was 
still largely experimental, with few "real users".

Interactive usage demanded low latency.   You really wanted to see the 
characters echo as you typed them.  The ARPANET was carefully managed to 
achieve a latency of no more than 250 milliseconds.  That was 
considered, by psychologists, to be what humans could tolerate for 
interacting with a computer.

The ARPANET switching fabric (IMPs and its algorithms) had mechanisms to 
restrict traffic flows when necessary.  That even included hardware 
mechanisms such as stopping data flow from an attached user's computer 
when necessary to protect the overall network and provide the required 
level of service.

Bulk traffic usage, such as transferring large files, didn't need low 
latency.  So it could fit into the gaps and use network resources when 
they weren't needed for the interactive traffic. There was considerable 
research, analysis, modelling, and evolution of the internal algorithms 
used within the ARPANET, especially over the 1970s and early 1980s, to 
serve both interactive and bulk usage as the network grew and evolved 
into the Defense Data Network.

In addition, we knew about the older military communications systems 
that our research was intended to replace.  Autodin was the existing 
system at the time, and its interface incorporated concepts such as 
"precedence", which enabled Autodin to focus its resources on the most 
important user traffic.   Your use of the network could be 
unceremoniously aborted if a higher priority usage needed the network 
resources.  A summary of that era is available at 
https://archive.org/details/DTIC_ADA071729

That technology of the 1960s had evolved from the earlier days of 
telephony.  Circuits were actual physical wires linked together to allow 
two devices to communicate, with latency dictated by the physics of 
electrical signals.  If there were insufficient resources (wires) 
available to establish your connection, you would hear a "busy signal" 
and have to try later

The new concept of "packet switching" enabled the introduction of 
"virtual circuits", which behaved more or less like actual physical 
circuits.

But virtual circuits are not the same as physical circuits, especially 
as resources become scarce.

As we debated the contents of the new IP header, there were lots of 
ideas about what should be included.  But there was also reluctance to 
make the header become so large that it became the dominant fraction of 
overall network traffic.   Some things were eventually decided to be 
included in the IP header - such as addresses.  Other things were deemed 
useful, but would be included as "options", using the new format for 
adding extra stuff to the IP header.

Some techniques from the older systems weren't possible in the new world 
of The Internet.  Much of the "virtual circuit" mechanism was now to be 
implementd in the users' computers, rather than in the network switches 
as had been done in Autodin and ARPANET.  So techniques for "congestion 
control", "precedence", and network management tools were relegated to 
IP options or ancillary protocols such as ICMP, XNET, et al.   There was 
no longer a way for a "switch" (router) to use a hardware mechanism to 
give a "busy signal" to a user's computer.

There were many unanswered questions.  But the DoD was insistent on 
establishing a Standard.  We didn't know how to provide some functions 
within the IP API (IP header).   There were many ideas, but none had 
been implemented or vetted to reach "rough consensus and running code".

As one example, we "knew" that there would be different kinds of usage 
of The Internet.   In addition to the then common bulk and interactive 
use, lots of experimentation was happening with interactive voice and an 
aspiration for video even when it became feasible.   So the TOS field 
was defined - Type Of Service.   We didn't know what the various types 
of service should be, or how to make the Internet treat them 
differently.   Including the TOS field in the IP header would enable 
that research to continue.

We also "knew" that some kind of back pressure would be useful to 
restrict traffic flows into The Internet.   Hardware mechanisms, and 
techniques such as the RFNMs used in the ARPANET, were not thought to be 
feasible.  So we put in the "Source Quench" mechanism, in expectation 
that it would be quickly replaced by something better.

With lots of meetings, debates, arguments, discussions, as well as kung 
pao and beer, IPV4 came into focus.  Jon Postel wrote up the spec.   DoD 
declared it a Standard.  Continued research would replace the 
"placeholder" mechanisms with more appropriate ones, as soon as someone 
figured out what they should be.

Interfaces are important, and should be simple.

Everything should be as simple as possible.

But not simpler than possible.

I don't think we're there yet.

Jack Haverty






-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250814/f1c5018a/attachment.asc>