23 Feb
2019
23 Feb
'19
12:01 a.m.
On 2/22/19 6:15 PM, Paul Koning via cctalk wrote:
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.
I'm trying to reconstruct what exactly the
difference is, but I never
knew 802.5 well and my FDDI brain cells are all from around 1986...
Fair.
--
Grant. . . .
unix || die