IETF Logo Mail Archive

Re: [tcpm] PLPMTUD for all protocols

Mikael Abrahamsson <swmike@swm.pp.se> Fri, 30 March 2018 06:20 UTC

Return-Path: <swmike@swm.pp.se>
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 51BA212D778 for <tcpm@ietfa.amsl.com>; Thu, 29 Mar 2018 23:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] 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 OwywZu_20tN2 for <tcpm@ietfa.amsl.com>; Thu, 29 Mar 2018 23:20:05 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 E0D5012D777 for <tcpm@ietf.org>; Thu, 29 Mar 2018 23:20:04 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 88B18AF; Fri, 30 Mar 2018 08:20:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1522390801; bh=RpVizH2kIfsN18A+UXnQ/dQY/j0PA6Pk+SmPbYC2res=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=LzPJcluh1AZ2mpJ0WVIH+Z4J2fQawSL4Bl5vccGFWcGUEnnLe11fM3tN9LAlk/h3P VM96wv++yJ/xpQ+eAB5f2XJl52UOD2uxWQBDL3Gt/y2mB7zunAc4DoPGMCoDg47t5/ pNNI0o3QbwFc5mi0tzRx5pAouPH3YhjO9R6rGsuY=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7F54E9F; Fri, 30 Mar 2018 08:20:01 +0200 (CEST)
Date: Fri, 30 Mar 2018 08:20:01 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Joe Touch <touch@strayalpha.com>
cc: William Herrin <bill@herrin.us>, tcpm@ietf.org
In-Reply-To: <572210fa-74ae-0edf-ce10-d66153ae80a3@strayalpha.com>
Message-ID: <alpine.DEB.2.20.1803300817030.20609@uplift.swm.pp.se>
References: <alpine.DEB.2.20.1803281034310.20609@uplift.swm.pp.se> <CAP-guGVEcnk09yi8sz+fmghpeb91Y8tQb+LsEmSF+0e+f6oGhw@mail.gmail.com> <alpine.DEB.2.20.1803281747020.20609@uplift.swm.pp.se> <B323BA47-32DF-498B-9D1F-5A378E7ABB98@strayalpha.com> <CAP-guGXfds60dwJXgnSYdbtQ-qOCJGpiw1kcYUkJR8L3jwsFSA@mail.gmail.com> <08fb7ec5406418e439391c66bc108d5d@strayalpha.com> <alpine.DEB.2.20.1803300728240.20609@uplift.swm.pp.se> <572210fa-74ae-0edf-ce10-d66153ae80a3@strayalpha.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/tcpm/bg5R_6sJFi9ce9SgckmErSyNL9c>
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: Fri, 30 Mar 2018 06:20:06 -0000

On Thu, 29 Mar 2018, Joe Touch wrote:

> It would be useful to be careful. I'd rather see a TCP that runs just 
> fine (but maybe not as fast as you think it should) with 400 byte 
> packets than one that keeps bashing its head against a rock trying to 
> find the "best" larger packet size, failing, and "limping" along that 
> way continually.

I have no fundamental objections to this. The only question I guess needs 
to be answered is if there is an 10 second 100% packet loss outage 
situation, will all my TCP sessions now be in limp mode after that?

Because I imagine that if TCP now went into slow-start and that 576/1280 
byte packet happened to make it through when the network started working 
again, would the implementation deduce that the outage was caused by PMTUD 
blackhole, and keep itself in limp mode?

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

v2.23.0 | Report a Bug | By Email