Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!husc6!m2c!jjmhome!cpoint!martillo From: martillo@cpoint.UUCP (Joacim Martillo) Newsgroups: comp.dcom.lans Subject: Re: Token Ring vs. Ethernet Message-ID: <1975@cpoint.UUCP> Date: 15 Jan 89 18:48:12 GMT References: <18796@agate.BERKELEY.EDU> <10865@s.ms.uky.edu> Reply-To: martillo@cpoint.UUCP (Joacim Martillo) Organization: Clearpoint Research Corp., Hopkinton Mass. Lines: 109 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 ><-- 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!