> On Aug 17, 2018, at 4:53 PM, Tom Herbert wrote:
> ...
> Joe,
>
> I agree to the extent that keepalives are run only at one layer with
> one keepalive control loop. If they are simultaneously done at
> multiple layers without consideration that can be problematic.
They are equally problemati
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 w
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 retu
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 liveness
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 a
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 im
> 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 goi
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 Wat
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 co
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."
Which
> 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 ye
Hi, Kent,
I think the recommendations miss a few aspects of my suggestions:
- there is NEVER a good reason to assume that keepalives should happen at the
“highest level” of anything;
keepalives are needed *at EVERY level* where endpoint state needs to be
actively (rather than passively) maintai
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 d
> 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.
>
> I
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
whe
On 2018-8-16, at 9:22, Eggert, Lars wrote:
> you might want to also look at Section 3,5 of RFC8086, which specifies the
> current BCPs for keepalives for UDP.
Make that Section 3.5 of RFC8085:
https://tools.ietf.org/html/rfc8085#section-3.5
Lars
signature.asc
Description: Message signed with
Hi,
you might want to also look at Section 3,5 of RFC8086, which specifies the
current BCPs for keepalives for UDP.
Lars
> On 2018-8-15, at 20:35, Kent Watsen wrote:
>
>
> Below is an updated version of some text that we might roll into
> a statement or an I-D of some sort. Kindly review an
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 t
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 it
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 menti
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 th
On Wed, Aug 15, 2018 at 10:35 AM, Kent Watsen wrote:
>
> Below is an updated version of some text that we might roll into
> a statement or an I-D of some sort. Kindly review and provide
> suggestions for improvement, or support for the text as is, if
> that is the case. ;)
>
> This update accomm
Below is an updated version of some text that we might roll into
a statement or an I-D of some sort. Kindly review and provide
suggestions for improvement, or support for the text as is, if
that is the case. ;)
This update accommodates comments from:
- Wesley Eddy & David Black
- remove
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 la
> ...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 ke
> 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 all
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 programm
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 th
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 immediatel
> -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
PM
> To: tsv-area@ietf.org
> Subject: Re: statement regarding keepalives
>
> 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 lay
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 conne
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 st
38 matches
Mail list logo
