MTU of the Internet?

Fri Feb 6 20:35:17 UTC 1998

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 at no7where.edu eat59me0 at spam1mer.org die9spam at lame4ads.org
  phil      | ads6suck at s1p6a5m7.com end2it77 at no19ads5.edu eat9this at noplace5.net
    at      | stop1it8 at no2place.com no94ads7 at dumb8ads.edu ads4suck at s3p2a2m4.net
  milepost  | stop8801 at no29ads3.org no5way27 at s5p1a4m1.edu stop5ads at anyplace.org
    dot     | w2x0y3z0 at no94ads6.net stop4it3 at anyplace.com eat66me8 at anywhere.com
  com       | no5way51 at no2where.edu crash285 at spam2mer.org end4ads7 at anywhere.net