Verizon DSL question

[mcmanus at ducksong.com (Patrick R. McManus)]

[Derek D. Martin: Tue, Apr 30, 2002 at 11:21:45PM -0400]

[by instiuting lower mtus on your lan hosts]
> Essentially you're causing your local LAN to fragment packets.  That's

the mind boggles.

by lowering the internal mtu to match, you are preventing
fragmentation - you are not in any way shape or form "essentially
causing" it. ! If you think generating slightly more packets (8 byte
overhead, that's .53% !) is anything like what happens in the nightmare
of fragmentation you've got a totally warped understanding of what
goes on.

> smaller packets means a smaller data to frame header ratio.  IOW when

yes, .53%.. but if you actually thought this was a problem you'd be
attacking all DSL which is really ATM based - the overhead on that is
just plain terrifying. It totally dwarfs the pppoe encapsulation.

Fragmentation is a much more serious problem than you seem to
understand. Indeed, the biggest issue is most TCP sessions aren't
allowed fragment at all - they set the DF bit (a process known as Path
MTU discovery). This means that when fragmentation would occur, the
sender is signaled and has to resend with a lower mtu, basically
throwing aways all of the work that had been done to that point. Ugly
stuff.

even when fragmentation is happening, it creates fate sharing between
all of the fragments - there is no way for TCP to timeout and resend
just a fragment, this is also awful for performance. And then there is
packet reassembly - modern IP stacks are actually pretty bad at this
and allocate very few resources to it (as it is pretty rare), which
means you're more likely to overflow buffers at the receiver with
fragments than with whole segments.

Some Linux content: setting the MTU on a lan host (which is not the
host with the DSL connection) is a little non-traditional. You could
just lower the MTU of the interface, but as Derek points out this
lowers the MTU for internal traffic - which I assert is only a
measurable problem if you'd normally run jumbo frames (bigger than
1500). However, linux will let you actually change the MTU on a per
route basis instead of a per interface basis, with the "ip" command.

/sbin/ip route change 0.0.0.0/0 dev eth0 mtu 1492  via 192.168.16.1

[root at book mcmanus]# ip route list
192.168.16.0/24 dev eth0  proto kernel  scope link  src 192.168.16.10 
127.0.0.0/8 dev lo  scope link 
default via 192.168.16.1 dev eth0  mtu 1492


-P