IETF Logo Mail Archive

Re: [tcpm] PLPMTUD for all protocols

rs.ietf@gmx.at Wed, 28 March 2018 14:03 UTC

Return-Path: <rs.ietf@gmx.at>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFB112711E for <tcpm@ietfa.amsl.com>; Wed, 28 Mar 2018 07:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 28cNJ7bpA8c9 for <tcpm@ietfa.amsl.com>; Wed, 28 Mar 2018 07:03:25 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 7064512711B for <tcpm@ietf.org>; Wed, 28 Mar 2018 07:03:24 -0700 (PDT)
Received: from [217.70.210.6] ([217.70.210.6]) by msvc-mesg-gmx123.server.lan (via HTTP); Wed, 28 Mar 2018 16:03:21 +0200
MIME-Version: 1.0
Message-ID: <trinity-d67909c0-f0ff-4f5d-b878-55996e42d689-1522245801534@msvc-mesg-gmx123>
From: rs.ietf@gmx.at
To: tom@erg.abdn.ac.uk
Cc: swmike@swm.pp.se, tcpm@ietf.org
Content-Type: text/plain; charset="UTF-8"
Importance: normal
Date: Wed, 28 Mar 2018 16:03:21 +0200
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-Provags-ID: V03:K1:8wrv5uQg9jxdZTHTEUX4HFlMwfEsZxmNF1XLu2DqvAn 1BsAyJNfnhWVfrlcZlSMw0W1J097NkhBby+tPYiohYN3Q/eal1 ttHLyCXOnmkZJa4qte3ZPpqLKTZCtY1iXA5zDmUodf665JhJcm 1a0qkPNukdbDq1IW/SuU28B+iS3XkfkarbP+67BapSRD5tvV0B 4Y938VY6gwD+KbRjIn4k0/KdOzVujFtOb8hQAjSOWgYd2OP2Ir YUHL+rd4B6KIxYPs8M+49VnpMmL/UFlGIdWDs1q0HmhOkJtTbW fcSFp+sKBjQo/GBD3w8F89Ht9qz
X-UI-Out-Filterresults: notjunk:1;V01:K0:ANUL/a2rsr8=:DlwMPsVsc0adLH/RPsMxXL ZVi1BbuEAF9AeEXrRdMG1McgndA88FYn3HWRPqPjjvFlXc69xYw+xN7RI4C1bjtJV9pjy9EQZ aPsVr5PkLNFcdNQVxV8zbnGAOmVjvjHhsaVxpkaR5S8keuf+1BZ2MYLRQOleagAkweO8dnTGP 9Bqcq7TyOr/NfEEKFVKVIdrUuvBNq3xsoX3pN0hkEhhCtEtTiSYEvNvhnqAcoYysN+uI/WSwc lW1xlYNJFur042JKFLy493RNiMeg+nU87IF8IvawyBI1I7ci2yzmiFQZWmt+i4Y3/88jYRgzs RPl37BDiMXjA0hDTT6uLd5WHSs76vYHxDjqt2qNC++raxFr6WzBs7fmEz5eddcDDj8QKQ2xCo RTW8J/L9SzL7hIM1lokScgDlft8WDtXIAvWHEev6WArbXybxaId/xzyR/eBHV3ktP0BJ/VD9J kfRK76WpP4y6r1r85QbBRtjFNI21EjDXcPUit062B4Lo1HfWHn1IydTp+0svNsoGJ11IgJ+WR +NuEf96PPVmeVIBsDDaNrc=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/B2ZyrMCc1O8FXa4NruFsZus-dGo>
Subject: Re: [tcpm] PLPMTUD for all protocols
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2018 14:03:31 -0000

Mikael,

Yes, the main concern raised there (and in private conversations, also here) was a perceived performance impact when there is a false positive.

Also, the (rfc4821) probing upwards is often not fully implemented due to its complexity, and the obvious chance (with TCP) of causing a loss that has to be recovered (but IMHO nothing speaks against probing with a larger segment, immediately followed with a known-ok sized segment, using the ACK sequence number to validate if the probe went ok).

At least for BSD, there is still some work to be done, before it is 4821 compliant...


Best regards,
   Richard

 

-----Ursprüngliche Nachricht-----
Von: "Tom Jones" <tom@erg.abdn.ac.uk>
Gesendet: Mittwoch, 28. März 2018 11:03
An: "Mikael Abrahamsson" <swmike@swm.pp.se>
Cc: tcpm@ietf.org
Betreff: Re: [tcpm] PLPMTUD for all protocols

On Wed, Mar 28, 2018 at 10:43:40AM +0200, Mikael Abrahamsson wrote:
> 
> Hi,
> 
> In trying to advocate for all protocols implementing PLPMTUD (RFC4821) and 
> shipping with it default on, I received pushback when I suggested/asked 
> why modern TCP stacks don't come with PMTU blackhole detect turned on.
> 
> Relevant reading is draft-bonica-intarea-frag-fragile-01, where PMTU 
> blackhole is one part of this problem space.
> 
> I tried turning on PMTU blackhole in Linux quickly in a case I had, and it 
> worked around the PMTU blackhole we had for a certain deployment scenario 
> (which couldn't be fixed unless the NMS could reconfigure the device in 
> question, which it couldn't because PMTU blackhole existed).
> 
> People suggested to me that the current TCP stack implementations are 
> broken when it comes to PMTU blackhole detection and workaround, so that's 
> why it's not on.
> 
> What's wrong with it, and how do we fix it?


Related discussion on the freebsd-net mailing list.
https://lists.freebsd.org/pipermail/freebsd-net/2018-March/049916.html

As I understand there are issues with FreeBSD increasing again after
detecting a blackhole. There is not currently enough state kept to
regrow the mtu. 

- [tj]

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

v2.23.0 | Report a Bug | By Email