MTU is OK, if MSS/MTU discovery works well. What happens if the ethernet MTU is 1500 and the tunnel MTU is 1400 , and the MTU discover did not work.
In other equipment (Juniper, Netscape, Fortinet, ...) there was the option to re-write the MSS in the TCP discover, so the sender would learn the smallest MTU in the path.
(https://kb.fortinet.com/kb/documentLink ... ID=FD40793
Well I wonder about your TCP session termination at the routers (or not). I fully agree if you test from router to router then the endpoint can only be the routers. Your real file transfer is different. It starts from server1, is routed and encapsulated/decapsulated in the routers, and delivered to server2. The TCP session counters, packet numbers, buffer window size, ack handling, retransmission ... is only handled at the servers. The routers only route, fragment if needed, encode/decode, (normally do not reassemble fragments), the TCP session, at least that's what I expect.
Missing ACK's, resulting in retransmissions and duplicates, can have an enormous effect on the TCP throughput, as the TCP congestion avoidance algorithm reacts to this missing ACKs by reducing the pace at which it will send the next packages. It will gradually (fast or slow depending on the algorithm used) increase that pace until it starts failing again. This can be an unstable process.
The problem at the routers is that a large buffer (bufferbloat) is growing , because a fast network connects to a slower network. (Like on the highway : going from 3 lanes to 2 lanes is usually a problem). Maybe throttling would help: viewtopic.php?t=162533
Using wifi as medium is yet another mismatch with TCP. The TCP congestion algorithms are not fit for that varying medium. For satellite transmission very aggressive TCP congestion protocols are used, mostly executed in dedicated traffic concentrators (called accelerators). Routers do not end and restart TCP sessions, like those concentrators do, AFAIK. I don't know in detail how your tunnel is processed in RoS. The tunnel is often UDP (router-router) , to avoid having two competing TCP-congestion-protocols in the connection. So even if the UDP tunnel is router-router end-to-end, the TCP session is server-server end-to-end.
I had very good experience with the "Expand networks accelerator", this does much more like local ACK to increase the traffic over the link, and reduces delays. (Steelhead from Riverbed was too expensive)
And more practical: what performance do you get when you use a multistream FTP client (like Filezilla) ? Not sure it does segmented: https://whatbox.ca/wiki/Multi-threaded_ ... mented_FTP