A question about ‘kind window size’

Question

Hello All Can someone please help me with the following question

I was watching an excellent video from Shark Fest (2013 I think) by Betty DuBios where she is focusing on the tcp three way handshake and the various flags and options that come out of this.

I understand Windows Size and Window Scaling factor. There was however part of here video which mentioned 'Kind window size' she only touched on this lightly and I did not get a clear sense or its purpose.

I posted an image from the video here to show you want I mean.

I believe it is meant to convey to the other party in the tcp conversation hay I can scale my windows right up to x10 (1024) but prefer x3 (8) as I am under load. Is that the meaning of the 'kind window size' ?

Any advise, most welcome

Thanks Ernie

Answer 1

@EBrant, it's not as sophisticated as you've interpreted it.

Your picture shows the last part of the dissection tree below.

Options: (12 bytes), Maximum segment size, No-Operation (NOP), No-Operation (NOP), SACK permitted, No-Operation (NOP), Window scale
    Maximum segment size: 1400 bytes
    No-Operation (NOP)
    No-Operation (NOP)
    TCP SACK Permitted Option: True
    No-Operation (NOP)
    Window scale: 7 (multiply by 128)
        Kind: Window Scale (3)
        Length: 3
        Shift count: 7
        [Multiplier: 128]

It is an illustrative example of how Wireshark displays the dissection tree. On the topmost line, there is a summary of the TCP Options portion of the TCP header. If you "expand" this line, you get all the options listed, each at its individual line. And if you expand any of these, you get the dissection of the internal structure of that particular option itself. Each option is identified by the contents of its first byte, and the RFC calls that distinctive field "kind" - therefore, the dissector names it the same way.

So the "kind" value for the option "Window Scale" is 3, the total length of the option (i.e. including the kind and length fields) is 3 octets, and the actual value of the payload, called Shift count, is 7. The last line, [Multiplier: 128], is a "pseudo-field" - it is not actually present in the captured frame but the dissector calculates it from the actual contents of the frame (and sometimes also of related frames). In this case, it is the value of 2^7.

The window size scaling factor does not change throughout the session, it is only announced once during session establishment. So the one and only value announced is the one in the Shift count field, which is 10 in your example and 7 in mine. It may possibly depend on the load of its sender, but there wouldn't be any purpose in advertising that the sender could support a different value if its life was easier.