Re: [tcpm] 793bis ready to go?

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Tue, 16 February 2021 08:58 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
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 C85733A10CA for <tcpm@ietfa.amsl.com>; Tue, 16 Feb 2021 00:58:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 q8OWjLSUL1bJ for <tcpm@ietfa.amsl.com>; Tue, 16 Feb 2021 00:58:09 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0373A10C5 for <tcpm@ietf.org>; Tue, 16 Feb 2021 00:58:08 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id B1E3E25A24; Tue, 16 Feb 2021 09:58:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1613465886; bh=FJKtqcuJnc7++I4zAJEZYhgHdyz44M+jP8nV1ZISuS4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=wcQGm+bNti7nFXEAMNaaADX2u/KRo8I/MIKfE0yzu/usbAF3Aw+75i3IApatQScSz 1FA7JuVhdPkvruHmGe+4cJfpItadRrdK54VtEJrL5BDQVkUkRG7BKI/ZxtUjFpotG+ cV3UsXEm8Wwcjc7zj25dVgfuQWd3xSlqIA7Ig58U=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1otm_9susr7x; Tue, 16 Feb 2021 09:58:02 +0100 (CET)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 16 Feb 2021 09:58:02 +0100 (CET)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 16 Feb 2021 09:58:02 +0100
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.002; Tue, 16 Feb 2021 09:58:02 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>
CC: tcpm IETF list <tcpm@ietf.org>
Thread-Topic: [tcpm] 793bis ready to go?
Thread-Index: Adb+OMcXKdPjASFKQc+5zg7FPT9zRwByaXyAAArIJQAARyDrAAC93P1g
Date: Tue, 16 Feb 2021 08:58:02 +0000
Message-ID: <8f556136c1e0409d9f88c4153dae070d@hs-esslingen.de>
References: <cd600644350847ef8415d21588d1e912@hs-esslingen.de> <CAK6E8=fs_EaMpAEmpV=7_ZwmtugN=1rnuxRjfY4zPxEiyp8NgA@mail.gmail.com> <CADVnQym-W-KmR8ZN3sxSqyTBptU_tOm=u844b6-5xLRbmYtdiw@mail.gmail.com> <6D674614-847D-4600-9DE5-7FFD29043C7F@lurchi.franken.de>
In-Reply-To: <6D674614-847D-4600-9DE5-7FFD29043C7F@lurchi.franken.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.140.248]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/xjVsh8V1SViU0f0Oqh3oUVQUyVw>
Subject: Re: [tcpm] 793bis ready to go?
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: Tue, 16 Feb 2021 08:58:11 -0000

> > > Minor:  https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-
> 3.7.4
> >
> > I agree with Yuchung that it would be nice to clarify what is meant by "idle"
> connections (in the pre-existing text), with respect to keep-alives. It seems
> at least the historical behavior for two of the major implementations out
> there interpret this in different ways, and this has caused some confusion in
> the developer community about what semantics to expect from TCP keep-
> alives. I guess the rfc793bis-20 draft does have some nice new text (that
> does not seem to be in RFC793 or RFC1122) that seems to shed some light on
> this:
> >
> >    Keep-alive packets MUST only be sent when no sent data is
> >    outstanding, and no data or acknowledgement packets have been
> >    received for the connection within an interval (MUST-26).
> >
> >
> > That sentence helps quite a bit. It seems to correspond to the last 20 years
> of Linux TCP keep-alive behavior, but not the BSD behavior (at least BSD TCP
> as documented in Stevens volume 2; I have not checked more recent BSD
> kernels).
> Can elaborate what Linux behaviour you are referring to an what BSD
> behaviour you are referring to?

I'd also be interested in more details. Unfortunately, I am not familiar with BSD.

For what it is worth, RFC 1122 Section 4.2.3.6 "TCP Keep-Alives" states:

            Keep-alive packets MUST only be sent when no data or
            acknowledgement packets have been received for the
            connection within an interval.

So, the latter part of the sentence originates from RFC 1122.

Could somebody comment on whether recent BSD stacks would deviate from the proposed text in 793bis? That would be an important insight!

Michael