home .. forth .. colorforth mail list archive ..

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

Now redo the exercise, several times, assuming first that EACH individual
assumption is WRONG.

1.  What works differently if the network does not run over wires?

2.  What works differently if the network is not a "bus" - by which I assume
you mean a "broadcast" "every endpoint at least theoretically sees every
message" organization?  If that is not what you meant, what did you mean,
and what happens if this assumption is wrong?

3.  What happens if there IS a logical distinction between a computer node
address and a software socket?  What would this mean?

You have also completely ignored protocol multiplexing issues.

4.  You appear to have made an unstated assumption that latency is not an
issue, that you can afford to "trunk up" multiple packets going to a
particular machine, in order to save a few bytes of header.  What if this
assumption is wrong?  What if latency IS an issue?  What if packet arrival
delays, and/or packet arrival delay variance, is critical?  (Think about
trying to stream music or video.  Think about trying to control a robot on
the moon from a console on Earth.)

What 99% of the network hackers out there do not realize is that the TCP/IP
protocols, and the layered models, were designed by people who DID know what
they were doing, and who DID take all these things into account.

----- Original Message ----- 
From: "Samuel A. Falvo II" <kc5tja@xxxxxxxx>
To: <colorforth@xxxxxxxxxxxxxxxxxx>
Sent: Saturday, March 27, 2004 11:34 PM
Subject: Re: [colorforth] DARPA takes aim at IT sacred cows


> 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
>


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