Re: [tcpm] 793bis: TCP Quiet Time

Matt Mathis <mattmathis@google.com> Thu, 23 January 2020 06:59 UTC

Return-Path: <mattmathis@google.com>
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 05599120115 for <tcpm@ietfa.amsl.com>; Wed, 22 Jan 2020 22:59:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 MUBvcfnOC2lf for <tcpm@ietfa.amsl.com>; Wed, 22 Jan 2020 22:59:19 -0800 (PST)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 9F24712003F for <tcpm@ietf.org>; Wed, 22 Jan 2020 22:59:19 -0800 (PST)
Received: by mail-io1-xd36.google.com with SMTP id m25so1909492ioo.8 for <tcpm@ietf.org>; Wed, 22 Jan 2020 22:59:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hhT9oBClRapNsVEyIpYObSC+1bskF9Ui1t6GYZW6KK4=; b=ZShd0DzVoRXC2ghh/YkiYJprmpO+MNhCo8t1lkrsEseF7lCFAUPON9S6jLzOceoHaP nT9PjqkcHYfn4f5CDFYNq+acv5ie3rtpDQY+1bqSTiBGySKRZaeTwnCinMpPHyTq7coV 8uial4dDkDHBx3AXXh14werfQzxDi5wWsIWB1/+vpYEvn4wOcMfln7Ny+EfQdbm+PkHJ duIHI3fK80zkQK9sYKXZOQVprDa6sIMmhYdiVkJzhUPWxXmDNFVZ9NjfyKYNMlXfTdo8 PoXmYjDhPvcQGY3kP1kjoUelHC8YCRxJLeMN5Cl01IuwALkjF8WysEx5QQonFq7kdKXj ULyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hhT9oBClRapNsVEyIpYObSC+1bskF9Ui1t6GYZW6KK4=; b=ugJ6ajzjnB817caLJBl4YuFvNbAGbexGnlHLcD55fNM/OIENI+s9rLdSKsuQ4NYfRH m+8gDky7bKTpxSIH/adK5qubue0Du4QyOrUlT83cqtDLHZjNM5x0t+xj5mXMuWPKaH53 1QTnKdUkWsmyR6Nvs3QNtpxIyU/w0E5StpbLT3xFtzL5B/dRVbAgPvOi2HgScB9MW2tQ vCxvk29T9E0orFe5atyi1j12kL0ZtmXETu53M93Y9jCFYSMWy4e3QL0mVaev+GCIUQCx 7yLYBxM8ycO7uOJ1aU+0w/fLm4HIQGxu+D2Xv5ql3J0iSXao0W32BgGaKp1pT0WbR5ot 9R/A==
X-Gm-Message-State: APjAAAWTM4Uhk8lP67KOWBbt0wRGfDdZwqbwLT6a4huVJJJ4Ctqf2z1t c97+IsXJ3gFF26sqhh5II/zHGNQyc2MrcFHu3YDyO/lh8Ng=
X-Google-Smtp-Source: APXvYqyeDgLBrnc1btNu8eRvkdhZ676N/aY2AZE6rpJ9dA8K9EIHWsHWSC3J57PgeiW7sYShbDWiFAbCnGqy1S4Axho=
X-Received: by 2002:a5d:8c89:: with SMTP id g9mr5756033ion.178.1579762758558; Wed, 22 Jan 2020 22:59:18 -0800 (PST)
MIME-Version: 1.0
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com> <d6d45644-387a-6cee-8087-379c45f36e43@si6networks.com> <4B73D1AE-7901-4F2C-A56F-D4BF6D914050@strayalpha.com>
In-Reply-To: <4B73D1AE-7901-4F2C-A56F-D4BF6D914050@strayalpha.com>
From: Matt Mathis <mattmathis@google.com>
Date: Wed, 22 Jan 2020 22:59:06 -0800
Message-ID: <CAH56bmDx=EoCMhO__5n84cu0ZYDHRs0FvEYqm2KJLuNz+5K=PA@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: Fernando Gont <fgont@si6networks.com>, "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000e228e059cc92eee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/BC1H6jZYuZu_cEBX9yJrnKRan0Q>
Subject: Re: [tcpm] 793bis: TCP Quiet Time
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 23 Jan 2020 06:59:22 -0000

There are two other changes that have largely made this problem moot:
a) ISS and ephemeral port randomization make it extremely unlikely that
segments delayed across a reboot will be in sequence for any connections
(at the time this was written, both ISS and ephemeral ports were generated
by counters starting from fixed integers).
b) Although not reflected in policy, the effective MSL of the internet has
been declining as it gets faster.   There are paths and devices that can
delay packets by more than 10 seconds but they don't normally cause packets
to be reordered by that much, so a new SYN can't pass an old data segment,
which is a requirement for triggering the hazard.

I would suggest changing the text to say "a theoretical problem....  that
could be fixed by...  but for the following reasons it is viewed as being
sufficiently unlikely to ignore.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of
control;
            too weak risks being mistaken for tacit approval.


On Wed, Jan 22, 2020 at 10:27 PM Joe Touch <touch@strayalpha.com> wrote:

>
>
> On Jan 22, 2020, at 10:54 AM, Fernando Gont <fgont@si6networks.com> wrote:
>
> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
>
> OLD, Section: "   The TCP Quiet Time Concept"
> - Found this section quite amusing. Is this concept widely implemented in
> stacks?
>
>
> No.
>
>
> It might be useful to consider this is relevant only for systems that
> reboot in under 2 MSL anyway. That’s a good reason most systems don’t need
> to care - but a good reason to worry about ignoring this issue as we move
> forward.
>
> I.e., of this concept and its utility, as financial investors advise:
>
> Past performance is not be a predictor of future results.
>
> Joe
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>