Re: statement regarding keepalives

Tom Herbert <tom@herbertland.com> Fri, 17 August 2018 16:05 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738A6130E42 for <tsv-area@ietfa.amsl.com>; Fri, 17 Aug 2018 09:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 XymDRgkdUOGn for <tsv-area@ietfa.amsl.com>; Fri, 17 Aug 2018 09:05:53 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F11112426A for <tsv-area@ietf.org>; Fri, 17 Aug 2018 09:05:53 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id 89-v6so1224445qkp.2 for <tsv-area@ietf.org>; Fri, 17 Aug 2018 09:05:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hqtqBu5mbJs7gKJnEKeLx9vJ2kHw94s90phgITwSPbw=; b=IzdiSYqXWLeKRKCl5gRPTWLUL+AT93ObgpHtWRuJRfyD2xCw8VHpRyZxz3msueB385 u+8811lsge2oaXrDQAauYBWoBef+0RKXcZVKxA2Gw1LB8Pk0SkplVTCPphYhEmUhQysd rtlHR9h5o6u2Z1OM4iJKK/XpESTYWfgBRdMWlUT0yqbI1DPJd/jiWaTE1nZl6+5k9TrL eHnapJIWJWW6cRbnXhzfI/SvIjJs0hPtg8iwOcs0QWJQ693qel8F4buSDum53JtSwELY wheMhUss8lx4ts5BDCJe0ce82PFvICsIKqj59R76q+LBIWL/lootdjT5ZUuKvFNUmX/u 0yiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hqtqBu5mbJs7gKJnEKeLx9vJ2kHw94s90phgITwSPbw=; b=kIhqh6EK7rXTxLY/IbBoo9i7n6rlWwiYwBCWnkf8dynSv2Y06QA4yLGIC3OO2h3w6Q qP00LjjNQ4C7pS/7BZkNJMoMICiJIhR6SBpN4F0xCv0LtUBKC61VJKyqB/XxGm9KnZmY q5RqqgaDnhR/td4I+iaIYEuYZbfBKnR8U36SHl8Is8MGeylLgWOrJjuUWPdjDL4TOauV bIJDRc1SDNzNTwZpyVYS87p3nzhG8NF0+Lc3FXTQEJmyMzJs4fwgeFl9QaSHQeUwjoKM UzI7nxRe2Z8bG68yDyaJpyF+ZmU/4kzoOWLMB3t+nATj5C6I+/FtLN+YJY7wk08+BQ2K JVHQ==
X-Gm-Message-State: AOUpUlHLQO7KUcFY38QYuypC7FYAOZckpijrs5tZV7Dq35WzmXO8IjOo uR7KomYfCa7XrMjHM2sSK37LAK7Uf/1VJ82HcyAMBQ==
X-Google-Smtp-Source: AA+uWPwgKTQ9uW9ZtLRsF/vi3Fptntq6shVQFVxpXDB55+FX5zwlbMy3fccMXdBt4pfzEyHUWFu4H+oxVVDq1tDTzbg=
X-Received: by 2002:a37:c946:: with SMTP id q67-v6mr33932117qki.148.1534521951875; Fri, 17 Aug 2018 09:05:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Fri, 17 Aug 2018 09:05:51 -0700 (PDT)
In-Reply-To: <A0293639-EC0A-4559-9447-E58CDB8970FC@strayalpha.com>
References: <D3326DE0-3F31-4045-B945-82B3F417BE4B@juniper.net> <alpine.DEB.2.20.1807201340240.14354@uplift.swm.pp.se> <B50DC954-CBB6-41C5-BE3A-F1DECD6046A5@juniper.net> <717202c9c6c6b3d083bfa4c8a9925e45@strayalpha.com> <6377766E-9A03-41BA-A4D4-8796F46278BD@juniper.net> <20180816221059.GG40887@kduck.kaduk.org> <B3FA514D-4082-4C36-B487-B9B6AB46BF9D@strayalpha.com> <20180816225715.GH40887@kduck.kaduk.org> <A0293639-EC0A-4559-9447-E58CDB8970FC@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 17 Aug 2018 09:05:51 -0700
Message-ID: <CALx6S34o1DJ6Nmin23GSNF_o-ddVEHX0_5qMohnxJxmh-BqH9w@mail.gmail.com>
Subject: Re: statement regarding keepalives
To: Joe Touch <touch@strayalpha.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "tls-ads@ietf.org" <tls-ads@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>, "tsvwg-ads@tools.ietf.org" <tsvwg-ads@tools.ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/DesOgDm8AOR5WqA-Y-3uXN-89Cw>
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-area/>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Aug 2018 16:05:55 -0000

On Fri, Aug 17, 2018 at 7:40 AM, Joe Touch <touch@strayalpha.com> wrote:
>
>
>> On Aug 16, 2018, at 3:57 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>>
>> On Thu, Aug 16, 2018 at 03:52:54PM -0700, Joe Touch wrote
>
>>>
>>> On Aug 16, 2018, at 3:10 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>>>
>>>>> Keepalives at a layer SHOULD NOT be interpreted as implying state at
>>>>> any other layer.
>>>>
>>>> What's going on here in the last sentence is probably a bit subtle -- a
>>>> keeaplive both does not indicate "real" protocol activity but also can
>>>> serve to exercise the lower protocol layers (and, even, per the previous
>>>> sentence, suppresses their keepalives).
>>>
>>> That may be intended but is never actually known. Lower layers can compress, cache, merge, and otherwise change the effect a transmission st one layer has on any other.
>>
>> Right, that's why it's subtle :)
>
> It’s not subtle. There’s no way to know whether keepalives at a higher level have any desired affect at the lower level at all - except using Wireshark to trace the packets sent.
>
I don't think that's necessarily true. RFC1122 states:

"Keep-alive packets MUST only be sent when no data or acknowledgement
packets have been received for the connection within an interval."

So if an application is performing keepalives by sending and receiving
keepalive messages over the connection then that is enough to supress
TCP keepalives. For instance, if the period of application sending
keepalives on a connection is less then the one for TCP keepalives,
then there should be no TCP keepalives ever sent on the connection (if
Wireshark is showing otherwise then that might be a bug in the
implementation).

Tom

> That’s why users SHOULD NOT try to affect lower level keepalives using higher level ones.  (it’s not MUST NOT because there’s no strict harm, except that it simply can’t be known whether it achieved its desired effect).
>
> Joe