[tcpm] 793bis wording on TCP keep-alives

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Mon, 21 October 2019 10:37 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
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 1AB261201DB for <tcpm@ietfa.amsl.com>; Mon, 21 Oct 2019 03:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 YevkqDL0mex4 for <tcpm@ietfa.amsl.com>; Mon, 21 Oct 2019 03:37:09 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8EC71201DC for <tcpm@ietf.org>; Mon, 21 Oct 2019 03:37:08 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 293E625A25; Mon, 21 Oct 2019 12:37:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1571654227; bh=nDlUGMCT6SjMSqyV/UBedfSrikZRjTPRgVJNcyZ0D8U=; h=From:To:CC:Subject:Date:From; b=Lr7NFXvV7ANcBgFKKolKe8qNfqUOO21xqq+UYZRI4kdHG8sM1Cxn15Isb2kSFzBTg BKUQKoIsDB5tLB5WRDkE4FD7nHJe4lPKlnqe3mzDmwjevrS26yuA2VCsANpSWH1B61 j93muedS/nGDUG+YyNeAQy2zVjpZabCjtRQ4rSQw=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoZkdTs0_4Ha; Mon, 21 Oct 2019 12:37:06 +0200 (CEST)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 21 Oct 2019 12:37:06 +0200 (CEST)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 21 Oct 2019 12:37:06 +0200
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Wesley Eddy <wes@mti-systems.com>
CC: "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: 793bis wording on TCP keep-alives
Thread-Index: AdWH+eHSZJ72bo5bT1KmKh8OwI3e1A==
Date: Mon, 21 Oct 2019 10:37:05 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4AF868@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.29.249]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/jkeL8xUj0V51XPfXhHTgr6m_X0c>
Subject: [tcpm] 793bis wording on TCP keep-alives
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: Mon, 21 Oct 2019 10:37:11 -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