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

[Jared Mauch <[e-mail]>]

One of the issues I've seen here is the tcp stacks in routers be very ... unique. Much of this is because there is significant desire for state handling to be replicated between dual routing daemons and line cards. 

I spent many hours with cisco about the perils of non default settings for their stack for things like keepalives. These are all the choice of bad OS level defaults and the applications not having consistent socket behavior. This example with XR is mostly to air the details of their implementation and how it would impact the discussion. 

These implementation details matter as window 0 isn't clear and may not go up the stack or may not come down enough. 

There's a delicate balance here in consume the data as quickly as possible and run the rib and fib downloading in alternative threads and when it should cause a blocking event and when the back pressure should cause the notification or tcp tear down. 

The applications should be more aware of the transport state and I'm worried this runs into the "please don't write bugs" category. It's at least close to it. 

Sent from my iCar

> On Dec 12, 2020, at 9:07 AM, Jakob Heitz (jheitz) <jheitz=[e-mail]> wrote:
> 
>  No.
> 
> Regards,
> Jakob.
> 
> 
>>> On Dec 12, 2020, at 6:01 AM, Christoph Loibl <[e-mail]> wrote:
>>> 
>>  Hi,
>> 
>> Isn’t it save to assume that if a system cannot send any messages to its BGP-neighbor (for whatever reason) for HOLD TIME seconds, that the neighbor on the other side has by that time already declared the BGP session dead (is already “trying" to deliver a NOTIFICATION and has removed the routes from its RIB). If this is the case I see no point in trying to keep the session alive, because it will *always* sooner or later lead to a new session-setup + flapping routes. The BGP session (if the NOTIFICATION is queued) cannot recover from that state anymore (can it?) and is useless, even if there are chances that messages may get delivered later. 
>> 
>> Cheers Christoph
>> 
>> -- 
>> Christoph Loibl
>> [e-mail] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at
>> 
>> 
>> 
>>> On 12.12.2020, at 10:22, Robert Raszuk <[e-mail]> wrote:
>>> 
>>> 
>>> I went back and reread the thread: 
>>> 
>>>    https://mailarchive.ietf.org/arch/msg/idr/q0Sx5d3zZjfOmOQ4lO2OZAHh9Lc/ 
>>> 
>>> Shouldn't it be better if we first ask implementations to provide show command/api to list all peers and min-max durations of TCP Window being 0 without actually doing any automagic RST/NOTIFICATION/FIN ? 
>>> 
>>> This could allow to better understand which peers are getting behind in their control plane and perhaps also allow to set the RST timer under such conditions by operator? If he chooses this to be equal to HOLD TIME so be it but I am not sure this would be universally an optimal choice. 
>>> 
>>> Along the same lines we should perhaps also list per BGP peer number of DUPLICATE ACKS, RETRANSMISSIONS etc ... 
>>> 
>>> Are there implementations already deployed in DFZ allowing such data to be displayed per each BGP peer ?
>>> 
>>> Thx,
>>> Robert.
>>> 
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>> 
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr