[John Sullivan <jsethdev@xxxxxxxxxxxxxxxxxxxx>]

On Wednesday, October 29, 2014, 6:42:00 PM, Jeff Morriss wrote:
> On 10/28/14 11:12, ?? wrote:
>> Hi ,
>>
>>     If the server does not support 'Window Scale' option, even the
>> client send one packet with WS=256,  I thought the real window size
>> should be consider small than 64K.    But I can see the 'Calculated
>> window size' is larger that 64K on Wireshark1.12.1, is there something
>> wrong ?   the trace file is attached.

> Well remember that on a given TCP connection there are 2 window sizes: 
> that of the client and that of the server.

Technically 6, 3 in each direction. The effective window is the minimum
of the 3 which apply in a particular direction.

There is the receiver's advertised window, which itself is determined
by (according to implementation) the minimum of the receiver's buffer
and its own congestion implementation. (There are receivers that will
open their window wide open to the full buffer from the outset,
others, including current Linux under default but changeable
configuration, which will only open their window to a little more than
they expect the sender's congestion control to be able to exploit. I
guess you could interpret that as 8 (4 in each direction) separate
windows if the receiver is doing that.) The sender is not allowed to
exceed the advertised window, however that is determined by the
receiver.

Then there is the sender's physical window, which doesn't appear on
the wire but is determined by the maximum buffer space the sender is
prepared to allocate. Since it must be prepared to retransmit any data
within the window it must hold all in-flight data in memory until
ACKed.

Then there is the sender's congestion window, to which TCP slow start
applies. Old-style, 3*MSS initially, new-style generally larger,
10*MSS as the current Linux default, other systems may have other
initial defaults (and some local configurations raise it *much* higher
to optimise early thoughput), rising each round-trip by the amount of
ACKed data (so under ideal conditions, doubling each RTT until it hits
one of the other limits or detects packet loss.)

> In this trace the client supports scaling but the server does not. 
> Wireshark (at least the development version I just tried) correctly 
> applied scaling to the client's window but not to the server's window:

If the server doesn't send a Window Scale option, not even with a
scale factor of 1 (indicating it understands, but is not using it on
its own advertised receive windows), then it doesn't understand the
option and the client should assume it doesn't apply. Not that it
*really* matters since the server will simply not be using all of the
client's allowed receive window and the client never had any
expectation that it ought to be receiving a certain amount of data at
any point anyway.

(The one place it might matter is a boundary error condition: if the
server doesn't SYN/ACK the Window Scale option, but nevertheless puts
more data on the wire than the client's window scaled by 1, but less
than the client's window scaled by its own advertised Window Scale
option, the server is technically in error and the client is entitled
(probably even mandated) to drop that data regardless of local buffer
availability.)

Note that an old installation I have here on that attached pcap file,
running Win32 WS 1.2.1 (29141), correctly decodes the client's Window
Scale option but then not seeing a corresponding server option, uses
the raw window for the client from then on. I haven't checked a more
recent (less ancient!) build on that capture specifically (since
pretty much everything does scaling these days it's not something I've
noticed), but if it's now assuming unidirectional scaling it is almost
certainly wrong.

(Note the client initially advertises scale=8 (256), raw window=8192,
which would be 2MB if accepted. Subsequently it advertises nearly the
full 64k raw. Under scale=8 (256), that's 16MB, which is somewhat
unlikely so the client presumably is acting in accordance with a scale
of 1 from then on. Also, at the end, the client's raw window value has
decreased by almost exactly the amount of data the server transmitted,
also indicating no scaling.)

>> > ./tshark -Y "ip.src==192.168.1.200" -Vr /tmp/window_scale_neg.pcapng |grep -i "window size"
>>     Window size value: 8192
>>     [Calculated window size: 8192]
>>     Window size value: 64952
>>     [Calculated window size: 16627712] <<< Scaling applied
>>     [Window size scaling factor: 256]
>>     Window size value: 64952
>>     [Calculated window size: 16627712]
>>     [Window size scaling factor: 256]
>>     Window size value: 64222
>>     [Calculated window size: 16440832]
>>     [Window size scaling factor: 256]
>>     Window size value: 64222
>>     [Calculated window size: 16440832]
>>     [Window size scaling factor: 256]
>> > ./tshark -Y "ip.dst==192.168.1.200" -Vr /tmp/window_scale_neg.pcapng |grep -i "window size"
>>     Window size value: 14600
>>     [Calculated window size: 14600]
>>     Window size value: 11256
>>     [Calculated window size: 11256] <<< No Scaling applied
>>     [Window size scaling factor: -2 (no window scaling used)]
>>     Window size value: 11256
>>     [Calculated window size: 11256]
>>     [Window size scaling factor: -2 (no window scaling used)]
>>     Window size value: 11256
>>     [Calculated window size: 11256]
>>     [Window size scaling factor: -2 (no window scaling used)]
>>     Window size value: 11256
>>     [Calculated window size: 11256]
>>     [Window size scaling factor: -2 (no window scaling used)]


> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe 




John
-- 
Dead stars still burn