That's right. In the case of a download, the receive window can also be visualized as a limit on the number of packets that are allowed to be "in flight" at on

That's right. In the case of a download, the receive window can also be visualized as a limit on the number of packets that are allowed to be "in flight" at once. Shrinking the window is the wrong tool for the job here, like hammering in a screw. It's sensitive to round-trip-time in a way that makes it impossible to equate a given window with a desired speed. A better method might be to monitor download speed and delay ACKs when it exceeds the limit, but traditionally Unix doesn't have a standard API to do this.