Troubleshoot large number of TCP retransmits / dup ack / segment lost

Question

I have a problem with RDC slowing to a crawl or disconnecting entirely. Client is XP SP3 w/ RDC 6, server is Win 2k8 R2. Both have been scanned thoroughly and found to be virus free.

I downloaded and installed Wireshark on the client computer and ran a packet capture during an RDC session. The log showed at least 10-20 retransmit / dup ack /segment losses per minute during normal usage. Then, when I had a disconnect, it shot up to dozens of these per second.

FYI, I know very little about the Wireshark tool or how to do a full analysis of this problem.

** EDIT **

A little about my network architecture:

Client -

• 12 Mb down, 1Mb up
• 1 laptop directly connected to the modem -or- (I've tried it this way with no change) plugged in through a Linksys DSL phone box
• Located in Israel. Telecom services are split into infrastructure and ISP there, infrastructure is provided by HOT, ISP is provided by Netvision.

Server -

• 5 Mb down, 5 Mb up
• Medium web/data/app hosting network, routed with Allied Telesyn AR410
• Located in CA (US). ISP is Call America.

Other remote clients have no issues connecting to the servers (either speed or disconnects). Several other laptops have been used at the client location to verify it is not a hardware issue. The cable modem has also been replaced.

Answer 1

Probably not enough information, but here is some general guidance:

If other remote clients are ok and do not experience the symptom, the problem probably is not with the server. It may be the connection for that client.

A retransmit typically means that a packet was not acknowledged, so there usually will not be actual "errors" in a packet capture. It means that one end was sending the packets, and the other was not acknowledged. You may want to perform the capture from both ends, to determine if the retransmit is one-way only, or both ways.

If you ping your host from the client, what is the response time? If it is over 150 ms, you may have a suboptimal connection.

The server network adapter setting for Large Send Offload should be disabled. Windows should be smart enough to know it cannot send large packets to machines on different subnets, but sadly this is not always the case. If your server is a hyper-v guest, this is almost certainly the problem.

MTU. Generally speaking, accessing a server remotely when you are not on the same subnet, the MTU should always be whatever the smallest MTU is between the two endpoints. And that usually means the client. For remote clients that connect over VPN, it is not uncommon to have an MTU of 1400 or even lower. It can be beneficial to set the server MTU to match what the lowest MTU would be, to avoid issues where MTU cannot be discovered properly (sometimes referred to as black hole routers). To find the MTU for your connection you can enter the following command from your client:

ping -f -l xxxx <server ip>

Where xxxx is the MTU size. Start with 1400. If it works, increase it until it displays the message "Packet needs to be fragmented but DF set". If 1400 does not work, decrease it until it does. The highest number that works is your payload size. Add 28 to the payload size and that is your MTU.

You can set the server MTU at the following registry location:

HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{guid of the network adapter}  

FYI - RDP packets are always sent with the "Do Not Fragment" bit set.

Answer 2

You are receiving the following packages:

1. TCP Retransmits
2. Duplicate ACK
3. Segment lost

If you receive a TCP retransmit, this is because the ACK you have sent was not received by the server. The server was not aware the TCP packet was received, thinks it was lost underway and will send it again.

The duplicate ACK is typically received at the Sender in the following scenario:

• Receiver receives packet 1
• Receiver sends ACK for packet 1
• Receiver receives packet 3
• Receiver sends ACK for packet 1 (maximum packet sequence number received). This is a Duplicate ACK for the Sender.
• Receiver receives packet 4
• Receiver sends ACK for packet 1 (maximum packet sequence number received). This is a Duplicate ACK for the Sender.

The third error (Segment Lost) is exactly this scenario, but at the Receiver side. It indicates packet 3 was received before packet 2.

All these errors indicate congestion: somewhere along the way packets are dropped. This can have a lot of causes, so we really need a good indication of your network architecture to be able to tell you what the cause is.

Normally, congestion is not a bad thing. TCP is made to automatically adjust to this scenario, increasing transfer rate until packet drops / slowdown starts to occur. The fact that congestion poses problems here can have a number of different causes:

1. Your network is so congested it cannot handle the minimum required transfer rate for RDP. This would be the case for a 2G cell phone connection.
2. The algorithms in server or client are badly configured. Some ADSL "optimizer" programs can cause this, messing with the parameters of the Vegas TCP algorithm in Windows.
3. There is some other error (very high load on server or client, bad firmware/driver for network card, ...)