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

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

On Sunday 28 March 2004 08:14 am, John R. Strohm wrote:
> 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?

Nothing.  Bus-architecture networks run over any common medium.  
Employment of DAMA allows for efficient hidden transmitter syndrome 
resolution.

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

After some thought, absolutely nothing.  A switch can intelligently route 
network packet, exactly as it does on Ethernet 10-base-T networks.

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

I'd like to see one example of this.  I can, in every case I've 
researched so far, find "an endpoint" when a network address is given.

> You have also completely ignored protocol multiplexing issues.

No, in fact, I rather **EXPLICITLY** stated, by way of example, that the 
protocol ID field is as much a part of the end-point address as, say, a 
socket ID field.  ATM is predicated on this, and it is known to work.

> 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

The whole purpose for doing so is to *eliminate* latency.

You've obviously missed the whole point of the exercise, completely and 
totally.  Because escape characters can appear *anywhere* in a 
transmitted byte stream, and not only on packet boundaries, media access 
latency for higher priority traffic than what is being sent is, well, 0.  
Zip.  Nada.  It just plain doesn't exist.

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

In practice, these issues are moot.  End-points buffer a significant 
(though not necessarily a majority) amount of the stream data before 
even *attempting* to render the data.  As long as packets arrive fast 
enough to keep the buffer filled, that's all the real-time media player 
needs.  It could care less about specific inter-packet delays.  And if 
it does, well, it's clearly not designed at all for fault tolerance.  In 
which case, you get what you pay for.

Power supplies use capacitors to filter power for a reason: that reason 
is, simple, there is no perfect power supply.  You get ripple, you get 
loading effects, and you occasionally even get drop-outs.  Well, the 
same is true with network traffic too.

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

What YOU don't seem to realize is that *I* know what I'm doing, and as a 
result, I find your most condescending attitude towards this whole 
discussion to not only be utterly bunk, but also outright insulting, 
even to those who are *WILLING* to *CONSIDER* the *POSSIBILITY* of 
alternative structures.  I have certain words to say about such 
attitudes, but they are not appropriate to disclose in a public forum 
such as this.

I ran two internet service providers in my life, and have provided 
network design/engineering services for numerous companies during that 
time.  Moreover, I'm also actively involved with amateur radio computer 
networking, with networking occuring over RF links at monsterous speeds 
as 1200 (yes, that's one thousand, two hundred) bits per second.  Move 
over 802.11b.  Clearly, network overheads and latencies are **CRITICAL** 
issues at such slow speeds.  I've written and maintained server software 
employing raw sockets all the way up to using CORBA.  Care to contest?

I don't know where people get the *crazy* idea that QoS is needed at high 
throughputs.  That's RETARDED.  It's at the *SLOWEST* speeds that you 
need it the most.

Applying this argument is like saying the people who designed the OSI 
layer didn't know what they were doing either: consider ATM, from 
largely the same people who pretty much brought you the original OSI 
layer concept, which not only doesn't follow that model, it outright and 
publically advertises that it doesn't ("Look!  We don't have a network 
layer structure -- we have a network CUBE!  And it's only 4 layers deep 
on an edge!").

In the end, the purpose of networking is very simple: Get data from point 
A, to point B.  Now do this with a minimum of overhead.  From 
minimization of overhead, comes minimization of latency.  From 
minimization of latency comes vastly superior real-time performance.  
And from that come happy customers.

Some links for you to ponder and digest:

http://www.stuartcheshire.org/papers/LatencyQuest.ps
  Discusses issues pertaining to latency.

http://www.stuartcheshire.org/draft-ietf-pppext-cobs-00.txt
  Proposes *pre-emptive packet insertion* techniques to address latency.
  It's an actual RFC.  It's made by people "who know what they're doing."
  Oh, and it's not entirely unlike what *I* just proposed *ENTIRELY* from 
  *FIRST PRINCIPLES.*  Gee, go figure.

http://www.stuartcheshire.org/rants/ATMParadox.html
  I used to be an avid fan of ATM outright (just ask most anyone here or 
  in the amateur radio community) until I read this.

http://www.stuartcheshire.org/rants/Latency.html
  Ho dang, yet another argument for latency-related issues.

http://www.stuartcheshire.org/rants/Networkdynamics.html
  Simply a work of art.  For every network guarantee, there is an equal 
  and opposite network denial.

Yeah, they're mostly written by the same person.  But he has demonstrated 
a list of credentials in the industry, and is well linked to by others 
(in particular, KA9Q, Phil Karn, working for one of the most visible of 
telecommunication companies today, Qualcomm), such that I have little 
reason to question him.

Now, if you're willing to discuss things like a civilized individual, 
without resorting to ivory tower attitudes, I welcome discussion.  
Otherwise, Put Up or Shut Up.

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