Window Scale option

[David Borman <[e-mail]>]

There is a change that I would like to add to RFC 1323 about
the Window Scale Option.  The current text on page 10 has:

      *    The connection state is augmented by two window shift counts,
           Snd.Wind.Scale and Rcv.Wind.Scale, to be applied to the
           incoming and outgoing window fields, respectively.

      *    If a TCP receives a <SYN> segment containing a Window Scale
           option, it sends its own Window Scale option in the <SYN,ACK>
           segment.

      *    The Window Scale option is sent with shift.cnt = R, where R
           is the value that the TCP would like to use for its receive
           window.

      *    Upon receiving a SYN segment with a Window Scale option
           containing shift.cnt = S, a TCP sets Snd.Wind.Scale to S and
           sets Rcv.Wind.Scale to R; otherwise, it sets both
           Snd.Wind.Scale and Rcv.Wind.Scale to zero.

I'd like to change this to:

      *    The connection state is augmented by two window shift counts,
           Snd.Wind.Scale and Rcv.Wind.Scale, to be applied to the
           incoming and outgoing window fields, respectively.

!     *    When sending a <SYN> segment, the Window Scale option is
!          sent with shift.cnt = R, where R is the value that the TCP
!          would like to use for its receive window.

!     *    If a TCP receives a <SYN> segment with a Window Scale option
!          containing shift.cnt = S, it sends its own Window Scale option
!          with shift.cnt = R in the <SYN,ACK>.  If R has not been set by
!          the application, either explicitly or implicitly by changing
!          the receive buffer space from its default value, a TCP may set
!          R = S before generating the <SYN,ACK>.  The TCP then sets
!          Snd.Wind.Scale to S and sets Rcv.Wind.Scale to R.

!     *    Upon receiving a <SYN,ACK> segment with a Window Scale option
           containing shift.cnt = S, a TCP sets Snd.Wind.Scale to S and
           sets Rcv.Wind.Scale to R; otherwise, it sets both
           Snd.Wind.Scale and Rcv.Wind.Scale to zero.

I have implemented this in both UNICOS and BSD/OS, with no ill
effects.  The reason for wanting to recommend turning around the
scale value is that it can only be negotiated during the initial
3-way handshake, and on the passive side, the application that is
doing the listen()/accept() may not be the one that knows that the
receive buffer should be increased to get the a window scale value
sent as non-zero.  E.g, it is inetd that accepts the connection,
which then execs rshd, which in turn execs rcp, which is the
application that knows we're doing a bulk data transfer so the
buffers should be made larger, but by then its too late.  One way
to address this is to modify inetd to allow it to set the receive
buffers large for rshd.  However, rshd is used for other things
besides rcp.  If the receive buffers are made large in inetd, and
the application changes them back to the default values, then you
have an outstanding advertised window from the initial window when
the buffers were larger, which TCP can't retract.

		-David Borman, [e-mail]