[ih] "The First Router" on Jeopardy

[Brian E Carpenter]

Jack,
On 24-Nov-21 07:17, Jack Haverty via Internet-history wrote:
> On 11/23/21 9:51 AM, Steve Crocker via Internet-history wrote:
>> I wouldn’t expect  TCP packets to be routed differently from UDP packets.
> 
> But we *did* expect packets to be routed differently, even though they
> were all IP packets.
> 
> That was our purpose in putting the Type-Of-Service and Time-To-Live
> fields in the IP header.  Some packets required more reliable delivery
> but time didn't matter.  A good example is during transfer of a large
> file by FTP.  Other packets required fast delivery, since if they
> arrived too late they weren't useful.  Packet voice is an example.
> 
> By setting the TTL and TOS fields appropriately, a host computer could
> advise the IP backbone of routers of what kind of behavior was
> appropriate for that packet.  A packet which is part of a large file
> transfer might be routed over a satellite link, since time wasn't
> critical.   That role was envisioned for the "Wideband Net". However, a
> packet which is part of a conversational voice stream might be routed
> over only terrestrial nets to minimize delay, and if a router along the
> way determined that it would take too long to get to a destination (TTL
> would run down), that router could simply discard it.
> 
> This would require a lot of mechanism in the routers, 


Exactly, and it was simply not viable economically, compared to "throwing
bandwidth at the problem".

> including
> multiple, overlapping, and competing routing algorithms, one for each
> Type Of Service.   At the time (1980ish) the router hardware didn't have
> the capability, and we hadn't figured out how to implement such
> functionality anyway.   But The Plan was to have an Internet which would
> support multiple types of service over the available mix of networks,


We tried to recuperate that plan around 1998 (RFC2474, RFC2475), because
people were very much aware of those 8 lost bits, and we even incorporated
the same 8 bits in the IPv6 header.

> and route packets quite differently even when they were all IP.


s/route/queue/ and that's what we did, but it proved successful only
on site-wide networks, compared to throwing bandwidth at the problem
on the WAN.

> Then the Internet went commercial in the mid 80s, and it seems that The
> Plan was lost.


The "New IP" gang and the true believers in Deterministic Networking
seem to believe that we can do it now, at least in limited domains.
It remains to be seen whether that's viable, compared to (guess what)
throwing bandwidth at the problem. The problem's always been the same:
can we process packets faster than line speed, which is the only way
to sidestep queueing theory? If not, add bandwidth and you're done.

(Reading both volumes of Kleinrock's queueing theory book was one of
best investments of my time that I can recall. I didn't retain much
of the algebra, but the basic messages were loud and clear.)

    Brian

> 
> AFAIK, such capabilities never got implemented in IP, although something
> similar must have been done when "multi-protocol routers" appeared in
> the late 80s.  They could simultaneously run several overlapping
> "internets" of different protocols.   When I was involved in operating
> Oracle's corporate intranet in the early 90s, we had IP, Netware,
> Appletalk, OSI, and probably a few others, all running simultaneously.
> I don't recommend it; it was a nightmare to operate.
> 
> Jack Haverty
> 
>