[15027] in North American Network Operators' Group
Re: MTU of the Internet?
daemon@ATHENA.MIT.EDU (Phil Howard)
Thu Feb 5 13:34:21 1998
From: Phil Howard <phil@charon.milepost.com>
To: marcs@znep.com (Marc Slemko)
Date: Thu, 5 Feb 1998 12:18:35 -0600 (CST)
Cc: nanog@merit.edu
In-Reply-To: <Pine.BSF.3.95.980205104332.2304I-100000@alive.znep.com> from "Marc Slemko" at Feb 5, 98 10:45:46 am
Marc Slemko writes...
> First, I _really_ doubt the web server set the DF bit. It is almost
> certainly the OS, probably trying to do path MTU discovery.
>
> If there is a smaller MTU in the middle, and someone is filtering ICMP
> can't fragment errors then yes, you will have trouble with PTMU discovery.
> The fix is to not blindly filter ICMP. Increasing the client MTU won't
> fix this.
Agreed that one should not blindly filter ICMP. However not all filter
tests don't support discriminating individual ICMP types. Ascend is one
example.
> If the client lowers their MTU, there is no problem because then they
> advertise an appropriate MSS and no stack should try sending packets that
> it knows will need to be fragmented given the client MSS.
That's one reason I went with lower MTU until I could replace SLIP with PPP.
But then I discovered other things work better, such as interactive telnet
during multiple concurrent downloads. So I leave MTU low until I get that
OC-12 into my apartment.
--
Phil Howard | blow1me4@spammer0.net no75ads9@no3where.org ads9suck@dumb0ads.com
phil | stop9397@noplace2.org ads0suck@lame9ads.net no27ads2@nowhere0.org
at | ads4suck@nowhere5.net eat0this@noplace5.com die2spam@nowhere4.net
milepost | eat8this@spammer3.net suck1it7@anyplace.com end8ads9@lame8ads.org
dot | crash834@anyplace.edu suck5it5@spammer6.edu suck7it3@dumbads1.net
com | die5spam@anyplace.edu no16ads5@no61ads7.org no47ads4@anyplace.com
