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

"Scheffenegger, Richard" <rs.ietf@gmx.at> Tue, 16 February 2021 11:49 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 C9E773A0958; Tue, 16 Feb 2021 03:49:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmx.net
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 VkYuX1fUCuom; Tue, 16 Feb 2021 03:49:01 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 9CF5E3A0957; Tue, 16 Feb 2021 03:49:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613476126; bh=JST8xN2xSqhHo4K0qKa64rMO3vImmgv6orTXdZxa+js=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=gi00h9V+T6kYY/+bVIwBZEeBvPFiUTJthKM0VHwfYWk0oGuAnY1NywtMzJEHb8S48 GPOKLFjEvvX1bp4jXGFBws6iXw9ZLv10S5uRg25J1ZT2omA5oqYdprpf4DlTtO5qyV YJbs8XBwbqZFTKACEYHylHKsjj55XQuArdWs61Xs=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.233.106] ([185.236.167.136]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MTzfG-1lKGbM0rpq-00R2Qi; Tue, 16 Feb 2021 12:48:46 +0100
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Cc: tcpm IETF list <tcpm@ietf.org>, freebsd-transport@freebsd.org
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> <882be5a399ea4427a4879a4a485152f2@hs-esslingen.de>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <27952497-a9fa-5f97-c923-d78fa9add0dc@gmx.at>
Date: Tue, 16 Feb 2021 12:48:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <882be5a399ea4427a4879a4a485152f2@hs-esslingen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:1hPWqzxGYolmaur0RSfGTRJ9pxxxP7qpyOUY7Ll1CojJpF/cYfw XeGWVxqAefrHcnUx3U2H9H39+jnYpwzjB3IVjz1qv7KEaXb1QdRTSuYE4JOknn/PmOPHdWX ps7zrHlMLy3N/dBZg0sBJImDrCMU9f0srS9SA6oca9p7EZa5jiMXd6OAhikI82Y4qGphPg0 hAkV6xja97hOkoSQXJ8dw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:55SJ2kiWqvc=:uT0jASjrCpqg6g5u+Tduum D83c0crY17xPpkSuYk87Rfi/ZrcNxOYmxxbSfs7ZSiDW7aViOBaOlnHF/TaoGseg5GpJ4BIKs N+J40eMXZaY/P8Kw+EGQ8fymj+93eMZM8YAGerKEwjxNnN23XBpIfm2WRRLnSfPBx5IFawo4B mSvb93wgD0oeGDE2P4eHyA06empESbejAdfkMTqa8SQafAqsrTuTADEg/+djrrvKpxLzLEgCB 6jA/ccVum1vIWuuvn2csYECJF/ETnqU4IenidEzCqmN1M1WTVxKjPt6OEsvkl4LQwMVrkNENh B+KMA1By/uaKZ9ai98j3LanzVSZ2tZs23B1YSZxVNAuz1LGA7a8MTXo/xbtlw6xVViVNXkNfj cTug4NxEIdyohcxNj1chVaoJ0XJJ181t4pr59oWplrSebVPXTChhej/wUr99wC5s1wa347y3J mOd8qLKQD1gnTQ4qTbA4u2DvCaSm/8bOE+QIITQiEBmDclr/Hldu0y+AjqIDVTRkmWs9IreYj HrSXTBzEMtnKgttJeCE5DVoIDjeplL4NWHVZA+Rl4Mi4mBWEn1fI3RObJz30F2ALOZQaWfQXv LOT0Bn0WRhR0NK3ECFksiA+/NzNkd3oYvEvKflSkVNP8etvfGMayWzxgbSk2Q97LtrrsNI69N zjj/WpymnxBTHdHKu8mo9GJ7HZms+oUGVSJpc3lgTnmgWbJT54pMF+knFp6MCifNGvYo5bsi3 a4FteL/uxdXnUqDbPPnYwWTikPV1ZP5ugJtSSV7D4K/SATMAfysOwM0L5z6kkSwPHehaNFZC7 ySrFl3Oh9jbxoCBen3sYKUsrSITGUO8HHAD3pOEqtLqe7wkghojmjK1bj4dBhKY+/GqTzqrjB 0qK9ok5eSissSE+n6XPg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/zle23WvsjkxqCHaQ5jFx1s7EzC8>
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 11:49:04 -0000

I think the wording in 793bis is reasonable.

Also, I am not aware of a deviation from this behavior in any recent BSD
kernels - OTOH it is hard to get to a point with outstanding data, when
the keepalive timer fires (the outstanding data will have been
retransmitted by means of the RTO timer firing multiple times, and the
session most likely having been closed well before keepalive would
become relevant.

A quick inspection of the code appears to implement the 2nd half of the
statement "verbatim", relying on the much shorter RTO timers to deal
with the first half.

Strictly speaking, a socket could be configured with TCP_KEEPIDLE set to
1 sec, which could potentially cause the keepalive timer to fire prior
to the expiration of all RTO attempts.

Best regards,
   Richard


Am 16.02.2021 um 10:03 schrieb Scharf, Michael:
> 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
>     <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
> <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
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>