Re: [colorforth] DARPA takes aim at IT sacred cows

["Samuel A. Falvo II" <kc5tja@xxxxxxxx>]

On Saturday 27 March 2004 08:38 pm, wtanksleyjr@xxxxxxx wrote:
> We'll have to understand the problem first. So, who's going
> first? Let's see the network re-implemented in the spirit
> of Forth!

I have already done this, actually.  Though it won't appear in my Kestrel 
kit's peripheral interconnect bus, I did take some time out of my busy 
day to entertain a thought experiment: if I had to re-engineer a 
networking system, from scratch, using the Forth philosophy, how would I 
do it?

Assumptions:

1.  The network runs over wires.

2.  The network uses a bus architecture, physically or simulated (as with 
a switch or hub)

3.  There is no logical distinction between a computer node address and a 
software socket.  You can't send "a computer" a packet and expect it to 
know what to do with it.  It's always sent to a specific end-point.  
Sometimes this end-point is implied in the 'upper protocol' (e.g., ARP 
is an example of an implicit end-point, specified by Ethernet's protocol 
ID field), but it is always there.

Basically, we start out with the simplest possible network: two 
computers, connected point to point over a common wire.  Each computer 
represents a single end-point, as it's assumed one application on each 
end point "owns" the link.  There is no need for addressing information: 
if a byte of data is received, *clearly* it came from the other 
computer.

But in a multitasking operating environment, it's not desirable to let 
one application own the whole link.  What if we want to chat on IRC 
while downloading a file?  We need specific end-points that terminate in 
specific applications.  Yet, it's clear that we also want to preserve 
the lack of latency that the former situation had.  Therefore, we can 
establish a sense of modality on the network: the currently addressed 
end-point is who receives the bytes.  Note that each side of the 
connection can have independent end-points, since we always know who 
sent the data if a byte is received.  We need some way to notify the 
node that we're changing who we're talking to; hence, an escape 
mechanism is used.  Let's use the $AA byte for this purpose.  The format 
is $AA <epID>, where <epID> identifies the target end-point on the other 
computer.

The next level up occurs when we have three or more computers.  Suddenly, 
if we were to receive a byte, we *don't* know who sent it.  Therefore, 
we now need some means of identifying who sent a particular piece of 
data.  But since most (like, over 80%) end-points aren't shared amongst 
multiple nodes, it's possible to leave off source address information -- 
clearly, any data coming into a Telnet connection MUST have originated 
from the server the Telnet session is engaged with.  Therefore, when 
sending a packet of data, only the destination endpoint need be 
specified.  This must necessarily include the machine ID.  However, with 
proper scheduling, data to multiple end-points on that machine can be 
trunked!  There's no need to keep re-transmitting the machine's address 
over and over again!  Hence, applying the same principle above once 
again, we make a new escape sequence, $BB, to handle this job.

So far, a typical packet looks like this:

  $BB <mID> $AA <eID> ...data... $AA <eID'> ...data... $AA <eID''> ...

Thus, as far as the receiving nodes are concerned, it may as well still 
be connected to a point-to-point link.  Note that all the eIDs are 
within the scope of a machine ID.

Internetworking can be accomplished using yet another escape sequence, 
and as usual, all packets intended for that network can be trunked, 
again with the goal of minimizing bytes transmitted in mind.

Does this networking system work?  Well, there is zero indication to say 
it won't.  In fact, ATM networks already employ a virtual circuit 
identifier approach towards labeling data flows, and it works *great*.  
MPLS for the Internet strives to do the same basic thing; unfortunately, 
it keeps that insideous IP header overhead.

Unlike even TCP/IP, this networking system doesn't even need to depend on 
packets.  The concept of a 'packet' falls out naturally from its design, 
in a multi-computer environment.  But when connecting two computers, and 
data flows are limited to only a few applications, latencies and 
throughputs approach those of a direct, point-to-point connection.

You can't beat it.  At least, I haven't found anything that can yet. 

--
Samuel A. Falvo II


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com