Re: [Idr] Fwd: New Version Notification for draft-spaghetti-idr-bgp-sendholdtimer-05.txt

One question with TCP_USER_TIMEOUT (I've yet to test it) but if we
want to emit syslog/SNMP messages when it triggers, is there a way to
get out of the kernel that the reason for a socket closing was
TCP_USER_TIMEOUT and not something else?

Someone also mentioned in passing that TCP_USER_TIMEOUT in Linux was
buggy/broken until relatively recently, assuming that is the case,
that might be a good argument alone against going that route since the
a number of vendors using older kernels could risk someone thinking they
have implemented the feature but instead their kernel has
silently/loudly broken it.

On Wed, Aug 3, 2022 at 8:29 PM Enke Chen <enchen@paloaltonetworks.com> wrote:
>
> > if this is just queued keepalives (no BGP churn) then depending on the buffer size it may take ages to fill ..
>
> Indeed, in that case the local BGP speaker may not know about the
> condition (mis-behaving remote speaker / 0-window) for a long time,
> and that's not covered by the current draft, nor the FRR BGP patch
> based on my reading.
>
> To make it complete, I believe that the detection and handling of a
> stuck peer (i.e., "data not being transmitted") should be at the
> transport layer.  The TCP_USER_TIMEOUT option is readily available for
> that purpose:
>
> https://man7.org/linux/man-pages/man7/tcp.7.html
>
> TCP_USER_TIMEOUT (since Linux 2.6.37)
>               This option takes an unsigned int as an argument.  When
>               the value is greater than 0, it specifies the maximum
>               amount of time in milliseconds that transmitted data may
>               remain unacknowledged, or bufferred data may remain
>               untransmitted (due to zero window size) before TCP will
>               forcibly close the corresponding connection and return
>               ETIMEDOUT to the application.  If the option value is
>               specified as 0, TCP will use the system default.
>
> Thanks.  -- Enke
>
> On Wed, Aug 3, 2022 at 2:43 AM Robert Raszuk <robert@raszuk.net> wrote:
> >>
> >> Even if the remote (stuck) peer does not process the FIN, the local
> >> end will close the session and stop forwarding traffic that direction.
> >> That is an improvement, from an operator's PoV, both for forwarding
> >> errors and local resources.
> >
> >
> > Would not the same happen when you will send keepalives *ONLY* upon receiving them from a peer.
> >
> > If both sides support it there should be no issue of stuck sessions. Also no new timer needed and could be knob to enable/disable it.
> >
> > This draft assumes that one peer is bad and the other should time out when it can not send. So I am asking what exactly is the trigger to fire that timer when BGP can not write to a TCP socket ? Is it Error 105: No buffer space available ? Something else ?
> >
> > If this is just queued keepalives (no BGP churn) then depending on the buffer size it may take ages to fill ...
> >
> > Best,
> > R.
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!Mt_FR42WkD9csi9Y!a0z_mWIoJi3AkiI16RqyCvoRCWwEOL3bWCHM4NpDMSNuDupNtnpKp-7CS11XhqcJqXRdfdf7CvdIHDMJt49KTA$
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr