From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 94286138330 for ; Tue, 20 Sep 2016 14:47:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 94583E0BCB; Tue, 20 Sep 2016 14:47:27 +0000 (UTC) Received: from km35626.keymachine.de (km35626.keymachine.de [87.118.86.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4C7DBE0BC2 for ; Tue, 20 Sep 2016 14:47:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by km35626.keymachine.de (Postfix) with ESMTP id BB7701124763 for ; Tue, 20 Sep 2016 16:58:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at km35626.keymachine.de. Received: from km35626.keymachine.de ([127.0.0.1]) by localhost (km35626.keymachine.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7-LcWsgEwsn for ; Tue, 20 Sep 2016 16:58:55 +0200 (CEST) Received: from grusum.endjinn.de (p4FC96D26.dip0.t-ipconnect.de [79.201.109.38]) by km35626.keymachine.de (Postfix) with ESMTPSA id 2F2A41124762 for ; Tue, 20 Sep 2016 16:58:55 +0200 (CEST) Received: by grusum.endjinn.de (Postfix, from userid 500) id 628311702EF; Tue, 20 Sep 2016 16:45:49 +0200 (CEST) Date: Tue, 20 Sep 2016 16:46:15 +0200 From: David Haller To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] {OT} ISP requires MTU below 1500? Message-ID: <20160920144615.juwnp76jtqe6ec7y@grusum.endjinn.de> Mail-Followup-To: gentoo-user@lists.gentoo.org References: <20160920024829.0d9b56ea@hal9000.localdomain> <20160920115258.GV7108@ns1.bonedaddy.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: Organization: What? X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.6.2 (2016-07-01) X-Archives-Salt: db08aea5-0254-487f-85cd-d34544fe8803 X-Archives-Hash: 475b5a25f365234ef5ea24c804923a92 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