[15099] in North American Network Operators' Group
Re: MTU of the Internet?
daemon@ATHENA.MIT.EDU (Phil Howard)
Sat Feb 7 16:49:34 1998
From: Phil Howard <phil@charon.milepost.com>
To: wsimpson@greendragon.com (William Allen Simpson)
Date: Sat, 7 Feb 1998 15:33:42 -0600 (CST)
Cc: nanog@merit.edu
In-Reply-To: <7000.wsimpson@greendragon.com> from "William Allen Simpson" at Feb 7, 98 05:46:01 pm
William Allen Simpson writes:
> The real answer for ISPs is to never ship Explorer on your configuration
> CD, since it is impossible to make well-behaved. Preconfigure Navigator
> to 2 streams. And even better, set Auto-Load Images Off. There is a
> nice big Images button to load the images on a page on those rare
> occasions that you actually want to see them....
>
> You will find that your users will be much happier with their networking
> experience, and you will have fewer support calls.
I guess we have come full circle and are back to the beginning again, with
no solution that works.
Limiting Navigator to 2 streams does not work. I know that it does not
work because I have used it as such. 4 streams did not work, which was
the default. I run mine at 30 and the MTU at 552 and sometimes lower
and it works great.
Setting auto-load images off is so absurd as to not even justify an answer.
I know that a smaller MTU isn't the ultimate answer, but limited streams
only makes things worse because each image has to mostly wait until another
image has completed. And that requires a longer wait time which makes the
user less happy. I've seen this in user complaints about "slow loading"
sites.
We aren't going to get solutions to this problem by beating it with sticks.
Probably what we need to do is lay out what all the requirements are, and
then evaluate solutions on the basis of the requirements. Any solutions
that meets them all can win. Short of that it becomes difficult to balance
all the requirements.
But all of this, IMHO, should be a protocol design and/or implementation
issue, and not an issue of network operation. So it shouldn't even be on
this mailing list. My might well have a concern that problem be resolved,
as would be the case with any kind of problem that is seen in operations
and comes from design. But we aren't going to solve it here.
--
Phil Howard | no9spam1@anyplace.edu stop9960@anyplace.edu suck0it6@spam1mer.edu
phil | end7it32@dumb0ads.org stop4120@no2place.edu stop3it1@anywhere.net
at | stop7it8@dumb6ads.org a2b8c8d9@no9place.net blow4me5@spam6mer.com
milepost | eat0this@dumb2ads.edu stop7ads@nowhere4.net die4spam@noplace3.com
dot | stop2196@spammer9.com stop7260@dumbads5.org no1spam6@s8p1a5m4.org
com | a9b6c6d9@nowhere7.com eat2this@dumbads5.net stop8ads@no9place.edu
