Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!GVAX.CS.CORNELL.EDU!jqj
From: jqj@GVAX.CS.CORNELL.EDU.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  IP Datagram sizes (actually latency vs thruput)
Message-ID: <8705281420.AA09031@gvax.cs.cornell.edu>
Date: Thu, 28-May-87 10:20:21 EDT
Article-I.D.: gvax.8705281420.AA09031
Posted: Thu May 28 10:20:21 1987
Date-Received: Sat, 30-May-87 01:03:17 EDT
References: <7308@cornell.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jqj@gvax.cs.cornell.edu (J Q Johnson)
Distribution: world
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 17

One issue I'd like to see getting more attention in the current discussion
of transaction-parameter negotiation is the latency/thruput tradeoff.  It's
clear that for an ftp-like application all the user really cares about is
thruput, but for the rapidly growing rpc-based style of interaction latency
becomes critical.  My client programs care about the total time between the
dispatch of an RPC request and the response; if I'm going to transfer a
lot of data I'm willing to negotiate a separate channel for that transfer.

No, this is not simply a UDP vs. TCP issue.  Under different circumstances
I might want to use either protocol to carry my RPC traffic, or for that
matter might want a special-purpose protocol tuned for my particular style
of RPC.  There are still some general optimization issues that the IP
community needs to address.

Interested readers should see the discussion of special- vs. general-
purpose networking protocols in the latest Transactions on Computer
Systems (TOCS).