On Fri, Aug 17, 2018 at 4:06 PM, Joe Touch wrote:
>
>
>
> On 2018-08-17 14:13, Tom Herbert wrote:
>
> On Fri, Aug 17, 2018 at 1:31 PM, Joe Touch wrote:
>
>
>
> 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
On 2018-08-17 14:13, Tom Herbert wrote:
> On Fri, Aug 17, 2018 at 1:31 PM, Joe Touch wrote:
>
>> 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
On Fri, Aug 17, 2018 at 1:31 PM, Joe Touch 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
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
On Fri, Aug 17, 2018 at 10:27 AM, Joe Touch wrote:
>
>
>
>
> On 2018-08-17 09:05, Tom Herbert wrote:
>
> On Fri, Aug 17, 2018 at 7:40 AM, Joe Touch wrote:
>
>
> ...
> 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
On 2018-08-17 09:05, Tom Herbert wrote:
> On Fri, Aug 17, 2018 at 7:40 AM, Joe Touch wrote:
>
>> ...
>> 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
On Fri, Aug 17, 2018 at 7:40 AM, Joe Touch wrote:
>
>
>> On Aug 16, 2018, at 3:57 PM, Benjamin Kaduk wrote:
>>
>> On Thu, Aug 16, 2018 at 03:52:54PM -0700, Joe Touch wrote
>
>>>
>>> On Aug 16, 2018, at 3:10 PM, Benjamin Kaduk wrote:
>>>
> Keepalives at a layer SHOULD NOT be interpreted as
> On Aug 16, 2018, at 3:57 PM, Benjamin Kaduk wrote:
>
> On Thu, Aug 16, 2018 at 03:52:54PM -0700, Joe Touch wrote
>>
>> On Aug 16, 2018, at 3:10 PM, Benjamin Kaduk wrote:
>>
Keepalives at a layer SHOULD NOT be interpreted as implying state at
any other layer.
>>>
>>> What's
On Thu, Aug 16, 2018 at 03:52:54PM -0700, Joe Touch wrote:
>
>
> On Aug 16, 2018, at 3:10 PM, Benjamin Kaduk 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
On Aug 16, 2018, at 3:10 PM, Benjamin Kaduk 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
It's great to see the good discussion happening here. I'll note a couple
things online, and also that given the discussion of the tradeoffs that go
into making these decisions, Tom is probably right that shoving this into
an I-D would be helpful.
On Wed, Aug 15, 2018 at 05:35:28PM +, Kent
On Thu, Aug 16, 2018 at 8:01 AM, Mikael Abrahamsson wrote:
> On Thu, 16 Aug 2018, Tom Herbert wrote:
>
>> They are already on, TCP has a default keepalive for 2 hrs. The issue
>
>
> http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html says:
>
> "Remember that keepalive support, even if
On Thu, 16 Aug 2018, Tom Herbert wrote:
They are already on, TCP has a default keepalive for 2 hrs. The issue
http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html says:
"Remember that keepalive support, even if configured in the kernel, is not
the default behavior in Linux."
> On Aug 16, 2018, at 7:38 AM, Tom Herbert wrote:
>
> They are already on, TCP has a default keepalive for 2 hrs.
RFC1122 says that keepalives are optional and MUST default to off.
This has already been included in RFC793bis.
Joe
On Thu, Aug 16, 2018 at 12:44 AM, Olle E. Johansson wrote:
>
>
> On 16 Aug 2018, at 09:28, Mikael Abrahamsson wrote:
>
> On Wed, 15 Aug 2018, Kent Watsen wrote:
>
> You bring up an interesting point, it goes to the motivation for wanting to
> do keepalives in the first place. The text doesn't
Adding some comments here. I'm playinh catch-up, so I may have comments
on some things that have been fixed, and missed others.
On 16/08/2018, 08:28, Mikael Abrahamsson wrote:
On Wed, 15 Aug 2018, Kent Watsen wrote:
You bring up an interesting point, it goes to the motivation for
wanting to
> On 16 Aug 2018, at 09:28, Mikael Abrahamsson wrote:
>
> On Wed, 15 Aug 2018, Kent Watsen wrote:
>
>> You bring up an interesting point, it goes to the motivation for wanting to
>> do keepalives in the first place. The text doesn't yet mention maintain
>> flow state as a motivation.
>
>
On Wed, 15 Aug 2018, Kent Watsen wrote:
You bring up an interesting point, it goes to the motivation for wanting
to do keepalives in the first place. The text doesn't yet mention
maintain flow state as a motivation.
It's not only to maintain flow state, it's also to close the connection
On Wed, Aug 15, 2018 at 2:24 PM, Kent Watsen wrote:
> Hi Tom,
>
>
>
>> Kent, I'm not sure what the context of formal text is. Is this write up
>> going
>
>> to be in an I-D, or is it intended to be published by some other
>> mechanism?
>
>
>
> That is a good question. At first, we were thinking
Hi Tom,
> Kent, I'm not sure what the context of formal text is. Is this write up going
> to be in an I-D, or is it intended to be published by some other mechanism?
That is a good question. At first, we were thinking that is might be an
AD-level
statement, but I think Spencer last suggested
On Wed, Aug 15, 2018, 1:56 PM Kent Watsen wrote:
>
> Hi Tom,
>
> I recall you're mentioning NAT before. It fell into a crack and I
> lost sight of it.
>
> You bring up an interesting point, it goes to the motivation for
> wanting to do keepalives in the first place. The text doesn't
> yet
Hi Tom,
I recall you're mentioning NAT before. It fell into a crack and I
lost sight of it.
You bring up an interesting point, it goes to the motivation for
wanting to do keepalives in the first place. The text doesn't
yet mention maintain flow state as a motivation.
The first paragraph of
> ...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
> On Jul 20, 2018, at 4:47 AM, Mikael Abrahamsson wrote:
>
> So I'd like to see in the text that we recommend to do it as "high up" in the
> stack as possible, but still don't put off people turning on TCP keepalives
> "because the IETF doesn't recommend that", and thus they do nothing at
On Fri, Jul 20, 2018, 7:40 AM Spencer Dawkins at IETF <
spencerdawkins.i...@gmail.com> wrote:
> Hi, Mikael,
>
> On Fri, Jul 20, 2018 at 6:48 AM Mikael Abrahamsson
> wrote:
>
>>
>> Hi,
>>
>> While I agree with the sentiment here, I have personally been in
>> positions
>> where application
Hi, Mikael,
On Fri, Jul 20, 2018 at 6:48 AM Mikael Abrahamsson wrote:
>
> Hi,
>
> While I agree with the sentiment here, I have personally been in positions
> where application programmers were unable to (in a timely manner) modify
> whatever was running, to implement a keepalive protocol. In
Hi,
While I agree with the sentiment here, I have personally been in positions
where application programmers were unable to (in a timely manner) modify
whatever was running, to implement a keepalive protocol. In that case,
turning on TCP keepalives was a very easy thing to do that
-Original Message-
> > From: tsv-area [mailto:tsv-area-boun...@ietf.org] On Behalf Of Wesley
> > Eddy
> > Sent: Thursday, July 12, 2018 9:06 PM
> > To: tsv-area@ietf.org
> > Subject: Re: statement regarding keepalives
> >
> > Hi Kent, I agree with the s
Hi Kent, I agree with the spirit of the statement / guidance you've drafted.
You might want to tweak some of the wording, e.g. "test more aliveness"
could be "test more layers of functionality" or something like that, but
this is just a nit.
I think the footnote recommending short-lived
Dear TSVAREA,
The folks working with the BBF asked the NETMOD WG to consider modifying
draft-ietf-netconf-netconf-client-server to support TCP keepalives [1].
However, it is unclear what IETF's position is on the use of keepalives,
especially with regards to keepalives provided in protocol
30 matches
Mail list logo
