Xref: utzoo comp.dcom.lans:5454 comp.protocols.tcp-ip:12214
Path: utzoo!attcan!uunet!bu.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!ames!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip
Subject: Re: Zero manufacturer code in SNAP?
Summary: TCP/IP/802.3 is dead
Message-ID: <64617@sgi.sgi.com>
Date: 20 Jul 90 02:38:52 GMT
References: <1990Jul17.010234.12077@portia.Stanford.EDU> <9272@goofy.Apple.COM>
Sender: vjs@rhyolite.wpd.sgi.com
Distribution: na
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 51


It should be noted in passing that following is in the Host Requirements
standard, RFC-1122:

]      2.3.3  Ethernet and IEEE 802 Encapsulation
]
]         The IP encapsulation for Ethernets is described in RFC-894
]         [LINK:3], while RFC-1042 [LINK:4] describes the IP
]         encapsulation for IEEE 802 networks.  RFC-1042 elaborates and
]         replaces the discussion in Section 3.4 of [INTRO:2].
]
]         Every Internet host connected to a 10Mbps Ethernet cable:
]
]         o    MUST be able to send and receive packets using RFC-894
]              encapsulation;
]
]         o    SHOULD be able to receive RFC-1042 packets, intermixed
]              with RFC-894 packets; and
]
]         o    MAY be able to send packets using RFC-1042 encapsulation.
]
]
]         An Internet host that implements sending both the RFC-894 and
]         the RFC-1042 encapsulations MUST provide a configuration switch
]         to select which is sent, and this switch MUST default to RFC-
]         894.


Consider the implications.  Every vendor must offer ethernet TCP/IP
encapsulation, and that must be the default.  Adding support for 802.3
(RFC-1042) is not required, and does not increase the number of compliant
machines with which an implementation can interoperate.  Historically,
there were very few machines that used only RFC-1042.  (I think HP
used SAP, but that BICC (?) in the U.K. used RFC-1042.)

Supporting both RFC-894 and RFC-1042 does not make an implementation
faster, but code is not bad.  The reduction of the MTU in RFC-1042 is
about 1%, which should translate into around 10KBytes/second of lost
through-put for machines that are currenting get 1MByte/sec with
user-process-to-user-process TCP/IP/Ethernet.

Thus, there are no (or very few and exceptional) business reasons for a
vendor to offer RFC-1042 support, or even to continue existing RFC-1042
support.

RFC-1103 and its pending successor are a different story.


Vernon Schryver
Silicon Graphics
vjs@sgi.com