Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site petrus.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!ucbvax!decvax!bellcore!petrus!karn
From: karn@petrus.UUCP (Phil R. Karn)
Newsgroups: net.dcom
Subject: Re: TCP/IP sits on a LAN
Message-ID: <626@petrus.UUCP>
Date: Sun, 6-Oct-85 20:30:06 EDT
Article-I.D.: petrus.626
Posted: Sun Oct  6 20:30:06 1985
Date-Received: Tue, 8-Oct-85 04:10:50 EDT
References: <9@dolphy.UUCP>
Distribution: net
Organization: Bell Communications Research, Inc
Lines: 38

> Can anyone discuss, dissertate, denigrate, or point out references 
> regarding the suitability of TCP/IP as the top end of a Ethernet or
> similar local area net?  Can the ample header truly be customized?
> Does a connectionless based interface have a quantifiable throughput
> increase over a VC?  For both single and multi packet messages? etc?
> etc?

TCP/IP works just fine with, and is very heavily used on, Ethernets.  It is
a very good match for Ethernet since the latter is a classic example of a
datagram (connectionless) network. Connection-oriented network protocols
like X.25/75 assume absolute reliability from their lower layers and hence
require link level acknowledgements. These make very little sense on a local
area network with very low bit error rates; they just cause unnecessary
overhead and implementation complexity. Since TCP/IP assumes only an
"unreliable" datagram service from the networks it uses, running it on top
of Ethernet is trivial, and performance is excellent because end-to-end
retransmissions are rarely required.

In a local high bandwidth environment, heroic header-bit-saving measures
like those in X.25 make absolutely no sense. Most Ethernets run at only a
few percent of capacity (ours do, despite several roomsful of VAXes,
Pyramids and Sun fileservers), and bandwith is effectively free while CPU
cycles are not. Ethernet packets must be a minimum of 60 bytes long in order
for collision detection to work, and minimal length (40 byte) TCP/IP packets
still have to be padded out just to meet this requirement.

The way to get performance out of a local area network is by sending big
packets, since processing time is almost independent of packet size with
most protocol implementations. My only real complaint about Ethernet is its
packet size limit; while 1500 bytes is greater than most packet network
limits (128 bytes is typical in X.25 networks), it really ought to be bigger
in these days of 10 megabit coaxes and ultra-cheap memory for buffering.

For an entertaining discussion of this topic, see the chapter in Padlipsky's
book "The Elements of Networking Style" entitled "Slaying the TCP-On-A-LAN
Woozle".

Phil