Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!decwrl!bacchus.pa.dec.com!mogul
From: mogul@wrl.dec.com (Jeffrey Mogul)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: WIN/TCP Window Size
Message-ID: <1990Jul20.014319.28247@wrl.dec.com>
Date: 20 Jul 90 01:43:19 GMT
References: <mcrae@mk6vms.nwscc.sea06.navy.mil> <12606340619.9.BILLW@mathom.cisco.com>
Sender: news@wrl.dec.com (News)
Organization: DEC Western Research
Lines: 51

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.