Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site ima.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ima!johnl
From: johnl@ima.UUCP
Newsgroups: net.lan
Subject: Re: Token rings, error reporting in
Message-ID: <98600003@ima.UUCP>
Date: Fri, 24-Jan-86 15:38:00 EST
Article-I.D.: ima.98600003
Posted: Fri Jan 24 15:38:00 1986
Date-Received: Sun, 26-Jan-86 04:39:47 EST
References: <87900001@wdl1.UUCP>
Lines: 33
Nf-ID: #R:wdl1:87900001:ima:98600003:000:1944
Nf-From: ima!johnl    Jan 24 15:38:00 1986


/* Written  2:14 pm  Jan 22, 1986 by jbn@wdl1 in ima:net.lan */
>      Which token rings actually provide indication of non-delivery to the 
> sender?  I've been told that the Cambridge Ring does and Proteon does not.

I don't know about those two, but can shed some light on the IBM Token 
Ring.  This comes from an article on a "hypothetical" token ring published 
in the IBM Journal of R&D in September of 1983.  In the IBM scheme, the 
sender gets the token and puts out a packet as you would expect.  The 
receiver passes the packet through but sets some bits, and the sender 
removes the packet and regenerates a free token.  The receiver can set two 
bits: an "address recognized" bit meaning that it recognized that the 
packet was addressed to it, and a "frame copied" bit meaning that it 
actually read in the frame.  Normally the receiver would set both bits, but 
might set only the first if it had no buffer space to receive the packet.  
There is also a complicated priority reservation scheme that allows nodes 
to grab the token when they have something really important to say.  

This scheme does lower the bandwidth compared to one where the receiver 
passes on a free token, but has much better error properties.  If the 
receiver passed on a short free token as soon as it got the header of a 
long data packet, you'd have confusing situations where the sender got the 
free token back long before it had finished sending a packet.  Besides, if 
the receiver sends the token before it's received the whole data packet, 
it'll have no way to report if the packet isn't received right.  So it 
might as well pass the data packet back to the sender, which allows 
broadcast packets as a free side benefit.  The time difference between
that and passing a delayed free token is at worst one trip around the ring
which should be short compared to a typical packet time.

John Levine, ima!johnl

PS:  Personally, I like Ethernet.