Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-00.txt

Ole Troan <otroan@employees.org> Thu, 16 August 2018 08:57 UTC

Return-Path: <otroan@employees.org>
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 168F5130EEF for <int-area@ietfa.amsl.com>; Thu, 16 Aug 2018 01:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IbnhfAKI98-8 for <int-area@ietfa.amsl.com>; Thu, 16 Aug 2018 01:57:37 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E760130ECF for <int-area@ietf.org>; Thu, 16 Aug 2018 01:57:37 -0700 (PDT)
Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id A40D42D4F9D; Thu, 16 Aug 2018 08:57:36 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id D15353FD510; Thu, 16 Aug 2018 10:57:34 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <alpine.DEB.2.20.1808160735400.19688@uplift.swm.pp.se>
Date: Thu, 16 Aug 2018 10:57:34 +0200
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, int-area@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <AE241D6E-2379-4EFB-802C-BFBC840273E7@employees.org>
References: <153434872145.14477.17942361917248825531@ietfa.amsl.com> <2c82b61e-8017-742e-764b-559f2ec4bd37@gmail.com> <alpine.DEB.2.20.1808160735400.19688@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike@swm.pp.se>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/5CEuCBRQTK9Fm4_LJz5qOWhft24>
Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-00.txt
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, 16 Aug 2018 08:57:39 -0000

>> Whether that automatically solves the problem depends on whether
>> PMTUD works, which is unpredictable. Therefore, if you want a protocol
>> *design* that is universal, it can't depend on PMTUD. Disabling
>> fragmentation on its own is not enough. (That isn't news.)
>> 
>> The only universal solution therefore seems to be a fully specified
>> PLPMTUD solution, either built into the protocol design, or available
>> as a normative reference. I think that would be a better
>> recommendation than simply saying "don't rely on fragmentation."
> 
> Summary of my views:
> 
> Networks MUST support PMTUD.
> Networks MUST support IP level fragmented packets.

That is not realistic for the IPv4 Internet.
IPv4 fragments do have a higher drop probability than other packets. Just from the fact that multiple end-users are sharing a 16 bit identifier space.

> Protocols/applications SHOULD have PMTUD blackhole detection.
> Protocols/applications SHOULD do PLPMTUD.
> Protocols/applications SHOULD avoid IP level fragmentation.
> 
>> IMHO RFC4821 isn't a sufficient normative reference for this. Possibly draft-ietf-tsvwg-datagram-plpmtud will do it for UDP-based protocols. But IMHO we need a solution for each transport protocol, with widely available libraries.
> 
> Agreed. The libraries part is extremely important. Programmers implementing applications should not have to worry about this, it should be taken care of by the libraries they use. For them it should just work.

Cheers,
Ole