[ih] Nit-picking an origin story

[Jack Haverty]

It's been a long time, but I vaguely remember experiences like you 
describe.   While I was at MIT working on email circa 1975, I remember 
struggling to get emails back and forth quickly to the Datacomputer, 
which was literally in the building next door.  The ARPANET speed was a 
real limiting factor.

Routing used transit time as the metric for "shortest", which included 
time spent in queues.  So as traffic increased on "the path", the time 
to traverse that path increased, and routing would then switch to an 
alternate path.  The destination IMP of course had to put it all back 
together for delivery to the host.

It could certainly be possible to get more than 56 kb/sec between two 
hosts if there were alternate paths available of similar timing.  But it 
also seriously stressed the IMPs, which had to constantly set up and 
tear down their internal end-end mechanisms as the routes changed.  The 
IMP internals changed quite a bit over the years, as the IMPs complained 
loudly to the NOC about such abuse.

The research work circa 1980 was to find a better way, with the 
experience of 10 years of ARPANET operation and the emergence of DDN.

I forgot to mention -- that "Improvements" report I mentioned has a 
discussion of similar issues in gateways and Internet, which had 
surfaced through operational experience with the early gateways using 
the ARPANET.   It's in Chapter 7.

/Jack

On 8/19/25 14:17, vinton cerf wrote:
> Even back in the 1970-1972 period, some of my experiments with Bob 
> Kahn showed that the ARPANET IMPs were capable of adaptive alternate 
> routing so that I was able to inject about 80 kb/s of traffic from 
> UCLA destined for SRI that switched between a direct route and an 
> indirect one through Santa Barbara even though the direct and indirect 
> paths had at most 50 kb/s each.
>
> v
>
>
> On Tue, Aug 19, 2025 at 4:50 PM Jack Haverty via Internet-history 
> <internet-history at elists.isoc.org> wrote:
>
>     On 8/18/25 07:00, John Day via Internet-history wrote:
>     > This last one I think doesn’t get enough credit. It is a very
>     small thing, but I think was a major contribution to the success
>     of the ARPANET. It would have worked at 2.4 or 9.6, but been so
>     glacially slow as to have been considered not successful. At
>     50Kbps, we could do real work that was way beyond what people
>     expected. Not to take anything away from the great software
>     development that went into the IMPs and the NCPs, etc. I really
>     think this gets too little credit for the success.
>     Performance was also an issue as the ARPANET grew and traffic
>     increased.  One of the limiting factors to performance was the
>     routing
>     algorithm.   Packets were always sent on the "shortest" path.  
>     But that
>     meant that the aggregate performance was also limited to 56kb/sec,
>     which
>     was the maximum line speed of any path. Even after there were
>     multiple
>     possible routes across the US, routing would typically only
>     utilize one
>     path, whichever was shortest at the time.
>
>     There was a lot of analysis, simulation, and testing done over the
>     80s
>     as the IMP's internal algorithms were improved.  One ot the
>     targets was
>     "multipath routing", which meant figuring out a way to use more than
>     just the shortest path between two IMPs and their attached host
>     computers.  That would enable hosts to get more than 56KB/sec
>     throughput
>     across the 'net, as well as improve the overall efficiency of use
>     of the
>     expensive longhaul circuits.
>
>     Such issues were also present in the Internet of course.  A similar
>     desire existed to be able to use more than one path through the
>     Internet.  The ICCB's "To Do List" contained items such as "Multipath
>     Routing" and "Expressway Routing" in the early 1980s. But there
>     couldn't
>     be much progress on that since the Internet routing, at that time,
>     didn't have any real notion of "shortest path", but used the simple
>     metric of "hop counts" as an interim metric for decisions on datagram
>     routes.
>
>     Most people likely haven't seen much info about the internal
>     algorithms
>     used inside the ARPANET, which were captured in reports to the
>     government sponsors but not so much in RFCs et al.
>
>     There's some large reports on the "ARPANET Routing Improvements" work
>     done circa 1980.  One of the reports is online in PDF form at
>     https://apps.dtic.mil/sti/html/tr/ADA121350/index.html Others are
>     probably online in DTIC as well, for any historians interested in the
>     inner workings of the ARPANET and how it evolved over its lifetime.
>
>     Jack Haverty
>     -- 
>     Internet-history mailing list
>     Internet-history at elists.isoc.org
>     https://elists.isoc.org/mailman/listinfo/internet-history
>     -
>     Unsubscribe:
>     https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=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/20250819/80ca92e9/attachment-0001.asc>