This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

RDP of a RDP

0

Hi Folks.....

and thanks for reading my question. First some background:

I have a situation where I have a user in India using RDP to connect to a virtual desktop (VDI on VMWare View) in a data center in the U.S. This works OK. The user then starts a remote control session from the VDI to remote control (via RDP) a Sharepoint server in that same data center. I hope that is clear.

On occasion this runs quite slow. I have captured packets on the VDI so I can see both the connection from the user machine to the VDI as well as the VDI to the Sharepoint server. When looking at the packets with Wireshark I can see that on the TCP connection from the VDI to the Sharepoint server the TCP Calculated Window Size often drops to zero or 100 or 200 bytes (that is what the VDI is advertising to the Sharepoint server). Note this is the LAN connection within the data center. On the other RDP/TCP connection, from the client machine to the VDI, the TCP Calculated Window Size stays at about 64k throughout with only minor fluctuations. This is the WAN connection back to India.

  1. It seems (to me anyway) as if this situation is saying that there is some type of resource shortage on the VDI because it is not processing the received packets quickly enough and therefore sending back the low TCP Calculated Window Size value in the ACKs. Does this sound reasonable? Any ideas on where to look for a potential resource shortage?
  2. Am I reading the situation incorrectly? Any other ideas?
  3. Generally speaking can one TCP connection influence another? Like can what is going on on the TCP/RDP session from the client to the VDI influence the behavior of the TCP/RDP session between the VDI and the Sharepoint server? Up at the application layer are they even aware of each other?

Any feedback would be much appreciated. Thanks, F

asked 25 Oct '11, 08:34

Fredonians's gravatar image

Fredonians
1●1●1●1
accept rate: 0%

One Answer:

1

A small window size usually indicates a resource shortage on the system advertising the small window. This is one of the best indicators for a network engineer to pin a problem to a certain server.

Alas, it's not that easy.

Window Scaling often causes a TCP connection to show window sizes of a few hundred byte. If Wireshark sees the 3-way handshake it observes the window scale factor and calculates the correct window size. The next line in the decode shows the scaling factor.

If Wireshark does not know about the 3-way handshake you still see the term "calculated window size", but the scaling factor is reported as -1 to show an unknown scale factor.

Make sure, that you have recorded the 3-way handshake before interpreting the window size.

If you have the 3-way handshake and are still are at 200 byte window size something is wrong. Here are a few reasons that we found when analyzing network traffic:

  • The server is really out of resources and completely overloaded. In these cases I try to visualize the workload using the Load-Graph in IO-Graphs and collect service response time statistics. This only works for a few protocols.
  • A workstation receives large graphical images (like bitmaps) but the system can not visualize the data as quick as it comes in (caused by a slow bus or low end graphics card). Increasing the systems TCP receive window solved this problem without spending money.
  • Some transparent device modifies the TCP window size while the packet flows through. We have observed this behaviour in several products that manage bandwidths. The devices sometimes use algorithms that go back to the 80-ies or 90-ies. We usually categorize them as snake oil.
  • Installing a virus scanner on a workstation can cause a smaller receive window. Though I have never seen the window size go so small that it creates performance problems.

When analyzing small TCP windows I look at the next few frames in the connection. The system with the small window should send a window update within a few milliseconds, advertising a much bigger receive window. If these window updates are not coming in the sender usually waits several seconds before sending a small packet.

Oh, and one more thing: If you are in India and your server is in the US calculate the optimum window size for this link:

Calculate your bandwidth in Byte per second and multiply by your round trip time in seconds. If this value is significantly higher than 64k you can get better throughput by activating window scaling.

Hope that helps. Keep on hunting!

answered 26 Oct '11, 03:16

packethunter's gravatar image

packethunter
2.1k●7●15●48
accept rate: 8%

edited 26 Oct '11, 03:22