Hmm if i understand this right, you probably don't need a window at all.
If the current downloads are slow because of the inefficient error correction algorithm, then if you just send all the blocks out as fast as you can (without impairing the servers bandwidth required for players! I imagine something like specifying your servers bandwidth in the config file when you are setting up your server, and then taking the number of connected players, multiplying that by a safe average bandwidth requirement per client, subtracting that from the specified bandwidth in the cfg, then further dividing that by the number of clients in the downloading state) and quench slightly if you get excessive numbers of missing ACKs (e.g. if you have 1kB blocks, if you receive < (transmit rate in kBps)/2) a second), and the multiple-passes will take care of anything else. This way, you don't need to make any decisions about sliding the window up and such.
Thinking about it, this way is quite simple really and probably pretty effective, as long as you start high and go down as the level of lost acks becomes known, instead of needing logic to increment speeds after a number of sucessful runs (which might need tolerance levels and stuff for normal lost packets (acks) to function most efficiently). Having said that, I don't know what the bandwidth situation is like when running popular servers, it might be you need a highly scalable method dependant on how much free bandwidth you can possibly use if the servers are at high capacity.
Nice ideas anyway, can't wait to see it implemented - If only so I don't have to shed a tear everytime someone complains about having to wait ages to download KungFu...
- Dag