Subject: [tcpm] 793bis ready to go?

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 8 Feb 2021 17:00:07 +0000

Dear all,

draft-ietf-tcpm-rfc793bis-20 has been submitted recently. According to Wes, all WGLC feedback should be reflected in this version. A link to a complete diff can be found below.

During WGLC, there has been quite some discussion on the exact wording on congestion control. The suggested text in version -20 is copied below:

3.7.2.  TCP Congestion Control

   RFC 2914 [7] explains the importance of congestion control for the
   Internet.

   RFC 1122 required implementation of Van Jacobson's congestion control
   algorithms slow start with congestion avoidance together with
   exponential back-off for successive RTO values for the same segment.
   RFC 2581 provided IETF Standards Track description of slow start and
   congestion avoidance, along with fast retransmit and fast recovery.
   RFC 5681 is the current description of these algorithms and is the
   current Standards Track specification providing guidelines for TCP
   congestion control.  RFC 6298 describes exponential back-off of RTO
   values, including keeping the backed-off value until a subsequent
   segment with new data has been sent and acknowledged.

   A TCP endpoint MUST implement the basic congestion control algorithms
   slow start, congestion avoidance, and exponential back-off of RTO to
   avoid creating congestion collapse conditions (MUST-19).  RFC 5681
   and RFC 6298 describe the basic algorithms on the IETF Standards
   Track that are broadly applicable.  Multiple other suitable
   algorithms exist and have been widely used.  Many TCP implementations
   support a set of alternative algorithms that can be configured for
   use on the endpoint.  An endpoint may implement such alternative
   algorithms provided that the algorithms are conformant with the TCP
   specifications from the IETF Standards Track as described in RFC
   2914, RFC 5033 [10], and RFC 8961 [15].

   Explicit Congestion Notification (ECN) was defined in RFC 3168 and is
   an IETF Standards Track enhancement that has many benefits [50].

   A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD-
   8).

As document shepherd I ask everybody - specifically all TCPM contributors who have commented on congestion control - to carefully review this proposed wording within the next few days. If there are any issues with this suggested resolution of the WGLC, please speak up!

If the TCPM working group is fine with version -20, 793bis would be ready to go.

Thanks

Michael

-----Original Message-----
From: I-D-Announce <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, January 21, 2021 7:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-tcpm-rfc793bis-20.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.

        Title           : Transmission Control Protocol (TCP) Specification
        Author          : Wesley M. Eddy
	Filename        : draft-ietf-tcpm-rfc793bis-20.txt
	Pages           : 110
	Date            : 2021-01-21

Abstract:
   This document specifies the Transmission Control Protocol (TCP).  TCP
   is an important transport layer protocol in the Internet protocol
   stack, and has continuously evolved over decades of use and growth of
   the Internet.  Over this time, a number of changes have been made to
   TCP as it was specified in RFC 793, though these have only been
   documented in a piecemeal fashion.  This document collects and brings
   those changes together with the protocol specification from RFC 793.
   This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,
   6429, 6528, and 6691 that updated parts of RFC 793.  It updates RFC
   1122, and should be considered as a replacement for the portions of
   that document dealing with TCP requirements.  It also updates RFC
   5961 by adding a small clarification in reset handling while in the
   SYN-RECEIVED state.  The TCP header control bits from RFC 793 have
   also been updated based on RFC 3168.

   RFC EDITOR NOTE: If approved for publication as an RFC, this should
   be marked additionally as "STD: 7" and replace RFC 793 in that role.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-20

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 10 Feb 2021 16:14:05 -0800

I think it's ready. Kudos to Wes for the N-years-long effort to put
this together!

Minor:  https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4

The less clear part is the wording of "idle connections". Idleness can
be interpreted in several ways: no recent rx, tx, or both {on the wire
| on socket interface}. It'd be good to define more clearly. AFAIK
implementations have different definitions already leading to
different KA behaviors.

On Mon, Feb 8, 2021 at 9:00 AM Scharf, Michael
<[email-masked]> wrote:
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 11 Feb 2021 00:33:17 +0000

The new text on congestion control looks good to me.

Thanks!

-----Original Message-----
From: tcpm <[email-masked]> On Behalf Of Scharf, Michael
Sent: Monday, February 8, 2021 9:00 AM
To: tcpm IETF list <[email-masked]>
Subject: [EXTERNAL] [tcpm] 793bis ready to go?

Dear all,

Thanks

Michael

-----Original Message-----
From: I-D-Announce <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, January 21, 2021 7:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-tcpm-rfc793bis-20.txt

Abstract:

The IETF datatracker status page for this draft is:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tcpm-rfc793bis%2F&amp;data=04%7C01%7Cpravb%40microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637484005105023530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2B%2Fnf5AfiOwW4PZPhtsSHFCnbRVMr%2FJm93crEUHDnYI8%3D&amp;reserved=0

There are also htmlized versions available at:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tcpm-rfc793bis-20&amp;data=04%7C01%7Cpravb%40microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637484005105023530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=BhTeT76PMXuFVHNFfHqvt%2FDSBjNO3L1f%2BE371FYlOos%3D&amp;reserved=0
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-tcpm-rfc793bis-20&amp;data=04%7C01%7Cpravb%40microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637484005105023530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HgfUOg8gyzOO5Eox2qQFaOEKE4LBUT9Vr5Z7jO5LfSU%3D&amp;reserved=0

A diff from the previous version is available at:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-tcpm-rfc793bis-20&amp;data=04%7C01%7Cpravb%40microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637484005105033531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=yKJ3SXtv%2F0kuNXM%2BqRr7CiAOzmFqT1xzSLbMgx%2FTRYo%3D&amp;reserved=0

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
https://nam06.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&amp;data=04%7C01%7Cpravb%40microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637484005105033531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=lepBojFHU0gmFdbX5dXzZMK4SqEhrRGVwB8jFhGvgdk%3D&amp;reserved=0

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announce&amp;data=04%7C01%7Cpravb%40microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637484005105033531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=gbaTueD1oZCj48owt5KHKUHGqf6NwiEZuuwvvoMJyQk%3D&amp;reserved=0
Internet-Draft directories: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ietf.org%2Fshadow.html&amp;data=04%7C01%7Cpravb%40microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637484005105033531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=vMmLSaybns3dvCyFYBEYetOXiQK1rVrlKix3NnBg7HE%3D&amp;reserved=0
or https://nam06.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Fietf%2F1shadow-sites.txt&amp;data=04%7C01%7Cpravb%40microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637484005105033531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=a8WU5cGZzUnk11uO9oF9twtuRiKleFJW%2BwS2S%2ByPdUU%3D&amp;reserved=0

_______________________________________________
tcpm mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=04%7C01%7Cpravb%40microsoft.com%7Cc71f0d77739149fcaf7308d8cc530882%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637484005105033531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ecsv4xXHJXAeg4yJJ14vpJnrnVIhibLqYi0La91DTwg%3D&amp;reserved=0

---

From: Neal Cardwell <[email-masked]>
Date: Thu, 11 Feb 2021 00:22:48 -0500

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).

And, yes, thank you, Wes for all your years of effort on this!

neal

On Wed, Feb 10, 2021 at 7:14 PM Yuchung Cheng <[email-masked]> wrote:

> Minor:
> https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4
>
> > draft-ietf-tcpm-rfc793bis-20 has been submitted recently. According to
> Wes, all WGLC feedback should be reflected in this version. A link to a
> complete diff can be found below.
> >
> > During WGLC, there has been quite some discussion on the exact wording
> on congestion control. The suggested text in version -20 is copied below:
> >
> > As document shepherd I ask everybody - specifically all TCPM
> contributors who have commented on congestion control - to carefully review
> this proposed wording within the next few days. If there are any issues
> with this suggested resolution of the WGLC, please speak up!
> >

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 12 Feb 2021 16:19:26 +0100

> On 11. Feb 2021, at 06:22, Neal Cardwell <ncardwell=[email-masked]> wrote:
> 
> 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:
> 
> 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?

Best regards
Michael

---

From: Martin Duke <[email-masked]>
Date: Fri, 12 Feb 2021 07:52:58 -0800

I agree that the congestion control text skillfully threads the needle
between Standards Track and reality. Well done!

On Fri, Feb 12, 2021 at 7:19 AM Michael Tuexen <
[email-masked]> wrote:

> BSD TCP as documented in Stevens volume 2; I have not checked more recent
> BSD kernels).

---

From: Neal Cardwell <[email-masked]>
Date: Sat, 13 Feb 2021 10:12:28 -0500

> 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

---

From: "Scharf, Michael" <[email-masked]>
Date: Tue, 16 Feb 2021 08:58:02 +0000

> > 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:
> >
> > 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).

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

---

From: "Scharf, Michael" <[email-masked]>
Date: Tue, 16 Feb 2021 09:03:35 +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 <[email-masked]> On Behalf Of Neal Cardwell
Sent: Saturday, February 13, 2021 4:12 PM
To: Michael Tuexen <[email-masked]>
Cc: tcpm IETF list <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
> On 11. Feb 2021, at 06:22, Neal Cardwell <ncardwell=[email-masked]<mailto:[email-masked]>> wrote:
>

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

---

From: Jonathan Morton <[email-masked]>
Date: Tue, 16 Feb 2021 11:40:41 +0200

> On 8 Feb, 2021, at 7:00 pm, Scharf, Michael <[email-masked]> wrote:
> 

I agree that this is substantially the right approach.  One quibble is that the word "may" is used, but not capitalised and given a corresponding MAY-X entry in Appendix B.  I think it would be appropriate to do so here, in the last sentence above.

 - Jonathan Morton

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 16 Feb 2021 12:48:44 +0100

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:
> Nonetheless, I think it would be useful if somebody familiar with the
> BSD stack could review the current wording in 793bis…
>
> Michael
>
> *From:* tcpm <[email-masked]> *On Behalf Of * Neal Cardwell
> *Sent:* Saturday, February 13, 2021 4:12 PM
> *To:* Michael Tuexen <[email-masked]>
> *Cc:* tcpm IETF list <[email-masked]>
> *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
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>      > On 11. Feb 2021, at 06:22, Neal Cardwell
>     <ncardwell=[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>     <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:
>      >
>      > 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).
> 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
>
>

---

From: Markku Kojo <[email-masked]>
Date: Tue, 16 Feb 2021 16:12:50 +0200 (EET)

The CC test looks good. Just two minor things: one editorial and another 
small addition to address exponential backoff more accurately and 
correctly. See inline.

>   algorithms slow start with congestion avoidance together with

Here

  "SS with CA together with ..."

reads a bit odd to me. But not sure as a non-native speaker. Would it 
possibly read better if changed to(?):

  "algorithms slow start and congestion avoidance together with
   exponential back-off ..."

OR:

   "algorithms slow start, congestion avoidance, and exponential
    back-off ..."

>   segment with new data has been sent and acknowledged.

It would be useful to make the last sentence unambiguous as per Karn's 
original specification:

   "segment with new data has been sent and acknowledged without
    retransmission."

Thanks,

/Markku

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 18 Feb 2021 14:59:55 +0100

One more nit, around dealing with data-in-SYN,ACK

793bis (page 71) has this text, which unfortunately doesn have any
RFC2119 language.

But in short, it seems to require the transmission of a pure ACK just
for the SYN bit, and a 2nd ACK right afterwards (step 6) to acknowledge
the data.

The FBSD implementation was found to skip over the ACK-only-the-SYN
intermediate step (which must be acceptable, as that ACK may get lost in
the network), sending out only the cummulative ACK for SYN and data,
after having transitioned into ESTABLISHED.

But strictly speaking, this behavior is a deviation from 793 / 793bis.

Perhaps a "and should send it" would do, to allow this behavior,
conserving one pure ACK...

Best regards,
    Richard

  If the state is SYN-SENT then

          first check the ACK bit

             If the ACK bit is set
:
:
fourth check the SYN bit

             This step should be reached only if the ACK is ok, or there
             is no ACK, and it the segment did not contain a RST.

             If the SYN bit is on and the security/compartment is
 >>>         acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to
             SEG.SEQ.  SND.UNA should be advanced to equal SEG.ACK (if
             there is an ACK), and any segments on the retransmission
             queue that are thereby acknowledged should be removed.

             If SND.UNA > ISS (our SYN has been ACKed), change the
             connection state to ESTABLISHED, form an ACK segment

 >>>            <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

             and send it.  Data or controls that were queued for
             transmission may be included.  If there are other controls
or text in the segment then continue processing at the sixth
             step below where the URG bit is checked, otherwise return.

---

From: [email-masked]
Date: Sat, 20 Feb 2021 21:56:00 +0100

> On 18. Feb 2021, at 14:59, Scheffenegger, Richard <[email-masked]> wrote:
> 
Hi,

I really prefer the FreeBSD behaviour. A TCP stack should not need to send
two segments at the same time when handling the event of a single segment reception.

Best regards
Michael, as an individual

---

From: Joseph Touch <[email-masked]>
Date: Sat, 20 Feb 2021 13:37:47 -0800

Even if you prefer the FreeBSD variant, the text below doesn’t appear to fix this; it will end up sending the SYN-ACK of the received data *and a second ACK* at the end of the sixth step.

Joe

> On Feb 20, 2021, at 12:56 PM, [email-masked] wrote:
>

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 20 Feb 2021 22:53:38 +0100

> On 20. Feb 2021, at 22:37, Joseph Touch <[email-masked]> wrote:
> 
I think the idea of Richard is that if the text is

         and should send it.

Then NOT following the should, but only send the ACK at the end of step 6.
Wouldn't that work?

Best regards
Michael

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sun, 21 Feb 2021 15:33:24 +0100

Well, making the transmission of the ACK-only-the-SYN optional when data
is present, which needs to be ACK'd anyway..

That way, current FBSD and Linux behaviour both would comply with
793bis, while I agree with Michael T. that the behavior of FBSD is more
efficient.

Richard

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 21 Feb 2021 19:06:58 +0100

> On 21. Feb 2021, at 15:33, Scheffenegger, Richard <[email-masked]> wrote:
> 
> 
Hi Richard,

I'm not sure about your statement about compliance of the Linux stack.
My testing show that the following packetdrill scripts succeeds:

 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0.000 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
+0.000 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
+0.000 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
+0.000 > S    0:0(0)             win 64240 <mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 7>
+0.050 < S.   0:512(512) ack   1 win 65535 <mss 1460,sackOK,eol,eol>
+0.000 >  .   1:1(0)     ack   1 win 64240
+0.000 recv(3, ..., 1024, 0) = -1 EWOULDBLOCK (Operation would block)
+0.000 close(3) = 0
+0.000 > F.   1:1(0)     ack   1 win 64240
+0.000 < F.   1:1(0)     ack   2 win 65535
+0.000 >  .   2:2(0)     ack   2 win 64239

This means that the data on the SYN-ACK is simply dropped. I don't think
this is the handling described in RFC 793.

MacOS handles the case similar to FreeBSD.

Best regards
Michael

---

From: Joseph Touch <[email-masked]>
Date: Sun, 21 Feb 2021 10:38:19 -0800

> Then NOT following the should, but only send the ACK at the end of step 6.

FWIW, I think the case of combining the bare ACK with the ACK of the received SYN-ACK data is already covered in the sixth step below in the following text:

        This acknowledgment should be piggybacked on a segment being
        transmitted if possible without incurring undue delay.

If this needs to be made more explicit, here’s my suggestion:

OLD:

        If SND.UNA > ISS (our SYN has been ACKed), change the connection
        state to ESTABLISHED, form an ACK segment

        and send it.  Data or controls which were queued for
        transmission may be included.  If there are other controls or
        text in the segment then continue processing at the sixth step
        below where the URG bit is checked, otherwise return.

NEW:

        If SND.UNA > ISS (our SYN has been ACKed), change the connection
        state to ESTABLISHED, form an ACK segment

        Data or controls which were queued for
        transmission MAY be included in this segment.  If there are no 
	other controls or text in the segment then send the ACK segment 
	and return. Otherwise, continue processing at the sixth step below 
	where the URG bit is checked, either sending the ACK segment now or 
	piggybacking it with the response from that continued processing
	(as noted therein).

Joe

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 21 Feb 2021 20:15:30 +0100

> On 21. Feb 2021, at 19:38, Joseph Touch <[email-masked]> wrote:
> 
I agree, this covers it. But it would be good to have it a bit more explicit.
> 	other controls or text in the segment then send the ACK segment 
Maybe:
         other controls or text in the received segment then send the ACK segment 
> 	piggybacking it with the response from that continued processing
I like your proposal (maybe with the above suggestion).

Best regards
Michael

---

From: Joe Touch <[email-masked]>
Date: Sun, 21 Feb 2021 11:39:34 -0800

Works for me. 

> On Feb 21, 2021, at 11:16 AM, Michael Tuexen <[email-masked]> wrote:
> 
> 
>>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 22 Feb 2021 11:17:34 +0100

I also like the word-smithing the two of you came up with. That text
reads exactly like what I would like to know in that instance, where I
to implement the behavior.

Thanks!