This is kind of a theoretical answer, providing background to understand the problem:
From what you write, I assume you do not want to hear the answer "Get the connection fixed!", right?
So let's see what else we can do:
A large fraction of the packages are lost. The purpose of TCP/IP (Transmission Control Protocol) is to give you a connection that delivers data that is exactly what was send, and in the same order. You still get this from the connection in perfect quality, as long as the connection is not dropped.
But, obviously there is a compromise - the connection is slow.
Because it's really difficult to simulate a perfect connection over a connection that looses about 12% of it's data in some irregular way.
We do not expect magic, so some compromise needs to be accepted.
One could ask whether it's possible to use something else that does what TCP/IP does, but faster.
For a general solution, we can just assume that TCP/IP nearly optimal, because lots of research over lots of time was spend on it.
(With a special solution for you connection, developed based on measurements on the connection, it can be faster for sure, and even faster if you use hardware adapted to your connection - but that direction makes not much sense here)
Now, all we can do is look for a different compromise:
The other end of the scale of compromises is a very fast connection, with - 12% package loss.
That is what you have if you do not use TCP/IP, but UDP/IP (User Datagram Protocol), which transfers separate packages for you, and gives no guarantee that they arrive in order, or at all.
In theory, you could have compromises with less package loss, and slower, in between, build on top of UDP/IP. But in many cases, only TCP/IP makes sense.
So, the practical anser is: "Get the connection fixed!"
Some practical notes:
Regarding why the connection get's slow: TCP can recognize when it sends too many packages, and slow down, but I do not think that's what is happening here.
Loosing packages is a very different problem compared to sending too many packages.
I think the time is spend on retransmitting lost packages, and waiting for missing packages in between, that need to be delivered befor others that were already received.
As you did not say which kind of data you want to transfer: There are good reasons to prefer 12% packet loss over UDP/IP for some use cases:
It you transfer real time video from a camera, you only care about packets that arrive in time to be displayed on the screen. With TCP, the data would arrive complete and in order, but unuseable, because too late. Getting 88% of a video stream right in time is a lot better, it can even be enough for a good transmission.