Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

Tom Herbert <tom@herbertland.com> Fri, 27 July 2018 14:54 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8410130E25 for <int-area@ietfa.amsl.com>; Fri, 27 Jul 2018 07:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 zQQQn-dyqWj6 for <int-area@ietfa.amsl.com>; Fri, 27 Jul 2018 07:54:21 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32127130EF9 for <int-area@ietf.org>; Fri, 27 Jul 2018 07:54:19 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id c192-v6so3432468qkg.12 for <int-area@ietf.org>; Fri, 27 Jul 2018 07:54:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g/+wtV2ahbBUldcqPVK7SVEoKlB7Sb5t8Sll9pQm7Lg=; b=w/UwZJjlC5i8DjepWOfhp+mcBq+xb4HUMaP21tQtIolj8PUWiuv+4f0uYSi3e3IUkQ IuxvvxfuhqVx5ln0Hgl49vF5rwdvXq1HnPYga+6JKhakg5tnUSzXFJFUJk8HG/IYmhWG DpHLxvMjRdzscKrPCuKdmq/b3sQgwBEAw7M1H3KNiib+7Mfsy570US7LK/7i5gZAaDDh FlFcV1+4sQSIhARM6Y2AAVvTlDdZ6qdqao1cwsGz+mBDZh4u1RoxBrS4erWRlkG7UIyJ B2+afzpkUKGUu06KGmdrSwdL4f1OX+P3t91zAm4P0XCMM1x/7MpBAU4Y7PVybqfHhpVv YL4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g/+wtV2ahbBUldcqPVK7SVEoKlB7Sb5t8Sll9pQm7Lg=; b=f0j1x8jn6CDVwEvIcYW1HkxaFbn7TMVGlMW0DO7YMmAmLdl5VQN/BTKhPkBrn8dIpK Lq/Jt6wmszW/inOC10B/FjaSqfyuV0A3YSqxHRn+qqR4PtAKqwccALpQwn9lgkhw02dg FlCSgRBmB/fB2sTF6k/NzYahon2YXNOAwP91WIFSL3ZgBlEqIaZXn/b83IYQ+DHTey5O UnwSU/eRTCACay9QQDq4xr20VdACa1C85UWA9FMU4AyZPjw/qdYjahjG+KJNRx48IwgF vcvRd3QD4e9EfML81UIEVCyNz5DyfP8BgcJD+MEB1fTcDtJ/X1DLo2Dgtb0rnOaNJ7PW E8kQ==
X-Gm-Message-State: AOUpUlH9a1ckVlFSpedjdjPxdC/Dse4GoCSy2+LlVMLVxpIspF/+uRnK rMOZgGkW0oX8LYUg+riqO2qnp4tOp4teXDaLYjmkM8Kx
X-Google-Smtp-Source: AAOMgpdSRw2kYMQtzYm66fIMPHawo0l9ePvROQfH8Dsrg0LgQJZNV3oAN3w+s9KBlwNijENHA5sH75H37UQOSeNU548=
X-Received: by 2002:a37:1fdf:: with SMTP id n92-v6mr6421914qkh.333.1532703258159; Fri, 27 Jul 2018 07:54:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 07:54:17 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.20.1807271530280.14354@uplift.swm.pp.se>
References: <F227637E-B12D-45AA-AD69-74C947409012@ericsson.com> <0466770D-C8CA-49BB-AC10-5805CFDFB165@strayalpha.com> <6EDF0F79-C8F3-4F05-8442-FF55576ADDD0@employees.org> <alpine.DEB.2.20.1807271530280.14354@uplift.swm.pp.se>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 27 Jul 2018 07:54:17 -0700
Message-ID: <CALx6S35LthDLRry7k-pF8KSoX4BXBA8kyArOpDUAcJMDCoLQpQ@mail.gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Ole Troan <otroan@employees.org>, "internet-area@ietf.org" <int-area@ietf.org>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/qKLOqe0cZKA6JpFvyHQ9FpSZ7y0>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jul 2018 14:54:25 -0000

On Fri, Jul 27, 2018 at 6:32 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Fri, 27 Jul 2018, Ole Troan wrote:
>
>> There's nothing intrinsic in tunnels that require network layer
>> fragmentation. The current IP in IP / GRE etc tunnel implementations do, but
>> in principle we could design tunnel fragmentation/reassembly above the
>> network layer.

GUE defines that. Fragementation is done within the encapsulation
layer so that it is transparent to the network.
>
>
> This is what I do with OpenVPN for instance. I tell it to application layer
> fragment at ~1400 bytes, so the resulting packets always are significantly
> below 1500 bytes. So even as the inside of the tunnel is 9000 MTU clean, it
> never results in IP fragments to be transported.
>

I don't think that can be called a general approach. Setting MTU to
1400 bytes only avoids fragmentation if all the tunnel headers being
inserted are less than 100 bytes. If you start using more tunnel
options or the tunnel ingress inserts extension headers then that 100
byte budget may be exceeded may be exceeded. So a requirement to avoid
fragmentation in this manner would have to be that the MTU needs to be
low enough to account for all possible encapsulation overhead that may
be applied to a packet-- the emerging use of in-situ OAM, segment
routing, and even just switching from IPv4 to IPv6 for the underlay
puts downward pressure on MTUs. Lowering the MTU increase ratio of
overhead to user data thus making communications less efficient.

Fragmentation for tunneling is a special case since tunnels are often
used within a controlled network and precisley two fragments are
always generated. I know of at least one very large data center that
relies on fragmentation for tunneling. It seems to work fine in such
an environment and is preferable to lowering the MTU for everyone
(even non-tunnels) or turning on jumbo frames (complex to do at large
scale).

Tom

> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area