Re: statement regarding keepalives
Tom Herbert <tom@herbertland.com> Fri, 17 August 2018 21:13 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 832B3130E1F for <tsv-area@ietfa.amsl.com>; Fri, 17 Aug 2018 14:13:16 -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=unavailable 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 WGuEDIXkDsx9 for <tsv-area@ietfa.amsl.com>; Fri, 17 Aug 2018 14:13:15 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 054A5130DE3 for <tsv-area@ietf.org>; Fri, 17 Aug 2018 14:13:13 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id e19-v6so10268213qtp.8 for <tsv-area@ietf.org>; Fri, 17 Aug 2018 14:13:12 -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; bh=X9DIRab9UbecU6STg0xAiOQLOoDdjUTHlpoPbqA/Vyc=; b=n8RdcVywuvaB+YpKsI2wydZTFmB2bfuqHU/Y22DRQsoYFo+ZVyTSl/fN8cRpkXVIqh pcACQWRtR0FK5HT/OdIRum/GF5W8oHaHwscFoeUoxWoapYX+8tQbEO2pKtgyn2fFaUS0 BjLSjeFP+Lg8c56uge5QqTy8FoIJYmMhZZv81GnUp13Y9ZqsmjTCWSSMzZRftFWbTp/J JTmaFJgMcZ0YSa6nylcnjWZmsuZBJPPeEJ3TnZTU6CeGIykn9VKFkGCgoqQ6/mcKcP52 yCtKO0Y6nrVVFfOzm0SWULx+v6iSQYrSmEY0dpCvB3/qPa3hHurW6OIZRwRUMEJwlRL8 9avw==
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; bh=X9DIRab9UbecU6STg0xAiOQLOoDdjUTHlpoPbqA/Vyc=; b=NXDvklbw8mqE0B+a2On2Fs/1uViW18133RTyZH/FCX5qzCoz9kxqCh+R0KRTsc9Jtw FgguynI0Zj+2X9e1KolCiatyOIWGjWNWx2LOAQkzwfIrur3tqM/mBruQoHR/knCCypwT dG6tDXRVOM5ehGkGwJrmDZ1XLhMG0APYl6RUwl6gZRq+8PzbejZfzLtpfQ00f0A4GI+z yQ8nCs7XLow0AwTR3hxeOHQQwWViM7SbTj9K7S1IzEOuythe+R7wNtpgJKAtGs2r1kfN 9pad6X4OYJejn7oBoSWCgq0ZGrL+o7zVwZ68FvlrTmIPqXrp0KTdvTZ+0nqL4WY5nboI PV+g==
X-Gm-Message-State: AOUpUlFClfw1ddLGNDST10nBid2Xmfe9YkD34RiCnvbQZXMU15MdjTBD DIPbKX82wJAvzEQGYSzUVSMbNBWU2w1+4emkYiUB/v8JPYI=
X-Google-Smtp-Source: AA+uWPx8ClCjBzf9UgS/9qNq0TRBZDnLndtMFYSf5pJyhiaz/D7DNjzpGfiNlWHxIQDMJeRqpusVmAGbamWr8eN3tKk=
X-Received: by 2002:ac8:530d:: with SMTP id t13-v6mr34246409qtn.396.1534540392008; Fri, 17 Aug 2018 14:13:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Fri, 17 Aug 2018 14:13:11 -0700 (PDT)
In-Reply-To: <af592212b44a55e83749d0701ba60fa4@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> <CALx6S34o1DJ6Nmin23GSNF_o-ddVEHX0_5qMohnxJxmh-BqH9w@mail.gmail.com> <c9c28764899d10647b7d79e5ab1361fb@strayalpha.com> <CALx6S355YtSkquMmtQ-su=mBqPYdH=17XsChUJLXEURxeY-jEA@mail.gmail.com> <af592212b44a55e83749d0701ba60fa4@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 17 Aug 2018 14:13:11 -0700
Message-ID: <CALx6S360cygpqZchTDT3jwCN09AwF-NvEDOMmaD-tJB7diV==w@mail.gmail.com>
Subject: Re: statement regarding keepalives
To: Joe Touch <touch@strayalpha.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, netconf-chairs@ietf.org, tls-ads@ietf.org, "tsv-area@ietf.org >> tsv-area@ietf.org" <tsv-area@ietf.org>, tsvwg-ads@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/vPLIY_cJcloPonNuW-kTaWMb7yI>
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 21:13:16 -0000
On Fri, Aug 17, 2018 at 1:31 PM, Joe Touch <touch@strayalpha.com> wrote: > > > > > On 2018-08-17 11:43, Tom Herbert wrote:The purpose of an application keep > alive is not to do favors for TCP, > > it's to verify the end to end liveness between application end points. > This is at a much higher layer, verifying liveness of the TCP > connection is a side effect. > > > Sure - that's fine and not what I'm concerned about. > > I don't want the text to say that higher level protocols or apps should try > to do favors to keepalive lower level protocols - because it doesn't > necessarily work. > > > > > However, if that 1GB goes out in 10 seconds, then TCP would have sent its > own keepalives just fine. It didn't need the app's help. > > So the app didn't help at all; at best, it does nothing and at worst it > hurts. > > > Consider that someone sets an application keepalive to 35 second > interval and the TCP keepalive timer is 30 seconds. When the > connection goes idle TCP keepalive will fire at thirty seconds, and > five seconds later the application keepalive fires. So every > thirty-five seconds two keepalives are done at two layers. This is not > good as it wastes network resources and power. > > > Agreed. > > > In this case, the > application keepalive is sufficient > > > In this *implementation* it *might* be sufficient, in others, it might not. > There's simply no way for the layers to know. > > > and the TCP keepalive shouldn't be > used. > > > If you KNOW that the app keepalive will cause the TCP transmission, sure - > but how do you KNOW that? You don't and can't. Even if you write to the TCP > socket, all you know when the socket returns is that the data was copied to > the kernel. You don't know for sure that you've triggered a TCP packet. > Actually, you do know that information. Application keepalives are request/response messages sent in TCP data. When a response is received to keepalive request over the TCP connection that is proof that the keepalive was sent. If the application keepalive was sent on the socket, and no response is received before the application timer expires, then the application declares the the connection dead and most likely will just close the socket and try to reconnect. The fact that an application keepalive request, or its response, might be stuck in a TCP send buffer (e.g. peer rcv window is zero) versus the peer host completely disappeared is irrelevant. To the application it's all the same, a connection to a peer application has failed and action needs to be taken. Tom > Besides, your "keepalives" might end up causing TCP to send packets it never > needed to send in the first place - even IF you think you're doing it a > favor. > > > > This is an example of the problems in running two control loops > at different layers with overlapping functionality, > > > > The problem is trying to infer overlap in functionality. If you realize that > these are independent control loops *and leave them alone* you're fine. > Independence of control loops does not mean they can't conflict. Mulitple layers performing keepalives is just one example, and probably one with lesser insidious behavoir. Look at http://qurinet.ucdavis.edu/pubs/conf/wicon2008.pdf for good example how link layer retransmissions can conflict with TCP algorithms to produce really bad results. Tom > It's only in trying to optimize them as overlapping that a problem is > created. > > > > > if the > ramifications of doing aren't understood it can lead to undesirable > interactions and behavior. > > > Agreed - so don't. Admit that there are inefficiencies *regardless of how > hard you try to do otherwise* and leave them alone, IMO. > > > If the app needs an app-level keepalive, do it. > > If the app wants TCP to be kept alive, let IT do it and leave it alone. > > Don't try to couple the two because you can't, and whatever you think you > might gain you could easily lose. Leaving the two alone and separate is > sufficient and robust. > > Joe
- statement regarding keepalives Kent Watsen
- Re: statement regarding keepalives Wesley Eddy
- RE: statement regarding keepalives Black, David
- Re: statement regarding keepalives Spencer Dawkins at IETF
- Re: statement regarding keepalives Mikael Abrahamsson
- Re: statement regarding keepalives Spencer Dawkins at IETF
- Re: statement regarding keepalives Tom Herbert
- Re: statement regarding keepalives Joe Touch
- Re: statement regarding keepalives Kent Watsen
- Re: statement regarding keepalives Joe Touch
- Re: statement regarding keepalives Kent Watsen
- Re: statement regarding keepalives Tom Herbert
- Re: statement regarding keepalives Kent Watsen
- Re: statement regarding keepalives Tom Herbert
- Re: statement regarding keepalives Kent Watsen
- Re: statement regarding keepalives Tom Herbert
- Re: statement regarding keepalives Eggert, Lars
- Re: statement regarding keepalives Eggert, Lars
- Re: statement regarding keepalives Mikael Abrahamsson
- Re: statement regarding keepalives Olle E. Johansson
- Re: statement regarding keepalives Gorry Fairhurst
- Re: statement regarding keepalives Joe Touch
- Re: statement regarding keepalives Tom Herbert
- Re: statement regarding keepalives Joe Touch
- Re: statement regarding keepalives Mikael Abrahamsson
- Re: statement regarding keepalives Tom Herbert
- Re: statement regarding keepalives Benjamin Kaduk
- Re: statement regarding keepalives Joe Touch
- Re: statement regarding keepalives Benjamin Kaduk
- Re: statement regarding keepalives Joe Touch
- Re: statement regarding keepalives Tom Herbert
- Re: statement regarding keepalives Joe Touch
- Re: statement regarding keepalives Tom Herbert
- Re: statement regarding keepalives Joe Touch
- Re: statement regarding keepalives Tom Herbert
- Re: statement regarding keepalives Joe Touch
- Re: statement regarding keepalives Tom Herbert
- Re: statement regarding keepalives Joe Touch