What's causing the performance issue with Citrix here?

edit

Hi, is the packet-loss from Client to Server or from Server to Client? in which Trace-File and what sequenz-number can I find it? thank you in advanced.

There is packet loss in both directions. But I think I saw more loss from the client to the server that the other way around.

One instance of loss that had a significant duration can be found at frame #8008 of the file WS004013_00002_20190429100000. The data sent from 10.1.15.19 from frame #7990 onwards does not get an ACK until frame #8018, which is 2,1 seconds after frame #7990 was sent.

And by the fact that it did not send any DUP-ACK's or D-SACK messages, you can deduct that it did not receive any of the earlier packets and was just acknowledging the retransmission in frame #8017.

Too bad the server trace was not started yet at this point. It would have been nice to be able to confirm that from the server side.

do you mean those file "WS004013_00001_20190429095237"

Yes, I did. I edited my comment to point to the exact file :-)

Were you able to pinpoint this issue two years ago? If so, do you remember what he cause was so we can learn from it too?

will it be helpfully to upload Trace File?

will it be helpfully to upload Trace File?

Yes.

Uploading trace files is always helpful. In your case a trace from other side is more helpful, as client itself won't observe fragmented packets and we'll need to look for another 'signs'. Also it'd be helpful if you add any details about the network path - devices, technologies in use etc.

I have Client and Server side Trace Files both have round about 44 MB how can I upload?

You may use any public file-sharing service.

There does not appear to be any IP fragmentation of TCP segments, so the "don't fragment" flag not being set is irrelevant here.

ok, thank you very much for your diagnostic. Have you detected any other issues in the Trace Files?

(!) Please remove and re-do captures filtering out SMB (TCP port 445) because you've exposed seemingly sensitive SMB traffic in there containing scans (client-side capture).

As for other issues:

• There is no TCP 3-way handshake captured, whereas it contains some very useful info for diagnostics. So it's better to capture connection start process.
• Please narrow capture time span and clarify what the issue looks like (is it constant, periodic etc.) or specify time when issue was observed.

Now I see 1 strange thing: client is using small TCP segments of 536 Bytes segment length which could be a sign of MTU problems. But this needs to be checked further.

I have uploaded the Trace with the TCP-3-way handshake (WS004013_00001_20190429095237) please be informed that the capture output option was set to "create a new file after..." 1 hour.

you can filter out smb traffic it only affects Citrix Traffic TCP-Port 2598 or use Conversation Filter: (ip.addr eq 10.1.15.19 and ip.addr eq 172.16.59.31) and (tcp.port eq 49938 and tcp.port eq 2598)