Windows Scaling Issue

Question

I have an affiliate uploading files to one of our web servers and it's running slow according to them. They're network is Juniper SRX firewall to Bluecoat ProxySG to our Fortigate. They did a capture on the Bluecoat and sent me their capture file. They're saying that they are using scaling windows but that we are not. From what I researched with the scaling factors and their capture file, I can confirm that we actually are doing scaling windows and maybe a server issue?

From them to us...

Frame 6318: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: Invertex_0c:89:ee (00:d0:83:0c:89:ee), Dst: Netscreen_ff:10:05 (00:10:db:ff:10:05)
Internet Protocol Version 4, Src: 150.198.1.221, Dst: 69.25.25.67
Transmission Control Protocol, Src Port: 65189, Dst Port: 443, Seq: 1337, Ack: 16094, Len: 0
    Source Port: 65189
    Destination Port: 443
    [Stream index: 424]
    [TCP Segment Len: 0]
    Sequence number: 1337    (relative sequence number)
    Acknowledgment number: 16094    (relative ack number)
    Header Length: 32 bytes
    Flags: 0x010 (ACK)
    Window size value: 63156
    [Calculated window size: 63156]
    [Window size scaling factor: 1]
    Checksum: 0xf725 [unverified]
    [Checksum Status: Unverified]
    Urgent pointer: 0
    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 6317]
        [The RTT to ACK the segment was: 0.000119999 seconds]
        [iRTT: 0.020690000 seconds]

Next packet from us to them:

Frame 6319: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)
Ethernet II, Src: Netscreen_ff:10:05 (00:10:db:ff:10:05), Dst: Invertex_0c:89:ee (00:d0:83:0c:89:ee)
Internet Protocol Version 4, Src: 69.25.25.67, Dst: 150.198.1.221
Transmission Control Protocol, Src Port: 443, Dst Port: 65189, Seq: 16094, Ack: 1337, Len: 1448
    Source Port: 443
    Destination Port: 65189
    [Stream index: 424]
    [TCP Segment Len: 1448]
    Sequence number: 16094    (relative sequence number)
    [Next sequence number: 17542    (relative sequence number)]
    Acknowledgment number: 1337    (relative ack number)
    Header Length: 32 bytes
    Flags: 0x018 (PSH, ACK)
    Window size value: 31
    [Calculated window size: 7936]
    [Window size scaling factor: 256]
    Checksum: 0x5c8e [unverified]
    [Checksum Status: Unverified]
    Urgent pointer: 0
    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
    [SEQ/ACK analysis]
        [iRTT: 0.020690000 seconds]
        [Bytes in flight: 1448]
        [Bytes sent since last PSH flag: 2896]
    TCP segment data (509 bytes)
    TCP segment data (939 bytes)
[12 Reassembled TCP Segments (16437 bytes): #6280(1448), #6283(1448), #6289(1448), #6292(1448), #6293(1448), #6300(1448), #6304(1448), #6305(1448), #6312(1448), #6316(1448), #6317(1448), #6319(509)]
Secure Sockets Layer

Answer 1

There are several things to look at. First, to "use window scaling" may mean two things:

to use the "window size scaling factor" TCP option field during session establishment phase, indicating that you support the window scaling mechanism,
to announce a window size multiplier different from 1 in that TCP option field.

Your two packet dissections indicate indirectly that both the server and the client have declared support of window size scaling mechanism as the scaling factor differs from 1 in at least one of the directions (the one from the client). But as it is 1 in the packet sent by Fortigate to the Bluecoat, either your server or the Fortigate have decided to use a scaling factor of 1 which is equivalent to not using it in the sense of point 2., limiting the throughput in networks with higher round trip times.

The next thing to look at is whether this behaviour comes from your server or from the Fortigate, so you should capture on the path between them (in worst case, at one of them but on the interface looking towards the other one) to see whether it is not the Fortigate box which reduces the maximum window size this way, e.g. to make its life easier when doing deep packet inspection.

When you find out which of the boxes is responsible for using a window scaling factor of 1, you can start finding out why it does so and whether that can be changed.

Answer 2

Even though window scaling is used (as can be seen in the scaling factors in the two packets), it does not mean that the actually used Receive Window will be increased in size. It just means that the window size field has some extra bits to allow for larger values.

In the packet send from you to the client, the calculated value is only 7936. Does this value increase during the upload? What is the largest value seen? You might have to re-configure the Maximum Window Size value in your TCP stack. Please note however that on a server, there are a lot of open connections, so setting the value too high could result in a lot of memory being reserved for all the buffers.