Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!ucsd!usc!wuarchive!sdd.hp.com!mips!sgi!rpw3@rigden.wpd.sgi.com From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP Bandwidth limits (was Re: TCP window size restriction) Message-ID: <81030@sgi.sgi.com> Date: 14 Jan 91 02:48:58 GMT References: <9101091020.AA08870@techops.cray.com> <80719@sgi.sgi.com> Sender: guest@sgi.sgi.com Reply-To: rpw3@sgi.com (Rob Warnock) Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 46 In article <80719@sgi.sgi.com> cjohnson@pei.com (Chris Johnson) writes: +--------------- | Well, there is a data rate limit for TCP/IP, | but it isn't window size dependent. +--------------- ...in a zero-delay network. But in the presence of any round-trip delay, TCP *is* rate-limited to approximately one window-size per round trip. For example, on a maximally-configured FDDI network, the idle-net token rotation time is 1.6 milliseconds, or "20,000 bytes". Under some reasonable assumptions (e.g., hosts are very fast, but not infinitely so), one can show that this will limit TCP speed to about (16/(16+20))*12.5 = 6.9 MByte/s for a single connection between a pair of hosts (assuming all other hosts are idle). By sending more than the usual two ACKs per window (usual anti-"silly window" strategy), one can get ACKs for data close to the "end" of the window sent with the same token rotation as the data itself, and data rates closer to 10-12 MB/s could be obtained. (Even with very fast hosts and FDDI interfaces, I assume a few packets near the end on the trasmit burst will not get ACKed in time to go out with the "current" token rotation.) Of course, most FDDI rings will not be "maximally" configured, and will have less idle-ring token delays. But there are other media with substantial delay-bandwidth products (e.g. long-haul lines, satellites), and this is why RFC 1072 was promulgated. +--------------- | The sixteen bit IP id field and the 16 bit max | packet length limit a particular connection | to 4GB/255 seconds or about 16MB/sec. | cj* +--------------- ...iff all packets have an initial TTL of 255. If one knows (somehow) that the true needed TTL is lower (it's usually *much* lower!), the TTL rate limit is higher (usually *much* higher). For example, a TTL of 15 seconds yields a TTL-limited rate of ~286 MB/s. -Rob ----- Rob Warnock, MS-9U/515 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311