That's not quite right. The most common problem with (especially, but not only) DSL is bufferbloat, where you fill up your upload buffers, and this greatly increases RTT. Then your ACKs in response to downloaded content will take a long time to get through the queue and tell the server it's okay to send more data. You would have to have a truly tiny upload speed limit (like 0.01 Mbps) for the actual ACK throughput to be the limiting factor.
You can work around bufferbloat if you have a DSL modem with fq_codel (rare), or if you insert a router with a rate limiter and fq_codel, so basically you never fill up your DSL modem's queue.
Ah. What I posted is my assumption of what was going wrong. Buffer bloat makes sense. Thanks.
I 'solved' it by going to a provider with more upstream (cable) then later fiber. Even without this issue the download speed wasn't very good for the price so leaving was an easy decision.
You could also use μTP for transfering the data to a rented server and then from there to wherever you need. That protocol is designed to fill the pipe as much as possible, i.e. never let it dry out, while bloating the buffer as little as possible, by basically doing minimum one-way ping measurements and then using a target delay that is choosen so that the minimum delay is never actually hit. it does slow down internet browsing though, so you have to be carefull if there are other users who like to complain. the bandwith is not affected and it does yield to tcp though.
You can work around bufferbloat if you have a DSL modem with fq_codel (rare), or if you insert a router with a rate limiter and fq_codel, so basically you never fill up your DSL modem's queue.