Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!ucbvax!cbosgd.ATT.COM!mark
From: mark@cbosgd.ATT.COM.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: RING vs. ETHER - Theory and practice.
Message-ID: <8607210511.AA02538@cbosgd.ATT.COM>
Date: Mon, 21-Jul-86 01:11:44 EDT
Article-I.D.: cbosgd.8607210511.AA02538
Posted: Mon Jul 21 01:11:44 1986
Date-Received: Mon, 21-Jul-86 20:28:07 EDT
References: <12224206784.24.JNC@XX.LCS.MIT.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 18
Approved: tcp-ip@sri-nic.arpa

In article <12224206784.24.JNC@XX.LCS.MIT.EDU> you write:
>	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.

I note that 802.2 has a whole bunch of "connection oriented" features
added onto the side of Ethernet.  While I assume most of us are ignoring
them (I gather they were put there by X.25 types) I wonder if there would
be a clean way to use these facilities to get an ack or nak back for
normal IP type datagrams?  Since I gather we have some standards to
work out regarding ARP on 802.2 anyway, maybe this would be a good
time to adopt some other conventions too?

	Mark