Re: Bug in -s -S params?

Bruce Barnett (barnett@birch.crd.ge.com)
Fri, 30 Jul 1999 10:12:36 -0400 (EDT)

> I looked onto the traces of TCPDUMP to observe the Window size ("number of
> bytes of receive buffer space available"), and I found some inconsistency:
> the TCPDUMP Window size is not the same like I set with the -s -S params.! In
> the following table (sorry, a bit long, but at least a detailed one!) one can
> see the relationship between the NETPERF's -s -S parameters and the Window
> size as detected by TCPDUMP:

The specifications of the TCP header only allow 16 bits for the window
size. That means the maximum value the window can contain is 65535.
TCPDUMP will never show a value larger than that in this field.

The Window Scale Option (RFC 1323) is used to overcome this 16-bit
limitation. When the two systems are connecting (i.e. when each one
sends the other a "SYN" packet) there is also a window scale parameter
passed in the TCP OPTIONS field. If the other system understands the
convention, it too will reply with the WS option, indicating that (1) It undewrstands the option, and (2) the factor to scale all window values it sends.
Let me explain how this works.

You didn't include the TCPDUMP values, so I can't tell you what is
really happening, but I suspect there was a "WS 1" as an option during
the SYN packet on both sides during the negotiation. Provide the first
three lines of the TCPDUMP trace and I can confirm this.

If true (WS=1), then all values in the WINDOW SIZE field are shifted to the
left one bit. Therefore the value 32850 is really 32850<<1 or 65700
(you asked for 65536). 34310 with WS=1 is 68620 (you asked for
67584).

As you can see, the Window Scale option causes some lose of precision
in the lower bits, caused by round-up error.