Curtis:
Thank you for your referenced article.
It bothers me to see myths propagated. It also appears as though your
knowledge of ethernet (IEEE802.3) technologies ended well over a decade ago.
There are many definitive works that address the nonsense you espoused and the
best known is by Boggs, Mogul and Kent.
research.compaq.com
The article you quote is from 1988, and a production of Digital Equipment
Corporation. A lot of knowledge about traffic is still valid, it seems, even over a
decade later!
Also, many of the sources state that 10Gb Ethernet is basically 1Mb Ethernet, just
faster, so old knowledge still applies. I admit, haven't looked at MAC/PHY/PMD
deeply enough to disagree with these authorities.
I haven't perhaps been clear enough: I'm trying to puzzle out the idea of
multi-access networks, with many hosts and many clients not managed by a
central group, and understand the traffic issues related to mixing voice demands
(real-time requirements, with fixed small packets) with other media demands such as
data (variable sized packets, and bursty, tolerates delays) or or steam video (large
packets, real-time). This is the traffic model for the famous multi-media broadband
internet (IP based) network, which many think is the next generation network.
I am very happy to thank you for your article, because it gives practical experience
on why collision detection won't do well under multi-access multi host multi-client
conditions, and states that clearly, from the point of theory and simulation. The
lesson's learned section (4.1) give the following recommendations:
". Don't install long cables: to cover a large area, break up the cable with bridges or
gateways (routers), not repeaters.
. Don't put too many hosts on one cable: use gateways to break the network into
communities of interest, trading higher delay for intercommunity traffic for better
intracommunity response time and throughput.
. Implement the protocol correctly: proper collision detection and binary
exponential backoff in interface or host software is essential to good performance.
. Use the largest possible packet size: this keeps the packet count down, reducing
the likelihood of collision and not incidentally reducing overheads internal to hosts.
. Don't mix serious realtime and serious bulkdata applications: it is not possible
to simultaneously guarantee the lowest delay and the highest throughput (although
for moderate requirements both kinds of applications coexist well)."
Basically, they say to get good performance you must use a MANAGED IP
network, selecting your hosts and client mix with care, setting all parameters in the
network for all clients and servers "properly", and not mix traffic, particularly real
time and large and small packet (VOIP anyone?). This is the opposite of web-world
and internet land, and when you mix demand types. The only recourse other than
management is to heavily over dimension (5-10:1 perhaps?).
I also note the study didn't seem that 'real world' to me (more test lab) and the
number of server and clients is nothing like a web-internet, and the traffic mix was
well regulated.
It might help to keep in mind that even now at 10 Mbps, most
ether implementations are point-to-point, attached to a switch, i.e.. a two station
ethernet, and often full-duplex. This is especially true at 100Mbps and 1GE and will
definitely be that at 10GE.
Well, yes, and I prefer distributed and mesh network topologies to rings myself for
many reasons, but that only confuses our ability to model networks, and thus
manage them. The article recommends that you design your ethernet network with
care, allocating hosts and clients in community of interest. While this may be another
a good argument to buy Akami today (and I think it is), it is also true that most of the
internet can not be managed that way, particularly when you add nomadic computing
to the already open/chatoic/free mix of server hosts and clients.
I really don't like collision detection since noticing when someone else is transmitting
at the same time can take a long time, and this causes long latency, particularly in
WAN fiber multi-mile network, where you must listen long enought for the detection
message to travel the length of the network twice. With high degree of collisions,
and with random back off and re-transmit, this causes bad jitters problems and sinks
your chances of using voice over IP.
Now some these problems can be solved with massive over-bandwidh allocation- I
acknowledge that. And, of course, theses are pre-RSVP and IPv6 analysis- but
when I last looked at RSVP that didn't solve the multi-access multi-host multi-client
problem either: I guess we need to find a paper ls with RSVP real life experience
before passing final judgement. And IPv6, with larger headers, makes small packets
like voice even less efficient.
So let me take a higher level approach.
In terms of control, a useful taxonomy is to divide networks into Fixed Control,
Collision Control, and Dynamic Control. If you analyze the control types of
networks in terms of lost resources, you can have 1) wasted or idle resources, 2)
resources lost due to collision, or 3) control overhead. Fixed networks (leased lines,
TDMA, FDMA, for example) waste resources by having a lot of idle time but are
easy to implement. I note that collision detection (ethernet, for example) networks
don't waste resources, but lose them to collision, and are easy to implement.
Dynamic allocation (switched TDM networks, for example) allocate resources on
demand, and but are more complex to implement and may have higher overheads
(which is one reason why SS7, an overlay network for TDM circuit control was
invented).
My belief is that the best protocols of the future will use dynamic allocation
schemes. These seem more interesting future areas to look at than ethernet. I also
note as investors we should be trying to predict the future, not wait to see if
something deployed succeeds; by then it is too late to get in early. |
