jdg@dolphy.UUCP (Jesse D. 'The Reverend' Goodman) (10/03/85)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following article was posted a few weeks ago over a lossy net interface. Please accept my sincerest regrets and apoligies if this is a repeat: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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? Especially enlightening would be a comparison with other top contenders such as XNS/PUP, and maybe even X.25 (assuming you were using it already for long haul). Thanks in A. Jesse Goodman Saiph Corp. (that's Saiph as in Fail-Saiph) NY, NY (212)787-3318
karn@petrus.UUCP (Phil R. Karn) (10/07/85)
> 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
jqj@cornell.UUCP (J Q Johnson) (10/08/85)
In article <626@petrus.UUCP> karn@petrus.UUCP (Phil R. Karn) writes: >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". Don't buy that book! Anyone writing a book entitled "The Elements of ... Style" should heed Will Strunk's dictum "vigorous writing is concise. Omit needless words." On that basis, Padlipsky's book would be about 10 pages long. He is a tedious writer, far more concerned with his own ego and with what he thinks (wrongheadedly) to be a cute style than with the subject matter. Granted, he occasionally does have a few useful observations on networking, but they are so buried in the chaff that they are almost totally lost. Conclusion: it's not worth spending your money on. It should never have been published. If you REALLY want to buy it, I'll be happy to sell you my copy at 1/2 list price, since it offends me so.
karn@petrus.UUCP (Phil R. Karn) (10/10/85)
If you don't want to spend money on Padlipsky's book, you can read the chapter in question (TCP-on-a-LAN) as RFC 872. The only things missing are the Prefatory Afterthoughts and the cute cartoon. Phil