WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") (06/29/89)
Richard, A reading of your RFC gives a good impression on the surface, and in a closed, high-speed network, it would probably be a "good thing" to allow very large windows. However, my concern, from the point of view of running a host with a high volume of ftp activity, is that I don't believe proper window value are being used now, and that opening up the possibility of even higher windows will clog all available bandwidth, especially when several connections are active with several retransmissions in progress. Case in point: there are hosts connecting to us with connections through a local high speed network, which negotiate 8K, 16K, and even 64K windows. What does not appear to be taken into account is that the connections in the middle are at much lower speeds (or the opposite case where the connected net is some medium-to-high speed, but the host connection is at some lower speed). The result is that we try to keep the pipe full as requested, but the inevitable retransmissions are tying up the limited bandwidth for the other connections. Even now I'm not sure we should blindly accept any legal max packet and window size, just because it's legal for a single connection. It seems to me that we should be exercising some overall management of the aggregate of all the connections as to both timely serviceability and available bandwidth on our end. Unfortunately, the only tools we have as a measure are connection-by-connection round-trip times to use to compute retransmission intervals, and, although we seem to be getting closer, it still ignores the overall picture. I guess I'm not ready to accept requests for gigabyte windows when some hosts still don't know a reasonable window to request under 64K now...(not to mention *where* we're going to find the address space to hold the retransmission buffers)... --Frank
chris@GYRE.UMD.EDU (Chris Torek) (06/29/89)
Window size, packet size (MSS), and retransmit times are not all inherently tied together. (Related, yes; inextricably, no.) Retransmit buffer space is (becoming) cheap. One problem with large windows (and small packets) in TCP, though, is that the effect on overall transmission rate of random packet loss is magnified. Other this, the `Jacobson/Karels' (seems to me `Karn' ought to appear here too) algorithms seem to work well in practise with the (admittedly not large) 64 kB maximum windows in 4.3BSD-tahoe (only 1/64th of a megabyte, hence `not large'). Chris
rfox@tandem.UUCP (Richard Fox) (06/30/89)
<of running a host with a high volume of ftp activity, is that I don't <believe proper window value are being used now, and that opening up <the possibility of even higher windows will clog all available <bandwidth, especially when several connections are active with several In the general networking case this is the case. I don't think anybody would like a host to open its window to 100K and try and shovel that much data out onto the internet to traverse arbitrary paths to a destination. At least not now...... But what about the case where a site has a private t1 satellite for there disposal? Running standard tcp over this link even with the window fully opened doesn't fully utilize the link. It utilizes about 50% of the link at best. The users of this link might not really desire to use a link of this nature. At NASA this was the case. There was a t1 ground link and a t1 satellite link to the same location. If the performance of the satellite was not comparable or very close to being comparable to the ground link the users would not use it. To make the satellite link more appealing we needed to make the bandwidth utilization comparable to the ground link. Thus, the use of big windows fits the bill. Now the links can be used in the following ways: ground link is used for telnet type traffic and the satellite is used for bulk file transfers. Notice this was just one example of where big windows can make a difference. With todays networks becoming faster each year the use of bigger windows will become very important. Already some local area networks can support mtus greater than 64K. Thus to fully utilize these networks, big windows will be neccessary. Even if our goal isn;t to fully utilize the lan but just to get "better performance out of them" it might make sense to use an mtu close to the mediums capability and have >64K windows. Another obvious place that big windows will come useful is in the giga-bit bandwidth range. The arguments for this is just an extrapolation of the last argument. Also for a good argument read 1077. <now...(not to mention *where* we're going to find the address space to <hold the retransmission buffers)... This is a good argument. But remember memory is becoming cheaper and cheaper..... we are already starting to make 4meg chips. In a few years it might not be uncommon to see workstations with 32 megs.... Thus buffer space might become just another cheap commodity. A good argument for this can be found in a very recent paper by Craig Partridge that was presented at the INARC last month. Frank, I hope this gives some insight as to why the work was done and to why it might be a very important idea in the near future. I appreciate your comments and would be interested in any follow up. rich