Hello - this one has been puzzling me for some time. I frequently RDP to the office from home via 3 different methods: site to site VPN, client VPN, and Citrix RDP. There is no difference in behavior between the three methods, nor is there a difference in behavior if I RDP from different home machines, or target different machines at the office (even on different subnets. What happens is the latency substantially increases in the afternoon, however only via RDP. Users in the office do not see this, there is no bandwidth issue at the office. Nor is there anything that runs in the afternoon. This has been going on for months. Wireshark reveals on the destination that the source is constantly sending duplicate ACKs, perhpas 6-10 of them in response to a TPKT continuation packet. The ACKs are in rapid succession, time differences are in the 10000th of a second. These happen every 1/2 to 1 second. Anyone have any ideas? I've updated NIC drives on both ends and again, only happens via RDP. If I'm in the office, I can run WS all day and don't see these, same thing from my home machine to any other destination. asked 05 Feb '14, 13:14  DB13 showing 5 of 6 show 1 more comments |
One Answer:
The TCP session is using SACK and your client is reporting gaps indicating packets are dropped in the network. The amount of traffic is certainly not something to cause those packet losses so it must be something else going on here. Segmentation Offload is also enabled at the server side. filter: As this only occurs over the WAN in the afternoon and other protocols (non-RDP but also TCP?) are ok at the same time I suspect some kind of traffic shaping occurring here. Maybe you talk to your network folks and have them bump up the priority (ip.dsfield) of your tcp 3389 traffic before the packets enter the VPN. Maybe also disabling TSO at the server side might be of help here . answered 06 Feb '14, 23:42  mrEEde Hi - thanks for the reply. We do not have any QoS policies in place, so there is no traffic shaping occurring. I have a 50 Mbps line at home, and we have a 200 Mbps line at the office, typically we don't have any bandwidth issues. I've checked the circuits during the problem times and they are not maxing out. Just not sure why there would be packet loss at all. (07 Feb '14, 07:11) DB13 "...why there would be packet loss at all" is the question indeed. You need to identify where the packets are lost by tracing at multiple points simultaneously. (07 Feb '14, 07:22) mrEEde sometimes packet loss could happen on a line which uses only 1% of the bandwith. Watch out for microburst. (18 Apr '15, 11:53) Christian_R |
Do those ACKs have the same IP ID?
I'm trying to find out how to see that info, but do not see it in the break down. Is that exclusive to WS?
Just open the IP layer in Wireshark. The IP ID is one of the fields.
Got it. No, each one is sequentially increasing in value. What does that indicate?
Consecutive frames with the same IP ID could have indicated a loop somewhere.
Is it possible to post the capture file (Google drive, dropbox, cloudshark.org)?
Sure, here it is. http://www.cloudshark.org/captures/f4383a0d23cd
A loop would extremely surprising. Also note that going the other way, from work to home, I do not see this behavior on either side - no duplicate ACKs...