Re: [Idr] WG Adoption call for draft-spaghetti-idr-bgp-sendholdtimer-09 (2/28/2023 to 3/14/2023)

[Mikael Abrahamsson <[e-mail]>]

On Tue, 7 Mar 2023, Robert Raszuk wrote:

> Martin & Mikael,
>
>
>>> My main issue with what is proposed here is that it completely ignores
>> TCP
>>> keepalives.
>>
>> What would the draft do to TCP keepalives? If the receiving application
>> has stopped reading from the socket then TCP keepalives will still run as
>> normal.
>>
>
> I am not sure I follow ... Isn't the objective here to detect when sender
> (your bgp peer) is not sending ? Or you want to also detect local "reading
> from socket" issues and RST BGP session ? Really ?

One reason the sending TCP socket stalls and is because the reader stopped 
reading from the socket. From the draft:

"Implementation of a SendHoldTimer should help overcome situations where 
BGP sessions are not terminated after it has become detectable for the 
local system that the remote system is not processing BGP messages."

So yes, that's really one of the issues trying to be addressed. It's 
trying to detect that the other end isn't receiving our messages, by means 
that it can't put in more messages into the output socket for a prolonged 
period of time.

> See use of zero window is a very valid case in TCP.

If the window is zero for 8 minutes then it's sane default to terminate 
the session. If someone has a use-case that involves having zero window 
for more than 8 minutes then they should turn this feature off.

> But what was not answered was why to invent new "overlay" timer if TCP 
> USER TIMEOUT does exactly and much better what is being required here.

That doesn't help, because the problem isn't at the TCP level, it's at the 
application level. TCP works as designed. If receiver doesn't read data 
from the socket, then TCP window goes to zero. Working as expected.

This draft is trying to detect that the receiver isn't reading from the 
socket but still sending valid BGP keepalives etc.

-- 
Mikael Abrahamsson    email: [e-mail]