Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!tektronix!hplabs!ucbvax!XX.LCS.MIT.EDU!JNC
From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa")
Newsgroups: mod.protocols.tcp-ip
Subject: Re: RING vs. ETHER - Theory and practice.
Message-ID: <12224206784.24.JNC@XX.LCS.MIT.EDU>
Date: Sun, 20-Jul-86 11:33:24 EDT
Article-I.D.: XX.12224206784.24.JNC
Posted: Sun Jul 20 11:33:24 1986
Date-Received: Mon, 21-Jul-86 00:41:37 EDT
References: <8607191215.aa15740@SEM.BRL.ARPA>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 45
Approved: tcp-ip@sri-nic.arpa


	First, let me correct some misstatements in both your characterization
of the ring systems (one of which I had a hand in designing at MIT). It does
not automatically retransmit packets; perhaps the person was confusing it with
Ethernet interfaces which do retransmit packets automatically in case of a
collision. Also, the 80MB ring interface does have on board packet buffer and
it will receive back to back packets without host intervention, although the
10MB ring interface does not.

	What both 10M and 80M *do* have (as you alluded to) is a low level
*acknowledgment*. I.e., you know (with some reasonable degree of probability)
whether or not the intended recipient got the packet. The reason I think that
this is important is because it is starting to become clear that dropping
packets is a Bad Thing in terms of the effect on performance. Any losses and
retransmissions have serious effects on the performance of 'single-ACK'
protocols like TCP, especially when you are running at high data rates. The
single ACK is such a weak mechanism that it should only be used as a backstop
for rare failures; if you have to use it a lot, you lose a lot of performance.
Since we are stuck with TCP -> you should not drop packets.
	The point of all this is that nets ought to have a reasonable
hardware acknowledgement feature that would let you know when a host could
not accept a packet destined to it. I don't know why the didn't put one in
Ethernet; it would have been really trivial. The CHAOS hardware built at
the MIT AI Lab (which was a 4MB/sec Ether like system) had such a feature;
the recipient jammed the cable (causing a collision) if a packet for that
destination could not be handled.
	What amazes me is that although the IEEE Ethernet spec did make all
sorts of changes to the spec, of little or no pactical utility as far as I can
see (e.g. Ethernet demonstrably works fine without a length field), they
didn't fix this glaring defect! A typical standards committee: they make all
sorts of gratuitous changes to an existing widespread spec, resulting in a
massive incompatability problem, without fixing any real problems.

	I guess it is true that with a multi-buffered interface you are less
likely to drop packets, but it still does help. Also, low level acks can help
gateways a lot. If the next hop gateway on a route dies, you can detect it,
and reroute around it. You can also give more informative error messages. (How
I hate 'connection timed out' - I want to know why! The annoying thing is that
even when gateways go to great lengths to send back ICMP error messages, most
hosts do not reflect them to users. When I put ICMP error support into a
gateway, I could not find a host at MIT that would take the messages and use
them to make an intelligent error message for the user!)

	Noel
-------