Subject: [tcpm] 793bis wording on TCP keep-alives

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 21 Oct 2019 10:37:05 +0000

Hi Wes,

after reading Section 3.8.4. "TCP Keep-Alives" in 793bis, I would suggest to copy a bit more text from RFC 1122 to better define keep-alives.

Background: RFC 1122 does not formally define "keep-alive" in the normative part, but it mentions implementation behavior in the DISCUSSION text:
 
  Some TCP implementations, however, have included a
  keep-alive mechanism.  To confirm that an idle
  connection is still active, these implementations send
  a probe segment designed to elicit a response from the
  peer TCP.  Such a segment generally contains SEG.SEQ =
  SND.NXT-1 and may or may not contain one garbage octet
  of data. 
 
In RFC 1122, only this DISCUSSION text describes what a "probe segment" could be and what "garbage octet" implies.

Currently 793bis only copies the normative text from RFC 1122, and therefore it does not define these concepts.

My proposal would be to copy also the cited text from RFC 1122 to 793bis to provide more background, e.g., along the lines of:
 
793bis OLD:
 
   Implementors MAY include "keep-alives" in their TCP implementations
   (MAY-5), although this practice is not universally accepted.  If
   keep-alives are included, the application MUST be able to turn them
   on or off for each TCP connection (MUST-24), and they MUST default to
   off (MUST-25).

  [... and more sections on probe segments and garbage octet...]
 
793bis NEW:
 
   Implementors MAY include "keep-alives" in their TCP implementations
   (MAY-5), although this practice is not universally accepted. Some
   TCP implementations, however, have included a keep-alive mechanism.
   To confirm that an idle connection is still active, these implementations
   send a probe segment designed to elicit a response from the peer TCP.
   Such a segment generally contains SEG.SEQ = SND.NXT-1 and may or may not
   contain one garbage octet of data. If keep-alives are included, the
   application MUST be able to turn them on or off for each TCP connection
   (MUST-24), and they MUST default to off (MUST-25).

  [... rest of existing text...]
 
The additional text is literally taken from RFC 1122 and therefore should not be problematic.

Thanks
 
Michael

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 21 Oct 2019 22:25:03 -0400

Hi Michael, I totally agree with your proposal on this.  The change is 
simple and adds clarity; thanks!  I will put this into my working copy, 
unless there is any disagreement raised in the meantime.