From owner-freebsd-transport@freebsd.org Tue Feb 16 11:48:58 2021 Return-Path: Delivered-To: freebsd-transport@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1EDD853475E for ; Tue, 16 Feb 2021 11:48:58 +0000 (UTC) (envelope-from rs.ietf@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DfzlF5r4Zz3l3h for ; Tue, 16 Feb 2021 11:48:57 +0000 (UTC) (envelope-from rs.ietf@gmx.at) 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 Subject: Re: [tcpm] meaning of "idle" for TCP Keep-Alives (was: 793bis ready to go?) To: "Scharf, Michael" , Neal Cardwell , Michael Tuexen Cc: tcpm IETF list , freebsd-transport@freebsd.org References: <6D674614-847D-4600-9DE5-7FFD29043C7F@lurchi.franken.de> <882be5a399ea4427a4879a4a485152f2@hs-esslingen.de> From: "Scheffenegger, Richard" 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-Spam-Flag: NO 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== X-Rspamd-Queue-Id: 4DfzlF5r4Zz3l3h X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Mailman-Approved-At: Tue, 16 Feb 2021 15:55:49 +0000 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2021 11:48:58 -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=E2=80=A6 > > Michael > > *From:* tcpm *On Behalf Of * Neal Cardwell > *Sent:* Saturday, February 13, 2021 4:12 PM > *To:* Michael Tuexen > *Cc:* tcpm IETF list > *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 > > wrote: > > > On 11. Feb 2021, at 06:22, Neal Cardwell > > 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: > > > >=C2=A0 =C2=A0 Keep-alive packets MUST only be sent when no sent da= ta is > >=C2=A0 =C2=A0 outstanding, and no data or acknowledgement packets = have been > >=C2=A0 =C2=A0 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=C2=A0BSD-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=C2=A0tcp_timers() in tcp_timer.c). When that keep-alive timer fires i= t > 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=C2=A0rfc793bis-20 text,=C2=A0 "Kee= p-alive > packets MUST only be sent when no sent data is=C2=A0 outstanding", excep= t > 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 >