[ih] Source routing

Mon Feb 3 18:05:25 PST 2025

My recollections about Source Routing.   All IIRC of course:

Source Routing appeared during discussions involved in splitting TCP 
apart into separate TCP and IP components, leading to TCP/IP V4.  I 
don't think that TCP V2 had any provisions for "options".  This all 
occurred around 1979+- a year or so.

The new design was driven by a collection of military scenarios defining 
what the Internet should be able to do for military environments.

Graphical terminals were beginning to replace old hard-copy terminals.  
Computers were getting smaller and cheaper.  Ability to use new 
technology effectively was highly desirable.

One of the military scenarios involved a real-time discussion involving 
everything from observers in jeeps to commanders in field headquarters 
to generals in the Pentagon.  A map might be displayed on each 
participants screen, with discussions using voice, and everyone had use 
of light pens to point at different places on the map.   If you've used 
Zoom, that was the idea, except for today's realtime video.

At the time, the ARPANET was the "backbone" of the Internet.  It used 
mostly 56 kilobit/second circuits.  Despite a rich connectivity, no 
single path between any 2 hosts could achieve more than 56 kb/sec 
throughput.  Traffic always followed the "shortest route", and the IMPs 
had mechanisms to keep track of transit time and change routes as 
conditions changed.

At the same time, ARPA had deployed the Wideband Net, which utilized a 
satellite channel about 50 times higher capacity than the typical 
ARPANET circuit.  However, where the IMPs were connected by terrestrial 
circuits, the satellite was in geosynchronous orbit. The WBNET had much 
higher capacity than the ARPANET, but the ARPANET had much lower transit 
times, aka "latency".

To support the scenario above, the thought was that the satellite path 
might be most useful to transfer large data objects, as long as they 
didn't change frequently.  Graphical images were fine, realtime video 
was not.  The ARPANET might be useful for smaller data objects that had 
to be delivered quickly -- such as data involved in real-time 
conversations and interactions such as light pen pointing.

Unfortunately, the Internet wasn't quite up to that task.  Something had 
to be done.

-----

Unlike the ARPANET IMPs, the Gateways (routers) did not have any 
mechanisms to measure transit time, especially since they were using 
networks rather than circuits to communicate with other routers. Network 
behavior was much less predictable and stable compared to circuits.   
The routing in the Internet was based on "hops" rather than time.  We 
knew that wasn't appropriate, but it was the best available at the time.

The topology of the Internet, at the time, had connections between the 
satellite net and the ARPANET at only a few sites.  Researchers at other 
sites could still experiment with the WBNET if their datagrams would go 
through the ARPANET to a nearby WBNET site, transit the WBNET, and go 
through the ARPANET again at the other end to get to their destination.

But the routing mechanisms of the Internet weren't capable of doing 
that.  Taking the "detour" through the ARPANET to the WBNET would add 2 
hops to the route, so the routing mechanism would never choose it as the 
shortest path.

So one reason for Source Routing was to enable the researchers 
investigating that particular scenario to experiment with the use of two 
different types of networks - high capacity with high delay and 
low-capacity with low delay.  FYI, that was the same motivation for 
"Type Of Service", in order to tell the Internet what characteristics 
were needed, e.g., high capacity or low delay.  Also UDP, to provide a 
service where timely delivery was more important than eventual 
guaranteed delivery.

The expectation was that, while such experimentation was happening, the 
Internet's routing mechanisms would also evolve to provide such 
capabilities directly, and a future version of TCP/IP would no longer 
need Source Routing.

-----

Another motivation for Source Routing was for Internet operations, which 
is probably what Vint remembers.  In the ARPANET, IMPs had many tools 
and techniques that the NOC had developed over almost a decade of 
operating the ARPANET.   One of those tools was the ability for an IMP, 
anywhere in the network, to "loop" one of its circuits when commanded by 
the NOC in Massachusetts.  By looping circuits, it was possible to 
determine the cause of errors, and dispatch the appropriate service call.

IMPs were connected to each other by circuits.  Gateways (routers) were 
connected to each other by networks.  There was no way to "loop" a 
network.   At the time, I ran an ARPA project tasked to make the "core 
gateways a 24x7 reliable service".   The obvious way to do that was to 
mimic what the ARPANET NOC was doing.   Source routing was one of the 
likely tools.

Source Routing was a technique whereby errors could be remotely 
investigated and appropriate corrective actions taken.  When there were 
problems, the routing mechanisms of the Internet would route traffic to 
avoid the problem area.  Using Source Routing, the NOC could force 
traffic into "dead" interfaces, to gather data about what was happening 
that had caused the routing mechanisms to declare that pathway broken.

The IMPs in the ARPANET also had several "fake hosts" which were virtual 
hosts implemented as part of the IMP code to provide certain tools -- 
such as traffic generators.  Using traffic generators and source routing 
in the Internet, diagnostics and performance data could be gathered 
throughout the 'net, and coordinated with similar data from inside the 
ARPANET.  But I don't recall how much of that actually got used, or 
whether or not such tools and techniques were picked up by any of the 
ISPs as they proliferated.   Maybe someone else does.

-----

At the time when TCP and IP were on the operating table to be "split", 
there were lots of debates and arguments about what to put in the two 
new headers.  Size was a concern however.   Much of the traffic at the 
time was using Telnet and such datagrams often contained only a byte or 
two of user data.  Large TCP and IP headers were an embarassing 
overhead, to be minimized.

Someone made the observation that some fields which could be in the IP 
header were actually not always going to be there.  Unless the 
particular traffic flow needed a service, the associated header space 
would be wasted.  That led to the definition of "IP Options", which was 
an obvious place for things like Source Routing.  Options were possible 
in any datagram, but they weren't needed in every datagram.  They were 
"optional", if whatever you were doing needed them.

Sadly, some implementors assumed that "options" meant such technical 
mechanisms that were optional to implement.  If they didn't see a need 
for them, they sometimes just didn't implement them.  In addition, the 
TCP and IP standards didn't set standards for the APIs that enabled user 
programs to do things like send options, set type-of-service bits, set 
the TCP "urgent pointer",  and such.   So it was difficult to actually 
use some of such "optional" facilities even when they were implemented.

That's what I remember, all from the late 1970s or early 1980s. It's 
possible that things like Source Routing are no longer needed.   But 
AFAIK routing is still based on hops.  Maybe there is such a glut of 
fiber now that many of the old concerns are no longer relevant.  But 
ISPs set "data caps", so ... maybe not?

Wherever we are today, how did we get here from those early days? 
Perhaps Historians will eventually sort it all out.

Jack Haverty

On 2/3/25 09:43, Greg Skinner via Internet-history wrote:
> On Feb 2, 2025, at 10:37 AM, Dave Crocker via Internet-history<internet-history at elists.isoc.org>  wrote:
>> My recollection is that mechanisms for source routing were common in the early days, but lost favor.
>>
>> UUCP networking (!) was a version.  SMTP originally supported it.  I don't think Arpanet packets did, though I have a vague sense there was some selectivity allowed.  And I don't think IP did.
>>
>> I'm curious about a rough summary of when and how it was used and when and why it lost favor.
>>
>> d/
>>
>> -- 
>> Dave Crocker
>>
>> Brandenburg InternetWorking
>> bbiw.net
>> bluesky: @dcrocker.bsky.social
>> mast: @dcrocker at mastodon.social
>>
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
> I found a couple of mentions of the use of IP source routing in the tcp-ip digest using the following query at Google Groups:
>
> https://groups.google.com/g/fa.tcp-ip/search?q="source route”<https://groups.google.com/g/fa.tcp-ip/search?q=%22source%20route%22>
>
> One of those was part of Jon Postel’s TCP Bakeoff.  One got 15 points for doing the source route option.
>
> --gregbo
>

-------------- 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/20250203/ff07120c/attachment.asc>