Frank Kastenholz writes...
note well that _none_ of this has to do with pmtu. none of this has to do with the oft-proclaimed poor quality of m.s. software.
Turn the MTU down, way down, and see how it affects things. At what point in number of connections does the problem happen with MTU=1500 and at what point does it happen with MTU=600 and even MTU=200. Of course changing MTU isn't the correct solution, nor is changing the number of connections. But these are workarounds that do work, for now. Perhaps the retransmission timeout is the real problem as suggested, but given there are different effects based on what client stack is used, as apparently see on the end results and packet traces with Windows 95 and Linux as the clients, there is some effect by the client. That may not be the true cause, but it should be discovered and logically ruled out if it isn't.
<soapbox> moral of the story theorizing is wonderful but a good packet trace beats a theory every time
and understanding how the protocols are _supposed_ to work and then trying to figure out why they don't is a lot more productive than bashing mammoth-software-corporations, though a lot harder </soapbox>
I'll admit to having never read the _whole_ protocol, so I will make a point to do that at some point. But having read the details on slow start as a result of this thread, I find it's not what I proposed, although I can now see that it, too, would have been explained as I explained my idea, so the explanation was flawed. I might try to implement my ideas via UDP and see what kinds of effects I can really get over real networks of the 1990's, understanding that the original design was done in the 1980's and before with slow links and slow routers. -- Phil Howard | stop0it8@anywhere.edu no3spam2@s9p6a8m8.com stop2012@anyplace.net phil | ads6suck@lame8ads.net w2x7y5z2@dumb6ads.com end8ads2@anyplace.edu at | blow1me4@spam0mer.edu crash416@no19ads1.com suck3it7@no2place.edu milepost | stop8149@nowhere6.edu no88ads5@no0where.org a5b7c4d9@noplace5.net dot | eat84me0@dumbads2.com stop9ads@lame1ads.net die0spam@spammer9.com com | end0ads2@nowhere7.edu a9b4c4d7@dumbads8.edu stop2ads@spammer9.org