Revision history [back]

Below are some observations / thoughts about the case

• Receiver Window size was not "negotiated down from 8192 to 513" but negotiated up from 8192 to 131328 Bytes. Scaling factor is not taken into account for SYN and SYN,ACK packets.

• RTT between endpoints is 200+ms, so this is high-BDP link. Sender-side capture is recorded on the sender itself, therefore we see large packets (offloading engine) of up to 65930 Bytes size which is repeatable throughout many packets. Every large packet contains PUSH flag.

• There is a long gap (up to 33 seconds) of total transmission pause caused by Zero Window Condition:

I don't know is it normal or not - we have to consider what application is this (SSL data transfer).

• There's one episode of packet loss (sender side, from packet no.332), but its effect is not so big compared to total transfer time.
• Now to the most interesting part. The transfer is happening in "send-wait-send.. manner":

The interesting thing is the sender never exceeds 82345 Bytes in flight, which is LESS than available RWIN.

So the questions are:

• Why the receiver doesn't increase it's RWIN? You can try to influence RWIN by playing with auto-tuning settings

  • It may help or not, because the sender anyway doesn't fully uses advertised RWIN. Larger advertised RWIN could potentially cause it to send more. It looks like the software being used for data transfer on sender side has some predefined buffers of two sizes: 64k+ and 82k+. This is a good idea to further investigate sender settings (what software is it and what settings you can influence).

Below are some observations / thoughts about the case

• Receiver Window size was not "negotiated down from 8192 to 513" but negotiated up from 8192 to 131328 Bytes. Scaling factor is not taken into account for SYN and SYN,ACK packets.

• RTT between endpoints is 200+ms, so this is high-BDP link. Sender-side capture is recorded on the sender itself, therefore we see large packets (offloading engine) of up to 65930 Bytes size which is repeatable throughout many packets. Every large packet contains PUSH flag.

• There is a long gap (up to 33 seconds) of total transmission pause caused by Zero Window Condition:

I don't know is it normal or not - we have to consider what application is this (SSL data transfer).

• There's one episode of packet loss (sender side, side trace, starting from packet no.332), but its effect is not so big compared to total transfer time.
• Now to the most interesting part. The transfer is happening in "send-wait-send.. manner":

The interesting thing is the sender never exceeds 82345 Bytes in flight, which is LESS than available RWIN.

So the questions are:

• Why the receiver doesn't increase it's RWIN? You can try to influence RWIN by playing with auto-tuning settings

  • It may help or not, because the sender anyway doesn't fully uses advertised RWIN. Larger advertised RWIN could potentially cause it to send more. It looks like the software being used for data transfer on sender side has some predefined buffers of two sizes: 64k+ and 82k+. This is a good idea to further investigate sender settings (what software is it and what settings you can influence).

Below are some observations / thoughts about the case

• Receiver Window size was not "negotiated down from 8192 to 513" but negotiated up from 8192 to 131328 Bytes. Scaling factor is not taken into account for SYN and SYN,ACK packets.

• RTT between endpoints is 200+ms, so this is high-BDP link. Sender-side capture is recorded on the sender itself, therefore we see large packets (offloading engine) of up to 65930 Bytes size which is repeatable throughout many packets. Every large packet contains PUSH flag.

• There is a long gap (up to 33 seconds) of total transmission pause caused by Zero Window Condition:

I don't know is it normal or not - we have to consider what application is this (SSL data transfer).

• There's one episode of packet loss (sender side trace, starting from packet no.332), but its effect is not so big compared to total transfer time.
• Now to the most interesting part. The transfer is happening in "send-wait-send.. manner":

The interesting thing is the sender never exceeds 82345 Bytes in flight, which is LESS than available RWIN.

So the questions are:

• Why the receiver doesn't increase it's RWIN? You can try to influence RWIN by playing with auto-tuning settings

  • It may help or not, because the sender anyway doesn't fully uses use advertised RWIN. Larger advertised RWIN could potentially cause it to send more. It looks like the software being used for data transfer on sender side has some predefined buffers of two sizes: 64k+ and 82k+. This is a good idea to further investigate sender settings (what software is it and what settings you can influence).

Below are some observations / thoughts about the case

• Receiver Window size was not "negotiated down from 8192 to 513" but negotiated up from 8192 to 131328 Bytes. Scaling factor is not taken into account for SYN and SYN,ACK packets.

• RTT between endpoints is 200+ms, so this is high-BDP link. Sender-side capture is recorded on the sender itself, therefore we see large packets (offloading engine) of up to 65930 Bytes size which is repeatable throughout many packets. Every large packet contains PUSH flag.

• There is a long gap (up to 33 seconds) of total transmission pause caused by Zero Window Condition:

I don't know is it normal or not - we have to consider what application is this (SSL data transfer).

• There's one episode of packet loss (sender side trace, starting from packet no.332), but its effect is not so big compared to total transfer time.
• Now to the most interesting part. The transfer is happening in "send-wait-send.. manner":

The interesting thing is the sender never exceeds 82345 Bytes in flight, which is LESS than available RWIN.

So the questions are:

• Why the receiver doesn't increase it's RWIN? You can try to influence RWIN by playing with auto-tuning settings

  • It may help or not, because the sender anyway doesn't fully use advertised RWIN. Larger advertised RWIN could potentially potentially cause it to send more. It looks like the software being used for data transfer on sender side has some predefined buffers of two sizes: 64k+ and 82k+. This is a good idea to further investigate sender settings (what software is it and what settings you can influence).