Path: utzoo!mnetor!uunet!seismo!esosun!ucsdhub!sdcsvax!gillies@uiucdcsp.cs.uiuc.edu
From: gillies@uiucdcsp.cs.uiuc.edu (Gillies)
Newsgroups: comp.os.research
Subject: Re: TCP or UDP for IPC.
Message-ID: <4856@sdcsvax.UCSD.EDU>
Date: 15 Apr 88 05:31:00 GMT
Sender: nobody@sdcsvax.UCSD.EDU
Lines: 28
Approved: comp-os-research@ucsd.edu

Here are some interesting papers to read:

1.  "Implementing Remote Procedure Calls", ACM TOCS (1984, I believe).
Investigates the limits of tuning a datagram-type protocol for
implementing remote procedure calls on 3Mbps Ethernet / Dorado
computer.  The authors use some very hardware and protocol-specific tricks.

2.  "Gaining Efficiency through Appropriate Choices in Network
Protocol Design and Implementation", ACM TOCS (1986 -- not sure about
entire title).  This paper talks about how to get high performance
without modifying the protocol, your ethernet hardware, or
specializing your O/S.  It is the opposite of paper (1).

3.  It's very hard to compare the overheads of TCP and UDP, because
the protocol designs are almost NEVER the bottleneck (it's usually the
O/S implementation or ethernet hardware).  Most modern operating
systems (e.g. UNIX) are horribly bad places to implement an efficient
protocol.  If you don't believe me, you should hear the talk: "Why
Computer Networks DontGoFast!" by D.D.  Clark, M.I.T.  Lab for C.S.
They have developed a TCP implementation capable of sustaining 1.1
megabits/sec of on a PC-AT.  Currently, the implementation spends
60% of its time nursing the inefficient 3COM ethernet board, and would
go faster with better hardware.

One exception to the "Don't blame the protocols" rule is satellite
communication: The MIT group has developed new protocol called NetBlt
to deal with its latency problems: It has been clocked at 1.3-1.4 Mbps
on a PC-AT.