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
