[ih] TCP RTT Estimator

Jack Haverty jack at 3kitty.org
Mon Apr 14 17:41:25 PDT 2025


The US DoD was (is still?) complicated and diverse.  The US DoD may have 
"sent someone" to meetings but it's difficult to tell what the mission 
was (influence?  observe?  learn?), or which piece of the DoD sent him 
or her.  During the 1980s, the ascendance of TCP was not guaranteed, 
even though it was a "DoD Standard".

For example, there was a sizable contingent within DoD that was 
committed to OSI (search for GOSIP), and viewed TCP at best as an 
interim step along the way there.   In 1990, OSI was even declared as a 
Standard, not just for DoD but for the entire US government. See 
https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub146-1.pdf

Personally, I lost track of DoD networking when I migrated to Silicon 
Valley in 1990.  I've always wondered just what happened to DoD 
networking over the last 35 years.  Do today's military systems use TCP 
(V4? V6?) over a secured private military Internet?  Or over the public 
Internet?  Or use some other technology over their own secured fiber, 
circuits, and satellites?

During the 1980s, there was a lot of concern in DoD about use of 
"public" systems such as the ARPANET or neonatal Internet.  But it was 
straightforward for agencies and departments to procure their own 
systems, at first using IMPs from BBN and routers from Cisco. We helped 
quite a few such networks get to operational status.  It was quite 
common even in 1990 for corporations to build out their own private 
"intranets", using off-the-shelf circuits and routers. For example, I 
consulted in the late 1980s to one major Wall Street firm on their 
private intranet connecting London, New York, and Tokyo.   In 1990 I was 
involved in running a private corporate intranet connecting corporate 
offices in 100+ countries.

After 1990, I have no data about the evolution of the DoD network 
world.  But I still recall some of the military scenarios which Vint 
outlined as goals for the Internet research as TCP V4 was being created 
a decade earlier.  Those scenarios motivated the introduction of UDP, 
and the splitting of TCP into TCP/IP, in order to provide a pathway for 
support of real-time interactive activities, such as coordinated 
conversational voice and graphics, across the military environment.

Is that how the DoD networking works today in military operations? Or 
perhaps TCP has been replaced by other technologies?  Signal?

Jack Haverty


On 4/14/25 17:03, vinton cerf wrote:
> one possible explanation: the preparation of the MIL-STD was in 
> parallel with further developments and just didn't take them into 
> account.
>
> v
>
>
> On Mon, Apr 14, 2025 at 7:22 PM Greg Skinner via Internet-history 
> <internet-history at elists.isoc.org> wrote:
>
>     On Apr 12, 2025, at 11:33 AM, Jack Haverty via Internet-history
>     <internet-history at elists.isoc.org> wrote:
>     >
>     > The 1980s era of The Internet was explicitly a time of research
>     and the "Internet Experiment".    We tried to reflect that in the
>     documents of the day, such as RFC793.
>     >
>     > The general principle was that the "on the wire" formats and
>     meanings were standardized, so that any implementation of TCP
>     could communicate with any other implementation. Everything else
>     was at best Recommendations.
>     >
>     > However, there were a lot of unanswered questions, such as the
>     best way to deal with network errors such as dropped, duplicated,
>     or mangled datagrams - such as discussed in IEN69.
>     >
>     > To enable research into different techniques, the specific
>     algorithms for TCP functions such as retransmission timers and
>     strategies were explicitly *not* standardized. That encouraged
>     experimentation with different kinds of network environments and
>     different ideas about how to cope with errors.   It also permitted
>     implementations of TCP with different goals.  An implementer might
>     pursue algorithms which minimized the load on their computer
>     system.  Or load on the network.   Or rapidity of implementation.
>     Or suitability for the specific user environment involved.  Or ...
>     >
>     > No one in 1981 had any significant experience with real-world
>     TCP networks and their behavior under heavy loads.  The ARPANET
>     was the basic wide-area network in use as the substrate for The
>     Internet, and the ARPANET provided only a reliable byte-stream
>     service that made greatly simplified TCP's task.
>     >
>     > IEN 177 says that the RSRE algorithm is the "current best
>     procedure" and "will be included in the next ... specification". 
>     I remember talking with Jon and others about this.  My
>     recollection is that such an algorithm might be included as a
>     "best practice" recommendation, not as a mandatory part of the
>     standard.  In 1981 we simply didn't know enough to nail down an
>     algorithm and there were lots of other outstanding unresolved
>     issues that might be related (such as Type Of Service, Policy
>     Routing, etc.).
>     >
>     > In 1981, The Internet was still very much an Experiment, but
>     being pulled forward by its adoption as a DoD Standard, and later
>     to be rocketed forward by its adoption in non-military
>     networking.   I think many of those research questions were never
>     answered.  I recall we even at one point we even opined that The
>     Internet would be fine as long as we kept enough capacity in the
>     circuits and switches to avoid overloads, while the research
>     continued, seeking the "right" answers.
>     >
>     > Jack Haverty
>
>     OK, that seems reasonable.  I did a little more digging, and found
>     that IEN 50 provides some “glue” by comparing some retransmission
>     algorithms, using simulations and analytical techniques to arrive
>     at some conclusions. [1]  It seems unfortunate to me that some of
>     these IENs couldn’t have been included as references in RFC 793. 
>     But as far as supporting (higher packet loss) military networking
>     went, some of these concerns (in theory) could have been addressed
>     in MIL-STD-1778 [2].  Does anyone know why they weren’t? The US
>     DoD sent people to those Internet Meetings from the late 1970s and
>     early 1980s, so (in theory) they had enough information to
>     incorporate any additional requirements into the military standard
>     for TCP.
>
>     --gregbo
>
>     [1] https://www.rfc-editor.org/ien/scanned/ien50.pdf
>     [2] http://everyspec.com/MIL-STD/MIL-STD-1700-1799/MIL-STD-1778_6676/
>     -- 
>     Internet-history mailing list
>     Internet-history at elists.isoc.org
>     https://elists.isoc.org/mailman/listinfo/internet-history
>

-------------- 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/20250414/c6a05d19/attachment-0001.asc>


More information about the Internet-history mailing list