Stephen Sprunk writes:
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.
Changing the number of connections IS the correct answer in this case.
If "this case" == "your computer" then of course whatever you want to be the correct solution is the correct solution. It would not be so in the case of my computers or computers I give advice for if the user (like I) wants to have all images show in parallel in order to have some idea of which to click without waiting for everything to load.
If you are a dialup user at 33.6k (or 56k even), you should be very acutely aware of how puny your pipe is. There is absolutely no reason to expect 64 simultaneously connections to an OC-12 connected server to behave normally. HTTP 1.0 is known to be severely flawed in this respect; it opens large numbers of connections and closes them before slow-start and congestion avoidance can kick in.
Isn't slow start supposed to be there at the beginning? I have 33.6k and am fully aware. I run my MTU at 552 and I know how to change it on the fly (for new connections) any time I want to. I have many times run it at 104.
If your primary complaint is interactive response while performing large downloads, changing the MTU is the correct answer. This is simply a matter of the transmission time on large packets.
That's one of them. The other is having multiple images on a page load in parallel instead of having to wait for some to finish all the way to high res before others can even get started. Low MTU fixes that, too. I won't say that a low MTU is the ultimate correct solution as long as every aspect of the protocol and every detail of each implementation is equally open to review and blame. The "correct" solution may even be as drastic is discarding the whole protocol and starting over. But a low MTU does work and does accomplish my goals where no other has. Another solution that could help is a better design of some web pages. Lots of pages have collections of buttons with each being a separate image. If they were to design them as a single image for all buttons that loaded low res first and filled in high res later, then one could at least get some idea early on about where the buttons are. And if one is familiar with the page they could even click on the proper button even before the text becomes obvious. This may not be the "correct" solution, but I know it would certainly help. And it would meet my needs (don't know about yours).
I'm sure we'd all like to see a reference implementation of your ideas. Keep in mind that one of the primary features of PMTUD is that it requires no modifications to any hosts or routers, and that it uses only one protocol (ICMP) which is required to be implemented on all hosts.
I understand this. And that's why I see it as a hack. It was done as a workaround to the problem that router vendors would not upgrade their routers. Maybe that was because the base standard was then frozen and could not be expanded on, or maybe it was because the vendors didn't want to go back to tweaking the router code (although I hardly believe they never do). If you were designing a whole new protocol from scratch without any of the vendor constraints, would you do it the same way? How would you do it? -- Phil Howard | ads8suck@no7where.edu eat59me0@spam1mer.org die9spam@lame4ads.org phil | ads6suck@s1p6a5m7.com end2it77@no19ads5.edu eat9this@noplace5.net at | stop1it8@no2place.com no94ads7@dumb8ads.edu ads4suck@s3p2a2m4.net milepost | stop8801@no29ads3.org no5way27@s5p1a4m1.edu stop5ads@anyplace.org dot | w2x0y3z0@no94ads6.net stop4it3@anyplace.com eat66me8@anywhere.com com | no5way51@no2where.edu crash285@spam2mer.org end4ads7@anywhere.net