Re: [tcpm] meaning of "idle" for TCP Keep-Alives (was: 793bis ready to go?)

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Tue, 16 February 2021 09:03 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 0E94D3A10E2 for <tcpm@ietfa.amsl.com>; Tue, 16 Feb 2021 01:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, 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 DjJiMVpM8oBU for <tcpm@ietfa.amsl.com>; Tue, 16 Feb 2021 01:03:39 -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 B0FD43A10DC for <tcpm@ietf.org>; Tue, 16 Feb 2021 01:03:38 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 289D425A18; Tue, 16 Feb 2021 10:03:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1613466217; bh=mDpHhHnsEMDP5Sgo2BI09/cFZ7kwSsaNg9KBqSCzuW4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=FUGgTKEHQPM/C25XVATHuBTnCEitnfx+NaIy5kJtBtkCWOqoGwfmvRFUMbgI0srOF ItsAShifeEPvDQ7Fp9e3zU9yxS4IspANnK2AlZ/Gq0JrcQLxDUBF2fjqYwyCLgiMzr bfRXNi9aFCF0DA4HOjKSmNLCaCMqvfO6WDlh0rVw=
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 mHtTzcSy2_wH; Tue, 16 Feb 2021 10:03:35 +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 10:03:35 +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 10:03:35 +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 10:03:35 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
CC: tcpm IETF list <tcpm@ietf.org>
Thread-Topic: [tcpm] meaning of "idle" for TCP Keep-Alives (was: 793bis ready to go?)
Thread-Index: AQHXAhq8eiQ4bgp7kk2AmYui70jrzapagGoA
Date: Tue, 16 Feb 2021 09:03:35 +0000
Message-ID: <882be5a399ea4427a4879a4a485152f2@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> <CADVnQykUeU1oO16Qq=rVk=6SH6RZDXptmc=4x_1Y4uiPenjtGQ@mail.gmail.com>
In-Reply-To: <CADVnQykUeU1oO16Qq=rVk=6SH6RZDXptmc=4x_1Y4uiPenjtGQ@mail.gmail.com>
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: multipart/alternative; boundary="_000_882be5a399ea4427a4879a4a485152f2hsesslingende_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/dZDR68PGieiR20DyIR6m9PahhOg>
Subject: Re: [tcpm] meaning of "idle" for TCP Keep-Alives (was: 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 09:03:41 -0000

Apparently, I got confused by the headline when sending my previous e-mail. Sorry about that.

Nonetheless, I think it would be useful if somebody familiar with the BSD stack could review the current wording in 793bis…

Michael



From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Neal Cardwell
Sent: Saturday, February 13, 2021 4:12 PM
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: [tcpm] meaning of "idle" for TCP Keep-Alives (was: 793bis ready to go?)

On Fri, Feb 12, 2021 at 10:19 AM Michael Tuexen <Michael.Tuexen@lurchi.franken.de<mailto:Michael.Tuexen@lurchi.franken.de>> wrote:
> On 11. Feb 2021, at 06:22, Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org<mailto:40google.com@dmarc.ietf.org>> wrote:
>
> The wording in the Congestion Control section looks great to me.
>
> > 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?

BSD: My reading of the behavior in older BSD releases (BSD-4_2 [1983] through BSD-4_4_Lite2 [1995], or Stevens volume 2 [1995]) is that a TCP endpoint resets the keep-alive timer (tp->t_timer[TCPT_KEEP]) to its full keep-alive interval upon receiving a packet, and then when the timer fires it sends a keep-alive probe packet (case TCPT_KEEP in tcp_timers() in tcp_timer.c). When that keep-alive timer fires it seems to send a keep-alive packet irrespective of whether the TCP endpoint currently has data outstanding in the network, or is sending ZWP packets.

Linux: Starting in Linux 2.3.41 in Jan 2000, and continuing through current releases, the Linux TCP keep-alive timer code in tcp_keepalive_timer() has two simple extra checks introduced:
  https://elixir.bootlin.com/linux/2.3.41/source/net/ipv4/tcp_timer.c#L729
The checks basically say that if the keep-alive timer goes off but the TCP endpoint has data outstanding in the network (RTO timer is set), or outgoing data queued and waiting for a non-zero receive window (ZWP timer is set), then the code merely resets the keep-alive timer, and short-circuits all the keep-alive processing that would send a keep-alive probe packet or check to see if the connection should be torn down. This behavior is similar to the rfc793bis-20 text,  "Keep-alive packets MUST only be sent when no sent data is  outstanding", except that it also skips sending a keep-alive when the sender is in the process of sending repeated zero window probes (which would also serve to tell whether the remote endpoint is reachable).

best,
neal