|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: MTU of the Internet?
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 | [email protected] [email protected] [email protected] phil | [email protected] [email protected] [email protected] at | [email protected] [email protected] [email protected] milepost | [email protected] [email protected] [email protected] dot | [email protected] [email protected] [email protected] com | [email protected] [email protected] [email protected]
|