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

[Jeffrey Haas <[e-mail]>]

Mikael,


> On Mar 7, 2023, at 6:52 AM, Mikael Abrahamsson <swmike=[e-mail]> wrote:
> On Tue, 7 Mar 2023, Robert Raszuk wrote:
> 
>> Specifies the amount of time that transmitted data may remain unacknowledged before the TCP connection is forcibly closed.
>> 
>> So local socket buffer get's full because we are not receiving TCP level
>> ack from the peer.
> 
> The window is 0 because the receiver didn't get the data from the socket. There's no data to send, so no ACKs to get lost.
> 
> This isn't a connectivity problem. It's an application problem.

Most typically it will be an application issue.  In some cases, it may be a TCP issue or other issue that results in dropped TCP ack packets.  

The sender can't know.  It just knows that it can no longer send.


> 
>> /* Besides we are all talking about broken BGP peer which does not receive new info from us yet keeps the connection up. */
> 
> Correct. Because the receiver stopped getting data from its socket.

In the case of the tcp user timeout, all that is required is that data is unacknowledged for long enough.  This may occur in situations where the tcp window isn't filled.  Thus, from the sender's perspective, the socket may not even block.

To use a previously supplied example, if the BGP session is stable and is only sending 19 byte keepalives every N seconds with a 32k window that started out empty, and the window isn't moving due to acks not being received, it will take a VERY long time before the sender blocks.

However, if the ack is sent out in a tcp packet, but isn't acknowledged within the desired window, the session can be bounced without waiting on the block.


-- Jeff