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

[John Scudder <[e-mail]>]

Agreed.

—John

On Dec 15, 2020, at 4:08 PM, Jakob Heitz (jheitz) <jheitz=[e-mail]<mailto:jheitz=[e-mail]>> wrote:

[External Email. Be cautious of content]


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]<mailto:[e-mail]>>
Sent: Tuesday, December 15, 2020 12:58 PM
To: John Scudder <[e-mail]<mailto:[e-mail]>>
Cc: Jakob Heitz (jheitz) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Robert Raszuk <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | https://urldefense.com/v3/__http://www.nextlayer.at__;!!NEt6yMaO-gk!Qm49_lCxrC4mUilTalG2MTz0dehIKXi0GAQ2hUdoNkILySKQdek0AWSPrbUfyQ$




_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!Qm49_lCxrC4mUilTalG2MTz0dehIKXi0GAQ2hUdoNkILySKQdek0AWQy5xj9EA$