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

Tom Herbert <tom@herbertland.com> Thu, 26 July 2018 14:56 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 C42B613117B for <int-area@ietfa.amsl.com>; Thu, 26 Jul 2018 07:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] autolearn=ham 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 EzWFvuBjA6eR for <int-area@ietfa.amsl.com>; Thu, 26 Jul 2018 07:56:50 -0700 (PDT)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 7E1D5131179 for <int-area@ietf.org>; Thu, 26 Jul 2018 07:56:50 -0700 (PDT)
Received: by mail-qt0-x235.google.com with SMTP id d4-v6so1815057qtn.13 for <int-area@ietf.org>; Thu, 26 Jul 2018 07:56:50 -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=Vs9uyOwyOBnyGpWpJH7E69fSmqepbf0iFjQcpSOVZj8=; b=BZmNz/jVtSzcfoF3ewyzv+GPChvV97WtPgYpAyFc3LSvvaE57zHnrC9fkVCLp5e2jw z/+F5sGwHZ3xoLKjFXXqYgAIbizziy71pOBzes0xrnt1SUgHScOG9bx0OvMBmTUBo6KO VIPtPlrLv3xrajjpRFz9OiMMuDp5n1A4+/fZwubyHO1cYeR4op6++FY2Nz+PQ4/zLUGz uqNvnav9B97p7p8wbTq3qzDzOFy/a9y+7k6AJl7yrPMxdIbsbue8FiZtyBZ4jnPpkPRi Yd09qigx5eHd8IsHf2tv+pXytelTuHSd6Hypm3o3E4QCwn6z7CZgDYxyags8dKvQyuQr UI+w==
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=Vs9uyOwyOBnyGpWpJH7E69fSmqepbf0iFjQcpSOVZj8=; b=dlPT96BLn4mTAeCLl3vROAGm7+OWvqm1MzeHzzVqXRrUydHF1J6xCJuo2/H9bWKGDS apWP4OyBCB62dSo//Nv2L9b/Emyr1zYQtK4lZ9BGJV6SSvu8GD9/kG6E20l3739xlbbZ MlSYReWxCvQIZYpMAnm+RUGKYWw05RFJxGjRxDn00GrepQkrK6cAhL53bwg/GKZ/+DpT 6aNVVYRybO8hx9VETaF3TqpWHuUj0dNPnoLmWhGiklNgzTe5nW3nY6XYeFLAs4v5X8QR MEnIt1htHXsWRamSH84fOU8aRtkkAG/VkbP9WIdTGGgu887FHgctqfun1k1/8C64Vbu5 KteA==
X-Gm-Message-State: AOUpUlFPaq80R0AUS2thW3JeRA58dEvmP3MUn9dvNwlSpyFz7tNKTUiw /6IusYTp4nKKYLjMcn3cbylyfziXU8AsNk43lg2E7g==
X-Google-Smtp-Source: AAOMgpd6qt/re5sJl02CUQ1S0XW9goDdMZI3TdDWD8auLjpMy9HqO9ITwdqO3BrbgBBdez+Ayu3Uo+NYWw9HAA/BzPY=
X-Received: by 2002:ac8:530d:: with SMTP id t13-v6mr2068010qtn.396.1532617009400; Thu, 26 Jul 2018 07:56:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 07:56:48 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.20.1807260900050.14354@uplift.swm.pp.se>
References: <F227637E-B12D-45AA-AD69-74C947409012@ericsson.com> <e794c5ddbb814c0384c8dd06eb6acf7c@XCH15-06-08.nw.nos.boeing.com> <alpine.DEB.2.20.1807260900050.14354@uplift.swm.pp.se>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 26 Jul 2018 07:56:48 -0700
Message-ID: <CALx6S37Rfj5f8YdpgqCvOwiQ0fxBVYGHT85NnvMF4+bp03hWNw@mail.gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, "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/L0EWONBkWCZdihI6G6e9V1YDUbc>
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: Thu, 26 Jul 2018 14:56:53 -0000

On Thu, Jul 26, 2018 at 12:01 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Tue, 24 Jul 2018, Templin (US), Fred L wrote:
>
>> Try it - by default, iperf3 sets an 8KB UDP packet size and allows packets
>> to fragment across paths that support only smaller MTUs. I have seen iperf3
>> exercise IP reassembly at line rates on high-speed links, i.e., it shows
>> that reassembly at high rates is feasible.
>>
>> We know from RFC4963 that there are dangers for reassembly at high rates,
>> but there are applications such as iperf3 that ignore the "SHOULD NOT" and
>> leverage IP fragmentation anyway. So, should the "SHOULD NOT" have an
>> asterisk?
>
>
> The iperf3 usage of fragments for UDP testing seems to be platform specific,
> at least that's what I've seen. Behaviour has been different on MacOS
> compared to Linux.
>
Mikael,

I don't understand what would be platform specific. Can you elaborate?
iperf3 is sending UDP packets that are exceeding MTU and packets are
being fragmented. For IPv4, this means that DF is not set and packets
are being fragmented somewhere in the network, for IPv6 they are being
fragmented at the source. I don't believe path MTU discovery is in use
by iperf3, so if packets do exceed MTU then the only way they can can
be delivered is if fragmented.

> Anyhow, I believe we should keep the "SHOULD NOT". This allows applications
> that feel they have a good reason to do fragmentation to do so, but doesn't
> disallow it.
>

The text is "Application developers SHOULD NOT develop applications
that rely on IPv6 fragmentation.". As Brian said, this requirement
does not describe the algorithm, nor is it obvious what it even means
for an application developer to knowingly develop an application that
relies on IPv6 fragmentation. Besides that, RFC8085, which is
referenced in section 5.2, already provides the recommendations that
applications should avoid fragmentation by limiting packer size or
doing PMTU discovery. I don't see how 7.1 of this draft adds anything
to that or is clarifying those recommendations.

Tom

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