Re: statement regarding keepalives

Joe Touch <> Fri, 20 July 2018 17:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A18D0130F74; Fri, 20 Jul 2018 10:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uBXQ-EUA6X7q; Fri, 20 Jul 2018 10:35:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 98276130DEE; Fri, 20 Jul 2018 10:35:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=e0u/EgGIslFfQfnh0TeEienaGfZr9aOAS4X+voudOMA=; b=UbmSRGNLLzMlKTUGWi4cP7iDf XABT5l6EntlMa+3MmAN6n/fMV0ATtSgCtTaTYPSP4RZaA0pnew+I2nPMTqeaRqwFGCqKND7+2GPh4 XhpXfEqCRTkFt87stKB+y9suv1LiYJ8u+cnpPK6Fd2rPi9lTLyO3y2yHBWx72x0Lx20MgPj7X3Zri pBFkIyyuXVFuaSGBFzlO40Jp73620TAPdODFRY71yVgebiI+wPQm/lJ0Z/KnKdKhO+JQpncyU0Rgl /OX7gv4xyAvZVgfsBh9Jh3qfhvne8s/CDWiJt3cCzMrrV2Z7pgvdHW6YF52KXm5Mg7VnOOzcht4dK Uyzkq+/kg==;
Received: from [::1] (port=34954 by with esmtpa (Exim 4.91) (envelope-from <>) id 1fgZJP-003cDo-PL; Fri, 20 Jul 2018 13:35:28 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_e080087503023a74f014e8d2f3baadf9"
Date: Fri, 20 Jul 2018 10:35:27 -0700
From: Joe Touch <>
To: Kent Watsen <>
Cc: HMikael Abrahamsson <>,,,,
Subject: Re: statement regarding keepalives
In-Reply-To: <>
References: <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/1.3.3
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Jul 2018 17:35:35 -0000

Hi, Kent, 

For keepalives, I think there are some more useful recommendations than
are currently proposed. Here's my cut: 

- keepalives SHOULD be used at *every* protocol layer where it is
important to retain state (connectivity) in the absence of traffic from
higher layers 

- keepalives at a layer SHOULD be suppressed in the presence of
sufficient traffic from higher layers  

- keepalives at a layer SHOULD NOT be interpreted as implying state at
any other layer (this was the error that BGP once made, i.e., assuming
that if TCP could not keep state then the route should be dropped) 

IMO, these are necessary and sufficient.  

I don't think there should be any other statement about the relative
timing of keepalives at different layers or that keepalives should be
driven by the highest layer possible. That's just silly - e.g., if the
app layer doesn't care about keeping state but the lower layer benefits,
there's no reason to rewrite the app just to keep the function out of
the transport layer(s). 


On 2018-07-20 08:14, Kent Watsen wrote:

>> ...but still don't put off people turning on TCP keepalives "because
>> the IETF doesn't recommend that", and thus they do nothing at all and
>> the problem just persists.
> No disagreement with what you and others have written, but note that 
> the proposed statement only recommends not using TCP keepalives in
> the presence of a crypto layer on top of the TCP-layer.
> Perhaps the statement could be refined, something along the lines 
> of, in cases when there is a crypto layer, to recommend not using,
> or at least relying on, TCP keepalives, *unless* higher-level
> keepalives have stopped working.
> To be clear, the statement as written, though not stated explicitly,
> recommends TCP keepalives, in cases where they make sense.
> Kent