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

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 16 August 2018 05:39 UTC

Return-Path: <swmike@swm.pp.se>
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 43590130EDA for <int-area@ietfa.amsl.com>; Wed, 15 Aug 2018 22:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 1yTcCq1_-8Qc for <int-area@ietfa.amsl.com>; Wed, 15 Aug 2018 22:39:11 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 0B9B6130DC8 for <int-area@ietf.org>; Wed, 15 Aug 2018 22:39:11 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id B4E4CAF; Thu, 16 Aug 2018 07:39:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1534397948; bh=58pD/Z4Eu4BALOOAQhsKFHK6xzTOk5htA0BbIhwrnpE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=qTRaWVu4Qswsu65Xu2ozHKqCHAJ5GotzSvYdJsA7mO2Q8dn7tlbAzaN5pyYQfk+1c LbTed6W36Z9eeomxZuWI5ovtPYHUXgLxafg6MarKGsY8KtSF/LXuxEozLYpvOiuhuh Ekx81k/C3v4F89KYlykS2uleCDCvf1WSoCAqfvuk=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B163D9F; Thu, 16 Aug 2018 07:39:08 +0200 (CEST)
Date: Thu, 16 Aug 2018 07:39:08 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: int-area@ietf.org
In-Reply-To: <2c82b61e-8017-742e-764b-559f2ec4bd37@gmail.com>
Message-ID: <alpine.DEB.2.20.1808160735400.19688@uplift.swm.pp.se>
References: <153434872145.14477.17942361917248825531@ietfa.amsl.com> <2c82b61e-8017-742e-764b-559f2ec4bd37@gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/dbpn__iYtRDjwdF7BhKX6wlcoTE>
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 05:39:13 -0000

On Thu, 16 Aug 2018, Brian E Carpenter wrote:

> 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.
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.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se