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

Hey Enke,

> for the session to be terminated deterministically at the transport
layer.

Yes and I would 100% agree with that.

However the discussion seems to be around terminating it at/by the
application layer just from not being able to write to transport socket any
more for N seconds. This mismatch is something IMHO is a bit ugly.

Your suggestion to solve it at transport itself is sound !

Otherwise with each failed write we start a counter. How often do we retry
to write the same msg ? Then after many failed attempts to queue a BGP
message the time is exceeded and we RST.  That triggering logic seems quite
dirty at best .. just imagine dealing with 1000s of peers.

Cheers,
R.

On Thu, Dec 17, 2020 at 8:48 PM Enke Chen <enchen@paloaltonetworks.com>
wrote:

> Hi, Robert:
>
> The receiver is broken for not closing the session after the holdtime
> expires, and that certainly needs attention.
>
> However, the rational for trying to do something on the sender seems to be
> the following: as the session is broken and should have been terminated by
> the other side, but it's not, the sender would like to have a way that
> provides an "upper bound" for the session to be terminated
> deterministically at the transport layer.
>
> The TCP_USER_TIMEOUT option seems to be a good fit in this case.
>
> Thanks.   -- Enke
>
> On Thu, Dec 17, 2020 at 2:21 AM Robert Raszuk <robert@raszuk.net> wrote:
>
>> Good catch Enke !
>>
>> Also what if TCP rcv takes the BGP messages and passes it to BGP I/O InQ
>> which drops it for some reason right there ? Looks to me like we are not
>> going to detect any event like this here. But the problem we are trying to
>> address will persist. I think in this thread we are focusing too much on
>> transport vs application level detection.
>>
>> And I will repeat the question already stated ... Why rcv would not close
>> the session in spite of missing KEEPALIVES or UPDATES ?
>>
>> Tx,
>> R.
>>
>> PS. Side note: BGP Operational Message addresses this type of
>> inconsistencies by periodically comparing BGP Adj_RIB_In and _Out counters.
>>
>>
>> On Thu, Dec 17, 2020 at 3:41 AM Enke Chen <enchen@paloaltonetworks.com>
>> wrote:
>>
>>> Hi, Folks:
>>>
>>> Regarding the patch for openBGPD pointed out by Job, I do not think it
>>> would work. When the TCP rcv window from the remote is 0, the BGP keepalive
>>> can still be queued to the socket buffer. It can take a long time for the
>>> socket buffer to be filled up by BGP keepalives.
>>>
>>> It seems that the TCP_USER_TIMEOUT option can be used for the persistent
>>> zero-size window issue.  The timeout value could be multiples of the
>>> holdtimer (with min and max adjustments), perhaps somewhere around 5 or 6
>>> minutes.
>>>
>>> Thanks.   -- Enke
>>>
>>> ----------
>>>
>>> Job Snijders <job@sobornost.net> Tue, 15 December 2020 21:54 UTC
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_idr_-23&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=FlndUknstuJ9j_Pf40oKOLGgDCHrXNgX1l6gQZsjVxE&s=Gy3ZgD4mwrmy1k7kEyDCeqqUBxyXkv33m4XaHfegXGA&e=>
>>>
>>> [snip]
>>> How to solve this? Claudio Jeker took a look at what it would take in
>>> OpenBGPD and came up with the (tiny!) following patch, should be
>>> readable to most: https://marc.info/?l=openbsd-tech&m=160796802508185&w=2 <https://urldefense.proofpoint.com/v2/url?u=https-3A__marc.info_-3Fl-3Dopenbsd-2Dtech-26m-3D160796802508185-26w-3D2&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=FlndUknstuJ9j_Pf40oKOLGgDCHrXNgX1l6gQZsjVxE&s=4Ip2QeM5GZ1ohdD4z1RB3-XR1zvrkGa-gnnnxVzd3Gs&e=>
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> Idr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/idr
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=FlndUknstuJ9j_Pf40oKOLGgDCHrXNgX1l6gQZsjVxE&s=hBMaxmukXgY-6uXgnTCoi6Zoz2jI0izuMOA06uP1Seg&e=>
>>>
>>