Analyzing slow file transfers

The 'poor' performance is caused by packet loss.

The Bandwidth Delay Product BDP determines how fast your SMB write can be.
The RTT is around 131 ms and the bandwidth seems to be limited to 48Mbps so you will be able to transmit at full speed when you have an open window of a 780000 bytes. Assuming the Window-Scaling factor from the SMB Server was 64 it can be seen that it is not the window_size offered by the receiver that is slowing you down but the congestion window at the sender caused by packet loss and required re-transmissions.

In the graph below you can see the number of bytes_in_flight dropping after SACKs were received indicating a GAP was detected at the receiver.

So - as Sindy pointed out - a 0% packet loss rate in pings doesn't really tell much about the packet loss on your TCP session. When this all started to get slow a week ago, something in your network must have changed

Not sure I understand exactly what you mean by "Continuation to #679", because I cannot see anything like that in your capture. Can you give the order number (the leftmost column of the packet list pane) of a frame (packet) in the capture where you can see this "Continuation to #679"?

But leaving that aside, I'd say that the root cause of your transmission slowdown is very simple: high packet loss causes frequent need for retransmissions, and the path delay causes the negotiation of these retransmissions to slow down the resulting transmission speed (because it takes long for the sender to learn that a retransmission is necessary). As the path delay is really high at an inter-continental link, the resulting slowdown is really high too.

Now why you can see "a million times the same ack number" is because Wireshark's tcp analysis and default coloring rules take care only about ack numbers and ignore the SACK values. So if you take a closer look at those packets with the same ack number (which is the reason why Wireshark marks the packet with black background and "Dup ACK" text), you'll see that while their ack number stands still, indicating to the sender the position in the session data after which the loss began, the SLE and SRE values keep changing, telling the sender which parts of the session data after the lost part(s) have been received, i.e. that those data need not be retransmitted.

See more about how SACK works in this illustrative blog post.

Another point is that the calculation of relative seq numbers is not synchronised between the two directions of the session because the tcp session establishment is missing in the capture. So to be able to match seq and ack between directions properly, you have to switch over to absolute seq values, which are far less comfortable to read but the only real ones.

When you do so, you can see that: the last packet which has been delivered successfully is in frame 864, with relative (to the beginning of the capture) time 7.05 seconds. The one which has been lost follows it almost immediately, in 18 μs. Now the first packet informing about the loss (in frame 1299) has arrived some 160 ms later. So the missing packet is retransmitted in frame 1305 (relative time 7.217205), but it takes until relative time 7.350896 (i.e., another about 130 ms) that its reception is confirmed. In the meantime you can therefore observe those "million acks" coming at a rate of several packets per millisecond. But it is still not the end of the story because even the packet confirming reception of the one in frame 1305 contains SLE and SRE, meaning that the receiving side still has gaps in what has been received.

When you apply a display filter tcp.stream == 1 and tcp.analysis.duplicate_ack and scroll through the packet list pane, you'll find that there were several events like that during that session, each contributing at least 150 ms (but often more) to the operation completion time.