alo@kampi.hut.fi (Antti Louko) (01/03/91)
This is a crazy idea I have been thinking of. As we all know, the window field in the TCP protocol is 16-bit and can thus represent only values 0 .. 65535. This limits the available bandwidth of a single TCP connection to 65535/T octets/second. With 1 second round-trip-delay we can get at most 64 Kbytes/second. The solution I have in mind is as follows: TCPs at each end agree a new meaning for window sizes 65520 .. 65535. 65520 means window size 2^(65520-65504) = 2^16 65521 means window size 2^(65521-65504) = 2^17 etc. 65535 means window size 2^(65521-65504) = 2^31. Please remember that this has to be agreed by both TCPs. Please comment! Antti Louko (alo@hut.fi)
alo@kampi.hut.fi (Antti Louko) (01/03/91)
In article <1991Jan2.162810.6356@santra.uucp> alo@kampi.hut.fi (Antti Louko) writes: I said: >This is a crazy idea I have been thinking of. Idea itself is not so crazy, but there are problems and it needs thinking. I was kindly enlightened by mckenzie@bbn.com to look at RFCs 1110 and 1185 which indeed have things discussed quite thoroughly. This restriction in TCP bandwidth came up in one seminar where some OSI people were bashing Internet protocols. At that time, RFC1185 hasn't come out, and I didn't check again... (shame on me) Anyway, now I can tell that TCP will have a solution before OSI :-) Antti Louko
cpw%snow-white@LANL.GOV (C. Philip Wood) (01/03/91)
What if you were to send more than one packet at a time. Like 1600 packets before requiring an ACK. In other words bump the window you can send into. Phil
fab@md.interlink.com (Fred Bohle) (01/03/91)
Window size expansion has already been covered by RFC 1072. An option code of 3 gives a shift amount for the 16-bit window field. Note that other parts of RFC 1072 have not been generally agreed to, but *this* part of it is. It is a simple matter to generate this option in the open logic and look for it from the other end. Then simply shift the window the specified amount to use expanded windows. Note also that both ends must specify the option in order for either side to use it. One side may specify a shift amount of zero, in order to indicate support, but no expanded window. Some brain-dead TCP implementations may hiccup at an unrecognized option code, but they are non-compliant if they do. RFC 1122 says in 4.2.2.5 "A TCP MUST ignore without error any TCP option it does not implement..." So please explore using RFC 1072 for your needs. I put it into our product, SNSTCP/access, and it works fine. Fred ------------------------------------------------------------------------ Fred Bohle EMAIL: fab@leo.md.interlink.com Interlink Computer Sciences AT&T : 301-317-6600 9145 Guilford Road, Suite 175 Columbia, MD 21046 ------------------------------------------------------------------------
mni@techops.cray.com (Michael Nittmann) (01/09/91)
Happy someone pointed out here that tcp/ip is limited to 64kB/sec transfer speed! I always doubted my numbers here for xfer speeds. Thanks a lot for the enlightment, Antti! Michael -------------------------- This NEEDS a disclaimer: this is my PRIVATE, own opinion!
thomas@uppsala.telesoft.se (Thomas Tornblom) (01/10/91)
In article <9101091020.AA08870@techops.cray.com> mni@techops.cray.com (Michael Nittmann) writes:
Happy someone pointed out here that tcp/ip is limited to
64kB/sec transfer speed! I always doubted my numbers here for
xfer speeds. Thanks a lot for the enlightment, Antti!
Say what??? This must be utterly wrong!
--
Real life: Thomas Tornblom Email: thomas@uppsala.telesoft.se
Snail mail: Telesoft Uppsala AB Phone: +46 18 189406
Box 1218 Fax: +46 18 132039
S - 751 42 Uppsala, Sweden