glass@tehran.berkeley.edu (01/07/89)
I've received quite a number of messages in response to my two small postings to comp.dcom.lans -- some complimentary, some expressing dissent, and no small number carrying "flames" of the form: "I think Network X is better because I use and like it, and that's that!" A few brief comments. First, to paraphrase Mark Twain, "There are lies, damn lies, and benchmarks." 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. 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. 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!). Also, once we start talking about internetworking on ISO levels above the link level, we are really talking about a WAN, not a LAN. A whole new set of considerations comes into play in this case. Finally, I've learned that there's no end to the amount of time one can spend arguing "religion." The messages I've received indicate that there's a lot more passionate feeling tied up in choices of technology than I'd expected. Or maybe the nets are just one place where such emotions tend to get vented. In any event, let's keep the forums open -- but at a dull roar, please. I have next month's column to write.... <BG>
narten@cs.purdue.EDU (Thomas Narten) (01/07/89)
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
glass@tehran.berkeley.edu (Brett Glass) (01/07/89)
In article <5786@medusa.cs.purdue.edu> narten@cs.purdue.EDU (Thomas Narten) writes: >In article <18796@agate.BERKELEY.EDU> glass@tehran.berkeley.edu writes: >>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. The use of a "foreign" internetworking protocol such as TCP/IP in a benchmark will favor Ethernet because it will negate the value of many of the Token Ring's unique features. (The Token Ring may still prevail, however, depending on how you've set up your benchmurk... er, mark.) <BG>
narten@cs.purdue.EDU (Thomas Narten) (01/08/89)
In article <18809@agate.BERKELEY.EDU> glass@tehran.berkeley.edu (Brett Glass) writes: >>Why does TCP/IP favor Ethernet? Please explain. > >The use of a "foreign" internetworking protocol such as TCP/IP in a >benchmark will favor Ethernet because it will negate the value of many >of the Token Ring's unique features. (The Token Ring may still prevail, >however, depending on how you've set up your benchmurk... er, mark.) OK, name a higher layer protocol that is able to take advantage of the "unique features" of the ring but that also performs poorly when those features are removed. How useful is this protocol? How general? -- Thomas Narten narten@cs.purdue.edu or {ucbvax,decvax}!purdue!narten
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (01/08/89)
In article <18809@agate.BERKELEY.EDU> glass@tehran.berkeley.edu (Brett Glass) writes: > >The use of a "foreign" internetworking protocol such as TCP/IP in a >benchmark will favor Ethernet because it will negate the value of many >of the Token Ring's unique features. (The Token Ring may still prevail, >however, depending on how you've set up your benchmurk... er, mark.) > You should know that one of the most fundamental aspects of the design of TCP/IP and any other good internetworking protocol is that the protocol work well independently of the medium. If you tell me that someone has developed a super-duper protocol suite tailored to Token Ring (or Ethernet for that matter) that really screams compared to TCP/IP, I would say that rates one big yawn. I am simply not interested in "local area" protocols. I need internetworking protocols. There is no such thing as TCP/IP having a favored medium. As Van J, Dave Borman from Cray, and Phil Karn from Bellcore and amateur packet radio fame, among others, have proven, TCP/IP runs over *anything* from tin cans and string to Cray channels, including Ethernet. And it now works "well". Anyone in the software development business should feel about the same way. It gets tedious writing device drivers ad nauseum. How much worse would it be to write protocol stacks for each medium ad nauseum. You haven't convinced me that Token Ring has anything really wiz-bang to offer that can't be duplicated in TCP/IP. DEC hasn't convinced me that I should love LAT and their other local area protocols. IEEE hasn't convinced anyone to use 802 LLC 2. (almost no one) I simply do not rate LAN performance by the presence or absence of acknowledgements or contention. I think raw speed, cabling, topology, fault-tolerance, etc are much better ways to rate LAN technology. I have Ethernet networks where no other technology will do, since all the vendors support it and the cost of the computer hardware justifies the Ethernet. I have Pronet-80 for a backbone. Ethernet wouldn't do, simply because of bandwidth. I have LocalTalk because of Apple, but I wish I had a nice LocalTalk X terminal since that would be very cost-effective. I would like to run TCP/IP on all these media. Guess what? I can. Kent England, Boston University
bc@halley.UUCP (Bill Crews) (01/08/89)
In article <18809@agate.BERKELEY.EDU> glass@tehran.berkeley.edu (Brett Glass) writes: >In article <5786@medusa.cs.purdue.edu> narten@cs.purdue.EDU (Thomas Narten) writes: > >>In article <18796@agate.BERKELEY.EDU> glass@tehran.berkeley.edu writes: >>Why does TCP/IP favor Ethernet? Please explain. > >The use of a "foreign" internetworking protocol such as TCP/IP in a >benchmark will favor Ethernet because it will negate the value of many >of the Token Ring's unique features. (The Token Ring may still prevail, >however, depending on how you've set up your benchmurk... er, mark.) First, ARPA IP and ISO IP are purported to be extremely similar. I don't know the details, but perhaps it is likely that 802.5's behavior beneath ARPA IP will be similar beneath ISO IP. Second, regardless of the virtues .5 might have, if most of the widely used layer 3 protocols "negate the value of many of the Token Ring's unique features", then perhaps these unique features are doomed to go to waste. I'm not knocking .5. Just your argument. This isn't comp.os.research. The real world matters here. -bc -- Bill Crews bc@halley.UUCP (512) 244-8350 ..!rutgers!cs.utexas.edu!halley!bc
mogul@decwrl.dec.com (Jeffrey Mogul) (01/10/89)
In article <5786@medusa.cs.purdue.edu> narten@cs.purdue.EDU (Thomas Narten) writes: >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"). Alas, it's not so simple. Because the efficiency of CSMA/CD depends on the ratio of packet length (expressed in time, or packet-bits/bit-rate) to the propagation delay for the entire cable, it doesn't scale well to high-delay (i.e., high bandwidth*length) networks. For example, a 100 Mbit CSMA/CD net would only perform as efficiently as the 10Mbit Ethernet if the faster net were one tenth the length of the shorter net, or if the minimum packet size were ten times longer. Since it doesn't make sense to require 600-byte packets, a 100Mbit CSMA/CD net would probably only work for cables < 500 meters. There might be some tricks to get around this (see the paper by Maly et al, "Dynamic Bandwidth Allocation in a Network", SIGCOMM 88, for something that might work) but basically it's a fact of life. In our paper, we said At higher bit rates or for longer networks, ring topologies may be the only acceptable approach, but experience with Ethernet proves that at 10 Mbits/second, over a kilometer or so of cable, CSMA/CD is quite successful. (Experiments conducted after that was written suggest that even 5 Km of cable works well. Dave Boggs believes that CSMA/CD is "viable for any combination of bandwidth under 20 Mbits/sec and distance under 10 Km.") One should also not write off point-to-point or star technologies. Bottom line: you need to pick the parameters before you can make a comparison between two LAN technologies. -Jeff
david@ms.uky.edu (David Herron -- One of the vertebrae) (01/11/89)
In article <18796@agate.BERKELEY.EDU> glass@tehran.berkeley.edu () writes: >I've received quite a number of messages in response to my two small >postings to comp.dcom.lans -- some complimentary, some expressing dissent, >and no small number carrying "flames" of the form: "I think Network X is >better because I use and like it, and that's that!" Sorry 'bout that, if I'd have thought about it more before posting I'd have realized this was one of those touchy religious issues.... >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. 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!). Also, once we start talking about >internetworking on ISO levels above the link level, we are really >talking about a WAN, not a LAN. A whole new set of considerations >comes into play in this case. I think you're missing the point when people are arguing for end-to-end acknowledgements. These people know quite well about living on a WAN and not a LAN. What's the Internet if it's not a WAN? That link-level acknowledgement looks useful until, as people have said, you bring in external nets. If the host you're sending to is on the other side of a gateway, and the ONLY acknowledgement is the link level one, then the original host can easily get confused into thinking the packet was delivered when it really wasn't. So what you're claiming as a gain turns into a minus. Anyway, this thread of articles has been interesting, thank you ... -- <-- David Herron; an MMDF guy <david@ms.uky.edu> <-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <-- Now I know how Zonker felt when he graduated ... <-- Stop! Wait! I didn't mean to!
dick@ccb.ucsf.edu (Dick Karpinski) (01/11/89)
We have some departmental token rings and our support folks are saying that interconnecting token rings will provide the servers (disk, printer, modem?) on one ring to the others. They do not know of any way to share like that when the connection between rings is over an Ethernet. Do you? Dick Dick Karpinski Manager of Minicomputer Services, UCSF Computer Center UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick (415) 476-4529 (11-7) BITNET: dick@ucsfcca or dick@ucsfvm Compuserve: 70215,1277 USPS: U-76 UCSF, San Francisco, CA 94143-0704 Telemail: RKarpinski Domain: dick@cca.ucsf.edu Home (415) 658-6803 Ans 658-3797
martillo@cpoint.UUCP (Joacim Martillo) (01/16/89)
In article <10865@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: >In article <18796@agate.BERKELEY.EDU> glass@tehran.berkeley.edu () writes: >>I've received quite a number of messages in response to my two small >>postings to comp.dcom.lans -- some complimentary, some expressing dissent, >>and no small number carrying "flames" of the form: "I think Network X is >>better because I use and like it, and that's that!" >Sorry 'bout that, if I'd have thought about it more before posting I'd have >realized this was one of those touchy religious issues.... >>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. 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!). Also, once we start talking about >>internetworking on ISO levels above the link level, we are really >>talking about a WAN, not a LAN. A whole new set of considerations >>comes into play in this case. >I think you're missing the point when people are arguing for end-to-end >acknowledgements. These people know quite well about living on a WAN >and not a LAN. What's the Internet if it's not a WAN? That link-level >acknowledgement looks useful until, as people have said, you bring >in external nets. If the host you're sending to is on the other side >of a gateway, and the ONLY acknowledgement is the link level one, >then the original host can easily get confused into thinking the packet >was delivered when it really wasn't. By the way, if you read the IEEE standards carefully, you quickly realize that the highly efficient link-level routing and acknowledgement scheme really is not sufficient for even a single physical LAN environment. From IEEE Std 802.5-1985 p. 61 5.1.2.3 MA_DATA.confirm. This primitive has *local* significance and shall provide an appropriate response to the LLC sublayer MA_DATA.request primitive signifying the success or failure of the request. From IEEE Std 802.5-1985 p. 63 5.2.2.3 PH_DATA.confirmation. This primitive has *local* significance and shall provide an appropriate response to the MAC sublayer PH_DATA.request primitive signifying the acceptance of a symbol specified by the PH_DATA.request and willingness to accept another symbol. Now what does local mean? If it is not obvious: IEEE Std 802.3-1985 p. 22 2.3.2 MA_DATA.confirm 2.3.2.1 Function. This primitive has local significance and shall provide an appropriate response to the LLC sublayer MA_DATA.request primitive signifying the success or failure of the request. Since the wording is identical for MA_DATA.confirm for both 802.5 and 802.3, I would suggest that a designer/implementer who depends on 802.5 to provide more in terms of reliability than 802.3 is looking for serious trouble. By the way, suppose 802.5 really could provide reliable, sequenced delivery of link layer packets without an end-to-end sequencing and acknowledgement protocol at the link-layer. Then it would not be possible to provide security either as a sublayer at the bottom of the link layer or as a security layer between LLC and the MAC. I would demand that an application which ran in an unsecured environment should be able to run in a secure environment. Now if LLC does not provide sequenced, reliable delivery and the security layer or sublayer throws away packets which do not pass security tests, suddenly the sequenced reliable delivery which LLC depends on does not exist even though the MAC provides sequenced reliable delivery. I suppose one could require the security layer or sublayer to provide sequenced reliable delivery, but that seems inappropriate in many cases and would make the provision of sequenced reliable delivery at the MAC seem rather excessive. By the way in the bridged environment a la 802.1 (not an internetworked environment), sequenced reliable delivery at the MAC layer definitely does not guarantee sequenced reliable delivery on different segments of the bridged network. Since the IEEE is supposedly carefully crafting all the 802 standards, so that a 802.1 bridged network should be indistinguishable at the LLC layer from a single physical LAN of any of the 802 technologies, assuming LLC can depend solely upon the 802.5 MAC layer for reliability and sequencing is probably incorrect. It may actually work in some cases, but the IEEE specification clearly does not guarantee it. Thus, when comparing ethernet and token ring, it is appropriate to use an test-situation which uses end-to-end sequenced and reliable protocols for comparison. I suppose you might argue that using LLC type II which does provide another layer of reliability would have been more appropriate for comparison than TCP/IP, but from experiments which I performed at Prime Computer and which others have performed locally, it appears TCP/IP will almost invariably provide greater throughput on any LAN technology than 802.2 type II. The relatively silly packet counting flow control, too frequent acknowledgement scheme and lack of resequencing seem to harm performance. Thus using a TCP/IP-based test suite seems perfectly reasonable for comparing the two technologies. In any case, cost is the real killer. Token-ring costs too much in comparison to the adequacy of ethernet. >So what you're claiming as a gain turns into a minus. >Anyway, this thread of articles has been interesting, thank you ... >-- ><-- David Herron; an MMDF guy <david@ms.uky.edu> ><-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET ><-- Now I know how Zonker felt when he graduated ... ><-- Stop! Wait! I didn't mean to!
loethen@psp.psp.com (10/24/90)
GREETINGS TO ALL ON THE NET. FIRST, PRELIMINARIES. I AM POSTING THIS TO COMP.SYS.DEC,COMP.PROTOCOLS.TCP-IP, & COMP.DCOM.LANS. OUTSIDE IF THAT, CROSS-POST TO WHAT EVER YOU THINK MIGHT BE HELPFUL. ALSO, PLEASE ANSWER VIA EMAIL. MY NEWS FEED IS SPOTTY AND OCCASIONALLY UNRELIABLE. I HAVE HELPED SPECIFY AND TEST A ETHERNET - TCP/IP NETWORK TO PROVIDE BROADBAND CONNECTIVITY FOR A DEPARTMENT CONSISTING OF DEC (WORKSTATIONS, 3100 AND 3800), TANDEM AND PCS (AT AND MC BUS). AS WE HAVE COMPLETED THE TESTING OF THIS SYSTEM AND WERE MAKING PREPERATIONS TO PURCHASE SAID HARDWARE AND SOFTWARE, OUR CORPORATE SUPPORT GROUPS HAVE ASK US TO RE-EVALUATE OUR DECISIONS AND ANALYZE WHAT IT WOULD TAKE TO MAKE THIS A TOKEN-RING NETWORK INSTEAD (RUNNING NOVELL ON THE RING FOR PCs). SOME FACTS: WE NEED FILE SHARING, REMOTE LOGIN, REMOTE BACKUP, PRINTER SHARING, TERMINAL EMULATION (OBVIOUSLY) AND EVENTUALLY, REMOTE PROCEDURE CALLS. THE COMPANY GOAL IS TO MIGRATE TO OSI THERE ARE ALREADY TWO LARGE (75-100) TOKEN RINGS IN THE COMPANY, RUNNING NOVELL AND PROVIDING CONNECTIVITY FOR PC TO THE IBM MAINFRAME. QUESTIONS: IS THIS A VIABLE SOLUTION (USING TOKEN RING)? HOW MIGHT IT BE DONE? IF T/R IS NOT A BETTER SOLUTION, WHAT ARE SOME REASONS THAT MIGHT SUPPORT THE ETHERNET TCP/IP SOLUTION? I HAVE DONE SOME CHECKING INTO THIS, OF COURSE, BUT I COULD USE SOME FEEDBACK ON DIRECTIONS OR ALTERNATIVES I HAVEN'T THOUGHT OF YET. THANKS AGAIN. -- ******************************************************************************* * Shelly Loethen * "Only By Attempting the Absurd, * * * Can We Achieve the Impossible" * *=============================================================================* * ...uunet!amgraf!brian386!swl386!shellyl // loethen@psp.psp.com * ******************************************************************************* * Disclaimer: "My opinions are my own, thank you!" * *******************************************************************************
loethen@psp.psp.com (10/24/90)
X-NEWS: psp comp.dcom.lans: 425 GREETINGS TO ALL ON THE NET. FIRST, PRELIMINARIES. I AM POSTING THIS TO COMP.SYS.DEC,COMP.PROTOCOLS.TCP-IP, & COMP.DCOM.LANS. OUTSIDE IF THAT, CROSS-POST TO WHAT EVER YOU THINK MIGHT BE HELPFUL. ALSO, PLEASE ANSWER VIA EMAIL. MY NEWS FEED IS SPOTTY AND OCCASIONALLY UNRELIABLE. I HAVE HELPED SPECIFY AND TEST A ETHERNET - TCP/IP NETWORK TO PROVIDE BROADBAND CONNECTIVITY FOR A DEPARTMENT CONSISTING OF DEC (WORKSTATIONS, 3100 AND 3800), TANDEM AND PCS (AT AND MC BUS). AS WE HAVE COMPLETED THE TESTING OF THIS SYSTEM AND WERE MAKING PREPERATIONS TO PURCHASE SAID HARDWARE AND SOFTWARE, OUR CORPORATE SUPPORT GROUPS HAVE ASK US TO RE-EVALUATE OUR DECISIONS AND ANALYZE WHAT IT WOULD TAKE TO MAKE THIS A TOKEN-RING NETWORK INSTEAD (RUNNING NOVELL ON THE RING FOR PCs). SOME FACTS: WE NEED FILE SHARING, REMOTE LOGIN, REMOTE BACKUP, PRINTER SHARING, TERMINAL EMULATION (OBVIOUSLY) AND EVENTUALLY, REMOTE PROCEDURE CALLS. THE COMPANY GOAL IS TO MIGRATE TO OSI THERE ARE ALREADY TWO LARGE (75-100) TOKEN RINGS IN THE COMPANY, RUNNING NOVELL AND PROVIDING CONNECTIVITY FOR PC TO THE IBM MAINFRAME. QUESTIONS: IS THIS A VIABLE SOLUTION (USING TOKEN RING)? HOW MIGHT IT BE DONE? IF T/R IS NOT A BETTER SOLUTION, WHAT ARE SOME REASONS THAT MIGHT SUPPORT THE ETHERNET TCP/IP SOLUTION? I HAVE DONE SOME CHECKING INTO THIS, OF COURSE, BUT I COULD USE SOME FEEDBACK ON DIRECTIONS OR ALTERNATIVES I HAVEN'T THOUGHT OF YET. THANKS AGAIN. -- ******************************************************************************* * Shelly Loethen * "Only By Attempting the Absurd, * * * Can We Achieve the Impossible" * *=============================================================================* * ...uunet!amgraf!brian386!swl386!shellyl // loethen@psp.psp.com * ******************************************************************************* * Disclaimer: "My opinions are my own, thank you!" * *******************************************************************************