[ih] Fwd: Internet at Sea

[Jack Haverty]

That DTIC reference I posted is a Mitre study of the history of the 
Defense Simulation Internet (DSI).  It gives a lot of details about the 
system (as of the late 1990s when the report was written), and describes 
the transition from the initial system into the "Phase II" system in use 
at the time.  I haven't found anything about the years after the 1990s, 
so there's a lot of history missing.

When I was involved in the early 1980s, the near-term goal was to 
provide a state-of-the-art, but affordable, system for training. The 
longer-term vision was that the training system might evolve into one 
suitable for use in actual field exercises and even combat.   E.g., I've 
heard recently that operators in the US are piloting drones halfway 
around the world, but haven't heard anything about how whatever system 
they use is designed to enable that kind of tele-operation.

COTS was a big goal even in the 1980s.  The DoD was tired of paying for 
custom solutions and also reluctant to choose proprietary approaches 
that would lock in a particular vendor.   Corporate moguls preferred 
proprietary approaches that built walls to prevent customers from 
escaping.  But of course the DoD was only one customer, so corporations' 
marketing didn't pay as much attention as they might, at least in the 
early days of networking.

It sounds like your advice and other pressures eventually got Cisco 
involved and replaced the initial BBN solution.  I can't tell though 
whether or not that technology has propagated throughout the regular 
public Internet world, e.g., for use in gaming, tele-operation, 
teleconferencing, and such applications outside of whatever the current 
DSI looks like.   For example, do the current popular video conferencing 
"silos" use, or rely on, those standards that DSI uses?  The fact that 
something is labelled "standard" no longer means it's necessarily 
broadly implemented.

That 1998 report says in part:

"The old DSI (Phase I) wide area network (WAN) consisted of out-dated 
equipment such as Bolt
Beranek and Newman (BBN) T/20 routers and proprietary implementations of 
the Streams
Protocol, Version II (ST II). The modernized Phase II DSI replaced these 
with state of the
art equipment and standards-based commercial products.
...
Each backbone node is connected to several site nodes. There are a total 
of 46 tail sites at
the present time. Each site node has a Cisco 7204 router with a serial 
Tl (1.54 Mbps) link to
its backbone node. As an example, the configuration of one site (the 
Joint Precision Strike
Demonstration (JPSD) site at Fort Huachuca, Arizona) is shown in Figure 
3. We will also
describe this configuration below.
Typically, a site router has one serial port and four Ethernet ports. 
One Ethernet interface
is assigned a class C Internet Protocol (IP) address range for 
unclassified simulations. A
single host IP address is available for desktop VTC (DVTC) via a second 
Ethernet interface.
A third Ethernet segment connects to a port of the Improved Network 
Encryption System
(INES) box built by the Motorola Corporation. This box helps in 
providing secure
simulations and secure DVTC. Again, there is a complete class C IP 
address range for secure
simulations and a single IP host address for secure DVTC. The simulation 
Local Area
Network (LAN) and the DVTC LAN are connected to two Ethernet ports of a 
Cisco 4500
router on the red side (classified side). The maximum throughput from 
the INES is about 1.2
Mbps in both directions (combined) and is achieved by sending large 
packets (1400 Byte
packets) through the INES. For smaller packets, the throughput is much 
smaller. To
overcome this limitation, an aggregator box (which is a Personal 
Computer (PC) with a
Pentium processor running on Free Berkeley System Distribution (BSD) 
operating system)
connects to a third Ethernet interface of the Cisco 4500 router and an 
INES port (see Figure
3). Multicast traffic from the red side is packaged by the aggregator 
into larger packets and is
shipped to the network via its black site router. Similarly multicast 
traffic destined for the red
side is deaggregated and forwarded to the simulation LAN.
...
The DSI phase II network supports standards-based protocols such as RSVP 
and H.320
VTC. In addition, the DSI network supports IP multicasting, link-state 
routing, secure and
non-secure distributed simulations, and the usual internet and intranet 
applications such as file
transfer, e-mail, telnet, and web-browsing."

Jack Haverty


On 10/8/25 11:47, Barbara Denny via Internet-history wrote:
>   Trimming the message.  I am back to not having much luck in getting my messages posted.
> I remember hearing a little bit about the Defense Simulation INternet.  I didn't know the size of this network. I think I thought of it more like a testbed so probably not very large.
> I may have a different perspective with what the military, or at least some part of the army, wanted to have happen in the late 80s/early 90s?.  I don't think they were that interested putting effort/money in a private system that couldn't be created from COTS products.  They also wanted to create RFCs.
> Here are a couple examples.
> Quite some time ago I mentioned on this list they didn't like IGMP.  They wanted control of group membership.  This wasn't available so I gave them what I call a hack for doing this.  I explicitly told them it should only be used for this demonstration just to get them through it. They should work on getting a better solution.  Much to my display they wrote up the approach in a RFC without telling me about it.
> Another thing they wanted was RSVP in a commercial router. If I remember right, RSVP was not really getting implemented in routers.  I ended up having meetings with Cisco and WellFleet (maybe Wellfleet was Bay at this point in time) to try to get them interested in implementing the protocol.  Wellfleet seemed  interested in pursuing the discussion. My impression was Cisco was not that interested.  (The number of routers that the army said they would probably purchase immediately was not large enough. Cisco was a lot bigger by then.)  I don't think I talked to Proteon or 3com.  I think in the case of Proteon I was having trouble with a getting a good  POC.  For 3com I didn't realize they had a router at the time. I don't know who, if anyone, implemented RSVP as a result of these discussions.
> I also don't have any knowledge about where the wanted to use the technology. The work was probably done under a task ordering agreement SRI had with CECOM.  I only spent a brief amount of time on each task.
> barbara
>      On Tuesday, October 7, 2025 at 01:52:47 PM PDT, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
>   
>   Defense Simulation Internet -- that's it, I couldn't remember the name.
>
> Quick search uncovers this MITRE study with some technical info:
>
> https://apps.dtic.mil/sti/tr/pdf/ADA381147.pdf
>
> /Jack
>
>
> On 10/7/25 12:54, Craig Partridge wrote:
>> As I recall it was called the Defense Simulation INternet (DSIN) or
>> something close and was carefully engineered to have enough capacity
>> to link the various simulators.  It made heavy use of UDP.
>>
>> Couple of quick comments (some of my college classmates were the core
>> of the initial implementation team, but I was not on the team, so some
>> details may be not quite right) about the networking aspects.
>>
>> Both network bandwidth and the number of messages was at a premium and
>> the team figured this out quite quickly.  They were working initially
>> with the 1983-vintage Internet, with no working congestion control and
>> where effective Ethernet speed was about 1Mbps due to network adapter
>> limitations and Unix kernel limitations.
>>
>> They had, initially, an n*n comms pattern, every "thing" in the
>> simulated space was tracking what every other "thing" was doing to
>> ensure everyone had a faithful representation of the world.  Each node
>> drove its own graphics displays (and there were multiple per tank).
>> You didn't have to get too many tanks, plus shells and other moving
>> things, and the network saturated if you sent out an update on every
>> action.
>>
>> So what they did was develop predictive algorithms for each item.  For
>> instance, if a tank was speeding along, the algorithm predicted it
>> would continue along its current path and the tank only sent an update
>> when it deviated from the predicted path.  Each node was, therefore,
>> calculating what it thought each item in the space was doing and
>> looking for occasional updates.  This sharply reduced network traffic
>> and made performance quite good -- and this is the core of the
>> simulation protocols that were developed in the late 1980s and early
>> 1990s.
>>
>> There were some early hiccoughs.  There's an art to figuring out how
>> often to update and soldiers (who were getting to play the world's
>> best video game in high end tank simulators) were quick to figure out
>> glitches and take advantage.  As I recall, one trick was to drive your
>> tank at maximum speed (something like 60 mph) crosswise in front of
>> your opponent's tank with your gun pointing ahead -- so they think
>> you're an unsuspecting target but also have to line up a shot on a
>> fast moving object.   Then, just before you estimate your opponent has
>> got their shot ready, you stomp on the brakes and turn your turret
>> towards them and fire.  What the opponent would see is your tank
>> magically jump backwards and shoot at them.
>>
>> Side story: as I understand the politics of simulation, the SIMNET
>> project had a number of challenges getting the various contractors to
>> play nicely.  I think BBN finally ended up buying the specialized
>> graphics display company to reduce friction.  But what made SIMNET a
>> big success was the NATO Tank Competition.  The US Army historically
>> did poorly -- someone (the SIMNET PM?), in a stroke of marketing
>> genius, had SIMNET code the tank course into the simulator and let the
>> Army team practice on it.  The US won the competition....
>>
>> Craig
>>
>>
>>
>> On Tue, Oct 7, 2025 at 1:26 PM Jack Haverty via Internet-history
>> <internet-history at elists.isoc.org> wrote:
>>
>>      Answering Barbara's questions...
>>
>>      A few years ago, someone who had worked on SIMNET told me that
>>      they had
>>      chosen to use a private network approach rather than running over The
>>      Internet which was shared with others.   I don't know any of the
>>      details
>>      though.
>>
>>      My suspicion is that they built a private clone of the Internet,
>>      using
>>      TCP/IP routers, and circuits.  Lots of corporations were deploying
>>      similar private clones for use within their corporation and possibly
>>      some partners.
>>
>>      For a particular project, a private "intranet" could be carefully
>>      managed to meet the needs for gaming, perhaps using the methodology
>>      learned from the ARPANET.
>>
>>      The ARPANET had a team of analysts who looked at traffic
>>      statistics and
>>      trends, and designed changes to the ARPANET, e.g., to add or remove
>>      circuits, order higher bancwith, modify protocols, etc. That same
>>      philosophy could be applied to a private Internet, to maintain needed
>>      and consistent performance for a specific application.
>>
>>      In addition, with all of the switches and computers involved in the
>>      project under the project's control, customized approaches could be
>>      designed and implemented.  Corporations couldn't really do that
>>      when all
>>      their routers came from Cisco, but a military project such as SIMNET
>>      could; perhaps they implemented some TOS functionality, or something
>>      else to address the latency requirements.  With a private system,
>>      even
>>      based on TCP/IP, you could do that.
>>
>>      Coordinating with the "public" Internet, funding research on general
>>      solutions and implementations, and getting new mechanisms into the
>>      Standards Process was not needed for the project to be successful. A
>>      project-specific solution was sufficient.
>>
>>      But I don't know any of the actual details about how the SIMNET
>>      communications worked.   So the above is just speculation.  I suspect
>>      the details are in reports somewhere in DTIC.
>>
>>      /Jack
>
>
>
>
>
>    

-------------- 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/20251008/3febd3b3/attachment-0001.asc>