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

[Enke Chen <[e-mail]>]

On Thu, Aug 4, 2022 at 7:07 AM Ben Cox <[e-mail]> wrote:
>
> 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?

As documented in the man page, the kernel would return the error code
ETIMEDOUT to the application.

To retrieve an error on the socket (associated with the BGP session),
just follow the standard procedures for socket APIs, such as read(),
write(), select(), poll(), epoll().

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

Yes, there have been several fixes for TCP_USER_TIMEOUT in Linux in
the last several years. To get these fixes, either upgrade or back
port.
Otherwise the condition may not be detected in all the cases.

I don't think the existence of bug fixes should diminish the
TCP_USER_TIMEOUT as a simple and effective solution to the issue of
"stuck" sessions.

Thanks. -- Enke

>
> On Wed, Aug 3, 2022 at 8:29 PM Enke Chen <[e-mail]> 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://urldefense.com/v3/__https://man7.org/linux/man-pages/man7/tcp.7.html__;!!Mt_FR42WkD9csi9Y!byAyMMhah5M_HgRLuo7UbEgzIJ_j6QJDTgWHtcYI_Stvh2ai8GLl8eNO-Hoi9hvi-ZDtZqD84yeDNCzxHdAu$
> >
> > 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 <[e-mail]> 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
> > > [e-mail]
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!Mt_FR42WkD9csi9Y!a0z_mWIoJi3AkiI16RqyCvoRCWwEOL3bWCHM4NpDMSNuDupNtnpKp-7CS11XhqcJqXRdfdf7CvdIHDMJt49KTA$
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!Mt_FR42WkD9csi9Y!byAyMMhah5M_HgRLuo7UbEgzIJ_j6QJDTgWHtcYI_Stvh2ai8GLl8eNO-Hoi9hvi-ZDtZqD84yeDNCNwiZjB$