Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!husc6!purdue!narten
From: narten@cs.purdue.EDU (Thomas Narten)
Newsgroups: comp.dcom.lans
Subject: Re: Token Ring vs. Ethernet
Message-ID: <5786@medusa.cs.purdue.edu>
Date: 6 Jan 89 22:54:42 GMT
Sender: news@cs.purdue.EDU
Organization: Department of Computer Science, Purdue University
Lines: 61

In article  <18796@agate.BERKELEY.EDU> glass@tehran.berkeley.edu writes:
>I've heard arguments for both systems made on the basis
>of benchmarks, and so far none have been supportable strictly on the basis of
>the LAN architecture rather than the implementation. It may be argued, of
>course, that it's not practical to separate the two -- but then, that's
>a philosophical can of worms I don't really want to open just now.

Look, go read the paper by Boggs et al.  They look only at the
architecture.  They don't say "Ethernets are better than token rings";
they *do* put to rest the myth that token rings are inherently
superior to CSMA/CD by a *wide* margin.  In other words, statements
like "token rings are better than ethernets" are just plain nonsense
(but then, so are statements like "ethernets are better than rings").

>Second, virtually all of the arguments I received supporting Ethernet
>were based on the assumption that the TCP/IP protocol suite was being
>used for internetworking. Needless to say, this assumption can only
>favor Ethernet.

Why does TCP/IP favor Ethernet?  Please explain.  Again, see the paper
by Boggs et al.  They look at the ethernet from the physical media
only.  They make no assumptions about higher level protocols.

I think the correct observation to make is that TCP/IP is an existance
proof that Ethernets can go fast.  If there were other protocols that
could drive the media at rates near 10 Mbps, they too would show that
the Ethernet can be driven at high data rates.  There just aren't many
high-througput protocols to perform benchmarks against.

>The Token Ring has a highly efficient link-level
>routing and acknowledgement scheme that's guaranteed to be there (it's
>built into the chip set!).

Just to show that link-level acks aren't 100% wonderful, let me give
you an example where having a link-level acknowledgement isn't
necessarily such a nifty feature.  In the UNIX ProNET driver, the
driver retransmits frames that return with the acknowledgement bit not
set (e.g., frames the receiver didn't accept).  Since a sender can
generate back-to-back frames faster than a single receiver can receive
them, the second frame of the sequence returns unacknowledged.  The
driver then retransmits the packet up to 8 times before giving up.  It
turns out that when the back-to-back packets result from fragmented IP
datagrams, 8 retries are not enough time for the receiver to recover
from the first packet and the retransmitted packet is lost.  Now not
only is the frame not delivered, but the sender fields 8 extra
interrupts trying to deliver a single packet.

Upping the number of retransmissions is not a particularly good
solution either.  The driver also retransmits packets to hosts that
are down.  After all, 1 bit can't distinguish between "host crashed"
and "host temporarily out of buffers".  Thus, packets to crashed hosts
are an extra load on the sender.

>In any event, let's keep the forums open -- but at a dull roar,
>please. I have next month's column to write....

How about: routers are clearly better than bridges :-)

-- 
Thomas Narten
narten@cs.purdue.edu or {ucbvax,decvax}!purdue!narten