24 Feb
2019
24 Feb
'19
4:51 p.m.
On Feb 23, 2019, at 3:01 AM, Grant Taylor via cctalk
<cctalk at classiccmp.org> wrote:
On 2/22/19 6:15 PM, Paul Koning via cctalk wrote:
Yes, but that's not what I was trying to say, apparently not very clearly.
There is a translation of Ethernet 2 frames into SNAP (by using an OUI of 00-00-00 or
00-00-F8 followed by the Ethentype). Those particular SNAP values are meant to be used
only on LANs different from Ethernet, and bridges connecting those to Ethernet would look
for those SNAP values and convert to the corresponding Ethernet 2 format.
SNAP as a way of encoding bridged Ethernet II
frames applies only to non-Ethernet LANs, all of which have larger MTU.
Nope. I'm quite sure that NetBIOS used SNAP on Ethernet.
I'm betting that 3174's Ethernet interfaces also used DLC / LLC2 via SNAP.
IPX could run over SNAP on Ethernet if you wanted to. SNAP covers
more than encoding bridged Ethernet II. It was intended as a way to carry protocols in
802 format for which you couldn't get a SSAP/DSAP code point (such as private
protocols). DEC did this in various places, it's perfectly straightforward.
*nod*
Perhaps some implementations make it hard to
support both simultaneously, but there is no technical reason to make such a mistake.
I feel like putting TCP/IP in SNAP on Ethernet is a mistake in that most OSs will not
know how to work with TCP in a SNAP frame as they will be expecting Ethernet II frames.
I don't know that there's a technical reason per say. I do think that there is a
market reason. The pretense
that broadcast is different from multicast is just a confusion. The description says that
it is used for traffic that every station wants to get. If you take that literally, no
protocol should use broadcast, because there isn't any protocol that every station on
every LAN wants to see. For example, ARP should have used multicast for the same reason
DECnet does: it is traffic that is interesting to stations which speak that protocol, and
only to those stations.
Flip things on their head. I think it's that the sender wants every receiving
station to see. I think
that's right. For 802.5, that is.
ACK
In FDDI the frames are "stripped" by
the sending station, which allows things like network monitors in promiscuous mode to work
just like on Ethernet
Intriguing.
The claim of collapse under load -- meaning
throughput goes down beyond a certain load level -- is valid for ALOHA and similar
networks, but not on Ethernet because it uses carrier sense and collision detect. Under
overload it runs at close to full utilization.
Okay. So you weren't saying that Token Ring had problems as much as you were saying
that Ethernet can work at close to capacity.
I remember seeing references to Ethernet would start to have problems with increasing
backouts as the number of stations wanting to transmit at the same time would grow.
Though that may be that the average throughput of a given station may go down while the
network segment itself is closer to saturation.