Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!sdcsvax!ucbvax!QUABBIN.SCRC.SYMBOLICS.COM!DCP
From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP performance limitations
Message-ID: <870929090456.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Tue, 29-Sep-87 09:04:00 EDT
Article-I.D.: KOYAANIS.870929090456.5.DCP
Posted: Tue Sep 29 09:04:00 1987
Date-Received: Wed, 30-Sep-87 07:13:51 EDT
References: <AUERBACH@CSL.SRI.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 7

Given your assumptions, TCP is not the limitting factor.  The limitting
factor are rate at which producers can produce data and consumers
can consume it.  It is quite easy to multibuffer TCP, and I suspect most
implementations have.  Given the horsepower of the consumer and the
producer, and the channel bandwidth, and the multibuffering methodology,
you can probably calculate the minimum window size that ensures the pipe
will always be full.