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
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
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
> 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
> ...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
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