Re: Responding to Ron's comment about removing fragmentation

Carsten Bormann <cabo@tzi.org> Fri, 14 November 2014 21:24 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8B11ACDCC for <ipv6@ietfa.amsl.com>; Fri, 14 Nov 2014 13:24:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
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 Vhb6dkX4Dxfi for <ipv6@ietfa.amsl.com>; Fri, 14 Nov 2014 13:24:56 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7BB81ACDC3 for <ipv6@ietf.org>; Fri, 14 Nov 2014 13:24:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sAELOqT2001847 for <ipv6@ietf.org>; Fri, 14 Nov 2014 22:24:52 +0100 (CET)
Received: from dhcp-9bf8.meeting.ietf.org (dhcp-9bf8.meeting.ietf.org [31.133.155.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EB28C480; Fri, 14 Nov 2014 22:24:51 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
Subject: Re: Responding to Ron's comment about removing fragmentation
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <FE6C2980-804D-4D76-94AE-B4A40ADA33A0@tzi.org>
Date: Fri, 14 Nov 2014 11:24:49 -1000
X-Mao-Original-Outgoing-Id: 437693089.25117-62f80aed059cb44bee61ff9ece875510
Content-Transfer-Encoding: quoted-printable
Message-Id: <9736BDA3-E7A1-4402-B897-834972CFA685@tzi.org>
References: <5466662F.6080400@acm.org> <FE6C2980-804D-4D76-94AE-B4A40ADA33A0@tzi.org>
To: IETF IPv6 <ipv6@ietf.org>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/2L7rKr2SBaLg73sxmTzdGLGF1KY
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 21:24:57 -0000

I just sent Jeroen a message privately that I think could help framing the discussion about active measurement of MTUs.  See also the discussion about multi-MTU later in intarea.

One related draft is:
http://tools.ietf.org/html/draft-bormann-intarea-alfi-04.txt

We haven’t managed to find a way to make this work (except for “5. Another way of doing it”, and you be the judge whether this is the desirable way forward).

There are a number of very good uses for a way to collect information on the current path, and PMTUD is just the most pressing one (see RFC 4782 for a more esoteric one). We can’t put all of them in the flow label.  Hop-by-hop options are the architecturally correct way, but these seem to be irretrievably damaged by current deployment.

Grüße, Carsten



> On 14 Nov 2014, at 10:47, Carsten Bormann <cabo@tzi.org> wrote:
> 
> Having a single MTU is not very useful thinking: Every tunnel then causes a fragmentation problem.
> 
> Instead, we need to keep two MTUs:
> The one exported to the top of stack (inner MTU), and the one imported from the bottom of the stack (outer MTU)
> 
> The inner MTU is 1280, and with IPv6 it is really hard to use anything that is much closer to 1500, as old style (RFC 1191) PMTUD so overwhelmingly breaks and PLPMTUD (RFC 4821) incomprehensibly isn’t switched on.
> 
> The outer MTU is 1500 for all instances of reality.
> 
> By never sending more than 1280 from an application and never limiting the available MTU below what tunneling removes from 1500, most applications and tunnel stacks can just work well.
> 
> Apart from the cognitive dissonance problem, do we really need that 17 % (max) reduction in the number of packets that jamming up the inner MTU to the max would allow?
> 
> Grüße, Carsten
> 
> PS.: Yes, we made the mistake not to recognize these simple facts in 6LoWPAN.   See section 4 of draft-bormann-6lo-6lowpan-roadmap-00.txt for the (unofficial, but widely implemented) fix.
> 
> 
>