Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[David Haller]

Hello,

On Tue, 20 Sep 2016, Grant wrote:
>> MTU is per network interface but you really don't want to end up having
>> your router fragment every IP packet because systems on your subnet are
>> using a larger MTU.
>>
>> Todd
>
>That makes sense.  So in my case, I'm thinking 1492 MTU on every
>interface in the network.
>
>So I'm sure I understand, should everyone with a DSL connection set an
>MTU of 1492 (or potentially lower) on all of their network interfaces
>to avoid packet fragmentation?

That depends on your traffic flow. But, then again, 8 bytes out of
1500 means that you're "losing" just 0.533% of the maximum payload and
fragmenting can mean you have to send/recv 2 Frames for each 1500 Byte
packet you see locally.


I've just tested that (with the MTU set at 1492, so with the ping
overhead of 28 bytes, that leaves 1464 ping-payload without fragmenting)
("ping -M do" disallows, "-M dont" allows fragmenting).


$ ping -n -c 1 -M do -s 1465 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
From 192.168.178.11 icmp_seq=1 Frag needed and DF set (mtu = 1492)

--- www.dslreports.com ping statistics ---
0 packets transmitted, 0 received, +1 errors

==== corresponding tcpdump -n -i eth0 icmp ====
[nothing]
====


Ok, go down a byte:


$ ping -n -c 1 -M do -s 1464 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 1464(1492) bytes of data.
1472 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=136 ms

--- www.dslreports.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 136.638/136.638/136.638/0.000 ms

==== corresponding tcpdump -n -i eth0 icmp ====
15:48:39.587143 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3656, seq 1, length 1472
15:48:39.723751 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3656, seq 1, length 1472
====


One packet sent and received for 1492 bytes packet size / 1464 bytes payload.


$ ping -n -c 1 -M dont -s 1465 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
1473 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=137 ms

--- www.dslreports.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 137.888/137.888/137.888/0.000 ms

==== corresponding tcpdump -n -i eth0 icmp ====
15:47:07.983484 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3595, seq 1, length 1472
15:47:07.983494 IP 192.168.178.11 > 64.91.255.98: icmp
15:47:08.121308 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3595, seq 1, length 1472
15:47:08.121343 IP 64.91.255.98 > 192.168.178.11: icmp
====


Two packets sent and received for 1493 bytes packet size / 1465 bytes
ping-payload.

Try with e.g. 'ping -c 4 -M dont -s 1472 www.dslreports.com' for
yourself to see, that you'll send/recv 2 packets for each ping-packet
(and 1472 bytes is the ping-payload that just fits into the standard
1500 bytes MTU).

So, unless you have Gigs of internal traffic (and then you should have
a look at jumbo frames and might tune those to split nicely) and
little to the 'net, I'd definitely prefer losing those 8 bytes of
payload over sending double the packets (esp. with TCP, if just one of
those two of the fragmented bigger frame gets lost on the way, _both_
have to be retransmitted, as both TCP ends don't know (AFAIK, at least
usually?) about the fragmentation taking place inbetween, so basically
you're doubling the risk for lost TCP-packets for the "end-user" ...

With larger frames used internally (jumbo-frames) it gets complicated,
so I just send you to
https://en.wikipedia.org/wiki/IP_fragmentation
https://en.wikipedia.org/wiki/IPv4#Fragmentation_and_reassembly

And there's Path-MTU though. No idea if that works via the last-mile
PPPoE etc.

Disclaimer: I just know the basics of networking (and where to search
for what ;)

-dnh

-- 
I got an expresso maker at orkplace.  Expresso maker is deemed too complex by
all but me & PFY.  All expresso maker are belong to us.  :)  Caffeine is good.
Bzzzzzzzzz....                                          -- Mike Raeder