Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!VENERA.ISI.EDU!CASNER
From: CASNER@VENERA.ISI.EDU (Stephen Casner)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP performance limitations
Message-ID: <559937528.0.CASNER@VENERA.ISI.EDU>
Date: Tue, 29-Sep-87 14:12:08 EDT
Article-I.D.: VENERA.559937528.0.CASNER
Posted: Tue Sep 29 14:12:08 1987
Date-Received: Thu, 1-Oct-87 04:27:47 EDT
References: <8709290454.AA24282@venera.isi.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 25

Karl,
	For all the variables you mention, you've specified values that
would pose no limit to TCP performance.  However, you left out one
critical variable:  delay.  If the bandwidth and processing power are
infinite, the sender will immediately transmit as many octets as the
receiver's window will allow.  The sender cannot transmit any more until
an ACK is returned, and the receiver cannot send an ACK until the data
gets there.  Therefore, the maximum throughput is one window's worth of
octets every round-trip delay time.

	The window size is determined by the amount of buffer space
available in the receiver.  If you assume buffer space is also
unlimited, then you bump into the first real limit:  the maximum TCP
window size is 64K octets because it is carried in a 16-bit field.  To
cite a real example, the Wideband Satellite Network has a raw data rate
of 3Mb/s, but it also has a round-trip delay time of 1.8 seconds.  The
maximum TCP throughput is 64K octets per 1.8 seconds or 290Kb/s.

	There have been proposals by the INENG Task Force and others to
define a TCP option to carry a larger window-size field.  If you assume
this option field could be as large as necessary, then the only limits
left are physical:  the speed of light and the distance between hosts.

							-- Ste.

A with t time
r