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

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

There is a queue from rtr-B BGP to rtr-A BGP. This queue stretches through the TCP implementations on both routers. That means it consists of the TCP send buffer in rtr-B and the TCP receive buffer in rtr-A, whatever might be in the forwarding buffers on both routers and maybe some IPC queues and whatever else. rtr-A BGP only knows what it is pulling from its receive socket. BGP does not know or care what wnd=0 means. As long as it can keep pulling from its receive socket, it cannot expire its hold timer. An important check that a BGP implementation must do before expiring its hold timer is: "is my TCP receive socket empty?".

Regards,
Jakob.

-----Original Message-----
From: Christoph Loibl <[e-mail]> 
Sent: Tuesday, December 15, 2020 12:58 PM
To: John Scudder <[e-mail]>
Cc: Jakob Heitz (jheitz) <[e-mail]>; [e-mail]; Robert Raszuk <[e-mail]>
Subject: Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

John,

Thanks for answering my question in more detail. Maybe I was unclear (but reading your email I think we are talking about the same).

> On 15.12.2020, at 21:00, John Scudder <[e-mail]> wrote:
> 
> I think you are talking about this scenario. I’ll copy the example from Rob’s message cited above:
> 
>   rtr-A                   rtr-B
>   (congested c-p)         (uncongested c-p)
>   send window: >0         send window: 0
>   recv window: 0          recv window: >0	
> 
> In this case we expect:
>  a) rtr-B does not send any BGP packet (KEEPALIVE/UPDATE/NOTIFICATION)
> to rtr-A in normal operating circumstances.
>  b) rtr-A does not expect any KEEPALIVE/UPDATE packets from rtr-B. The
> session remains established even if no packet is received in the
> holdtime.
>  c) rtr-A continues to send KEEPALIVE packets to rtr-B.
> 

The part I have a problem to understand is b). It is clear that rtr-A will not receive any packets from rtr-B because rtr-B cannot send them (send window: 0). But does "rtr-A does not expect any KEEPALIVE/UPDATE packets from rtr-B” mean that rtr-A has essentially suspended its hold-timer until it is ready to receive new messages and opens up its recv window? If yes, why? I would expect timers to run independently of the transport protocol.

Cheers Christoph

-- 
Christoph Loibl
[e-mail] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at