On 10/17/07, Matthias Vill <[EMAIL PROTECTED]> wrote: > Tony Godshall wrote: > > If it was me, I'd have it default to backing off to 95% by default and > > have options for more aggressive behavior, like the multiple > > connections, etc. > > I don't like a default back-off rule. I often encounter downloads with > often changing download speeds. The idea that the first few seconds I > only have a quite bad speed and could get much more out of it is just > not satisfying.
You might be surprised, but I totally agree with you. A default backoff rule would only make sense if the measuring was better. E.g. a periodic ramp-up/back-off behavior to achieve 95% of the maximum measured rate. > > I'm surprised multiple connections would buy you anything, though. I > > guess I'll take a look through the archives and see what the argument > > is. Does one tcp connection back off on a lost packet and the other > > one gets to keep going? Hmmm. > > I guess you get improvements if e.g. on your side you have more free > bandwidth than on the source-side. Having two connections than means, > that you get almost twice the download speed, because you have two > connections competing for free bandwidth and ideally every connection > made two the sever is equally fast. > > So in cases, where you are the only one connecting, you probably win > nothing. Ah, I get it. People want to defeat sender rate-limiting or other QOS controls. The opposite of nice. We could call it --mean-mode. Or --meanness n, where n=2 means I want to have two threads/connections, i.e. twice as mean as the default. No, well, actually, I guess there can be cases where bad upstream configurations result in a situation where more connections don't necessarily mean one is taking more than one's fair share of bandwidth, but I bet this option will be result in more harm than good. Perhaps it should be one of those things that one can do oneself if one must but is generally frowned upon (like making a version of wget that ignores robots.txt). TG
