mcrae@mk6vms.nwscc.sea06.navy.mil ("Murl McRae") (07/14/90)
I need to change the TCP window size in WIN/TCP 3.2. Can anyone tell me
if it can be changed and if so, how? Thanks.
Murl McRae Naval Weapons Support Center
Crane, IndianaBILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (07/17/90)
Mumble. Someone has to ask... Just WHY do you want to change the window size (and which one). The window sizes offered by (and to) a system can be carefully thought out by the implementors, and can have serious non-linear effects on performance, thoughput, and even reliability of they are changed very much. There are better ways to solve most problems than changing the window sizes... BillW -------
mcrae@mk6vms.nwscc.sea06.navy.mil ("Murl McRae") (07/20/90)
As requested by BILLW@mathom.cisco.com on 19-JUL-1990 08:31, here is
more information on my WIN/TCP window size question:
The reason I wanted to change the window size was to see if that
would improve our Internet performance. We have a very slow Internet link.
The average roundtrip time is around 1.5 seconds. Our FTP transfer rate is
only about 9.6K bits/sec. With the long roundtrip time we thought a larger
window might help increase FTP throughput so we wanted to change the window
(both send and receive) and run some tests.
Since I posted the orginal message I have found out how to change the
window sizes. I changed the sizes from 4096 to 8192 and we tried a few
transfers. The results were inconclusive. I don't think the performance
changed. I did notice that all of the other hosts in the test had receive
windows around 4K (obviously I am rather green at this stuff), so if we did
get any improvement it would be in one direction only. So it looks to me
like I ought to return the window sizes to 4096 and leave them alone.
Any other sugguestions on improving performance on a slow link would
be appreciated. Our current link into MILNET is via sattelite. We are
working on getting a land line, but that may take a while. Thanks.
Murl McRae Naval Weapons Support Center
Crane, Indianamogul@wrl.dec.com (Jeffrey Mogul) (07/20/90)
In article <12606340619.9.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes: >Mumble. Someone has to ask... Just WHY do you want to change the window >size (and which one). The window sizes offered by (and to) a system can >be carefully thought out by the implementors, and can have serious non-linear >effects on performance, thoughput, and even reliability of they are changed >very much. There are better ways to solve most problems than changing the >window sizes... One reason to change the window size is if the segment size changes, perhaps as a result of Path MTU Discovery. Van Jacobson has pointed out that the flow-control window size had better be an exact multiple of the segment size, or performance will suffer. I've drafted a few paragraphs on this topic for inclusion in the forthcoming RFC on Path MTU Discovery. In fact, I invite people to comment on their wording. (The rest of the document is draft-ietf-mtudisc-pathmtu-01.txt at the usual place.) Thanks -Jeff (To be inserted at the end of section 6.4, "TCP layer actions"): Modern TCP implementations incorporate ``congestion advoidance'' and ``slow-start'' algorithms to improve performance@cite[Jacobson1988]. Unlike a retransmission caused by a TCP retransmission timeout, a retransmission caused by a Datagram Too Big message should not change the congestion window. It should, however, trigger the slow-start mechanism (i.e., only one segment should be retransmitted until acknowledgements begin to arrive again). TCP performance can be reduced if the sender's maximum window size is not an exact multiple of the segment size in use (this is not the congestion window size, which is always a multiple of the segment size). In many system (such as those derived from 4.2BSD), the segment size is often set to 1024 octets, and the maximum window size (the ``send space'') is usually a multiple of 1024 octets, so the proper relationship holds by default. If PMTU Discovery is used, however, the segment size may not be a submultiple of the send space, and it may change during a connection; this means that the TCP layer may need to change the transmission window size when PMTU Discovery changes the PMTU value. The maximum window size should be set to the greatest multiple of the segment size (PMTU - 40) that is less than or equal to the sender's buffer space size. PMTU Discovery does not affect the value sent in the TCP MSS option, because that value is used by the other end of the connection, which may be using an unrelated PMTU value.