Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

["Jakob Heitz (jheitz)" <[e-mail]>]

My point was a question.

Does TCP_USER_TIMEOUT work when TCP is in persist state?
It seems like it should work, but it helps to be sure.

Regards,
Jakob.

-----Original Message-----
From: Idr <[e-mail]> On Behalf Of Jeffrey Haas
Sent: Friday, December 18, 2020 11:20 AM
To: Brian Dickson <[e-mail]>
Cc: idr@ietf. org <[e-mail]>; Enke Chen <[e-mail]>
Subject: Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

On Fri, Dec 18, 2020 at 10:28:48AM -0800, Brian Dickson wrote:
> On Fri, Dec 18, 2020 at 10:09 AM Enke Chen <[e-mail]> wrote:
> > No, I am not assuming that packets are getting somewhere. The
> > TCP_USER_TIMEOUT would work as long as there is "pending data" (either
> > unacked, or locally queued). The data can be from the local BGP Keepalives
> > or the TCP_KEEPALIVE.
>
> Actually, my point was not only about packets getting somewhere, but also
> that the LOCAL implementation of the TCP stack should not be assumed to be
> bug-free (in relevant ways).
> 
> Your response is still assuming that those mechanisms actually work 100%
> reliably 100% of the time.
> 
> Yes, if the implementation works correctly, TCP_USER_TIMEOUT would work.
> However, I'm saying the BGP code should not assume that is the case, and
> put some guard-rails around the behavior.
> The overhead of some small amount of checking, regardless of how it is
> done, is likely quite low.

What's also important is that using this option removes the ability for the
BGP implementation to make its own decisions.

In the presence of some level of packet drop, the window may not be able to
advance because the ACK covering the head end isn't getting through.  So,
even if some data is getting through and helping open space in the buffer,
this feature may cause us to close the session.

Jakob also makes the point that zero window in the send direction isn't
really helped here.

> (If packets are flowing, as viewed by updates and/or keepalives being seen
> from the peer, for example, it might not be necessary to invoke those
> checks? Or the check might only need to be done every $INTERVAL, like every
> minute or two.)

My experience is that using the TCP information in an advisory fashion is
helpful, but hard to make work consistently or portably.  Features that tie
into the stack to try to assess liveness or close sluggish sessions are
helpful if you don't care about the impact.  BGP implementations tend to
care about being resilient, especially for ISP circumstances.

-- Jeff

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr