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

[Scheffenegger, Richard]

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 at ietf.org> *On Behalf Of * Neal Cardwell
> *Sent:* Saturday, February 13, 2021 4:12 PM
> *To:* Michael Tuexen <Michael.Tuexen at lurchi.franken.de>
> *Cc:* tcpm IETF list <tcpm at 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 at lurchi.franken.de
> <mailto:Michael.Tuexen at lurchi.franken.de>> wrote:
>
>      > On 11. Feb 2021, at 06:22, Neal Cardwell
>     <ncardwell=40google.com at dmarc.ietf.org
>     <mailto:40google.com at 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 at ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>