[v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement)

Jeroen Massar <jeroen@massar.ch> Thu, 04 December 2014 09:49 UTC

Return-Path: <jeroen@massar.ch>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA7E1A0120 for <v6ops@ietfa.amsl.com>; Thu, 4 Dec 2014 01:49:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIUhtSSwYnUy for <v6ops@ietfa.amsl.com>; Thu, 4 Dec 2014 01:49:24 -0800 (PST)
Received: from bastion.ch.unfix.org (bastion.ch.unfix.org [IPv6:2a02:2528:503:2::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7121A0117 for <v6ops@ietf.org>; Thu, 4 Dec 2014 01:49:23 -0800 (PST)
Received: from kami.ch.unfix.org (kami.ch.unfix.org [IPv6:2001:1620:f42:99:7256:81ff:fea5:2925]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jeroen) by bastion.ch.unfix.org (Postfix) with ESMTPSA id C8374100A228B; Thu, 4 Dec 2014 09:49:19 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=massar.ch; s=DKIM2009; t=1417686559; bh=3cE+JShPqNShuhLKm/jppNj4AAOs+xCxAz1g9sMcRGs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=vREBzkNkvgh1RDwJQfVVnyYJNKHebepFMP0Sb2seuwKMWv+x2Ld/DYOBD0xwP+vt0 YZAaQ1XfSaN8apGWHxejctAq+PJLGkM6hhQGD3wYDXBZdFu1g8JrCr8WghY70KF/AA EyS1HPdWsbW38DbjQyh/qr/9XrvzWznKOsTQFKvksHeEiZpJBWdpvAnA5NHz+v3FX0 WBYmtFy8oErK6pDYh0FiwQrApnzenx80+nrt9oTm+IbBm5kz9hPmByXQKIKN5V7a35 wGCCrWbhLE0TrGCy6grBXA79eqx+MhGzfHCU4MtMeqImwdO6GtmKY/oRxOJm8hdbmn h6naVQOH49GxA==
Message-ID: <54802E1D.9070401@massar.ch>
Date: Thu, 04 Dec 2014 10:49:17 +0100
From: Jeroen Massar <jeroen@massar.ch>
Organization: Massar
MIME-Version: 1.0
To: sthaug@nethelp.no
References: <547F37B4.8050509@massar.ch> <2134F8430051B64F815C691A62D9831832DA9AD6@XCH-BLV-504.nw.nos.boeing.com> <547F3CE8.4090302@massar.ch> <20141204.095809.74726281.sthaug@nethelp.no>
In-Reply-To: <20141204.095809.74726281.sthaug@nethelp.no>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-cbsMXKSo7EmiJ9uRicb-Oalbj4
Cc: v6ops@ietf.org
Subject: [v6ops] MTUs on the general Internet (Was: Report: Bar BoF on a 6to4 replacement)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Dec 2014 09:49:26 -0000

[Geoff, any measurements you know of?]

On 2014-12-04 09:58, sthaug@nethelp.no wrote:
>>>> I do still do not see why that a MTU of < 1500 but >1280 is a limitation
>>>> in any way.
>>>
>>> Hosts have become conditioned to expect 1500.
>>
>> Which hosts? Most IPv4 nodes are connected with a LOT less...
> 
> I would actually like to see some statistics on this. I'm afraid I
> regard the SixXS user base (and MTU info) as somewhat skewed in
> comparison to the general public.

Yes, it is a quite limited view. Though at least it covers hundreds of
different ISPs where the endusers are.

The primary thing I think though that one can take away from those
numbers is that people do not really care about MTU and that they are
mostly fine with 1280. There is then also no real perceived benefit for
them as long as their stuff is 'fast'.

I don't even think a speedtest will show the difference too much between
1280 and the 1480 that a proto-41 tunnel could do, though in theory it
is a lot of overhead.

As such shoving the people who kept it to 1280 as in a "do not care"
category, only few actual changers remain.


Possibly this is a better report to look at:
https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters

at least takes data from where Atlas probes are located, but those tend
to be reasonably managed networks again. Those numbers are for ICMP.

It is hard to get a good estimate of this as it involves people to
provide the data or doing some kind of magic probing around the world;

There is ISI's tr-643.pdf but unfortunately ftp.isi.edu is down and
can't seem to find a cached copy anywhere else (except for mackeeper
malware spreading sites it seems...)

Geoff wrote this a few years back:
http://www.potaroo.net/ispcol/2009-02/mtu.pdf

but that does not cover the general MTU sizes available. Of course on
the IPv6 level we do not care there it is a minimum of 1280 or pMTU.

> As a counterexample, I work for one of the larger ISPs in Norway. We
> offer full 1500 byte MTU to all customers, including residential/DSL,
> and also for IPv6.

Most networks that I am aware of do indeed do 1500. Though quite a few
do deploy PPPoE or similar systems and end up with 1480 there already
unless they use a larger size for the Ethernet that that runs over
(trick also employed by 6rd folks).

> Business customers can get larger MTU on request.

That is great, but are they able to use it in a meaningful way?

I know a couple of networks that run at a MTU of 9000 in the core, but
it is rare to see that intra-AS. Similar to this mystical Multicast
thing. Though I think there is an actual business case to be made for
larger MTUs unlike the business case for intra-AS-Multicast.

Greets,
 Jeroen