Re: [Idr] WG Adoption call for draft-spaghetti-idr-bgp-sendholdtimer-09 (2/28/2023 to 3/14/2023)

[Claudio Jeker <[e-mail]>]

On Tue, Mar 07, 2023 at 09:11:32AM +0100, Robert Raszuk wrote:
> Martin & Mikael,
> 
> 
> > > My main issue with what is proposed here is that it completely ignores
> > TCP
> > > keepalives.
> >
> > What would the draft do to TCP keepalives? If the receiving application
> > has stopped reading from the socket then TCP keepalives will still run as
> > normal.
> >
> 
> I am not sure I follow ... Isn't the objective here to detect when sender
> (your bgp peer) is not sending ? Or you want to also detect local "reading
> from socket" issues and RST BGP session ? Really ?
> 
> > Of course one may say ... Oh if I configure long enough timers we will be
> > > fine - and that is maybe true - maybe SendHoldTimer will be just an extra
> > > fuse.
> >
> > That seems to be what is proposed, yes.
> >
> 
> Indeed.
> 
> But I am mainly worried that what is proposed here is to smash the session
> because applications have problems on possibly healthy TCP connection.
> 
> See use of zero window is a very valid case in TCP.
> 
> Of course everything depends on the duration hence concern about timers.
> 
> But what was not answered was why to invent new "overlay" timer if TCP USER
> TIMEOUT does exactly and much better what is being required here.

The publication of RFC793 was 40 years ago and most systems did not
implement this or not correctly in 40 years.  I think that is a pretty
strong reason to not use it.
 
> Sure there were bugs in the past, but should we get blocked by history of
> TCP implementations in linux kernel ?

Since Linux is the only open-source TCP implementation with this feature I
think it is a strong indication that this should be blocked exactly
because of this.

Adding the SendHoldTimer has a benefit to be part of the BGP process and
so no matter what causes a stall it will be noticed at some point.
It is a proper end to end detection while TCP USER TIMEOUT only notices a
specific case of TCP stall.

The simplicity of implementing SendHoldTimer, the fact that TCP USER
TIMEOUT is not widely available and that TCP USER TIMEOUT on the only
open-source stack implementing it was broken for a long time all speak
against draft-chen-idr-tcp-user-timeout.

-- 
:wq Claudio