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

[Jeffrey Haas <[e-mail]>]

> On Mar 8, 2023, at 5:14 AM, Mikael Abrahamsson <[e-mail]> wrote:
> 
> On Tue, 7 Mar 2023, Jeffrey Haas wrote:
> 
>> 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.
> 
> Sure. But if it's a connectivity problem and the session can't transmit keepalives and the receiving application is functioning normally then it'll notice the lack of bgp keepalives and drop the session because of that.

The issue may be unidirectional.  You may receive keepalives without being able to send anything.
(Indirectly an argument for BFD.)

> 
>> 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.
> 
> That's correct, but in that case we don't have much real data we wanted to send anyway, so it means the other side is still kind of "in sync" with us.

That's one way to picture the magnitude of the problem, if it makes you happy.

If a single withdraw is in that clogged pipe, and it's for a prefix that represents 20% of your traffic, how do you feel about it?


> 
>> 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.
> 
> I see the user-timeout being brought up again. Is my understanding of how RCP works, flawed?
> 
> application1->socket1->tcpstack1->network->tcpstack2->socket2->application2
> 
> If application2 stops reading from its socket, then tcpstack2 buffer will fill up, it'll then reduce the window to 0,

Let's stop here since we're at the differentiating point for the two parallel discussions.

In one case, it's not necessary for a sender to block due to lack of buffer.  TCP can provide the necessary information via user-timeout that the receiver is not consuming the things sent to it.  This is the user-timeout methodology.

In the other case, the sender pays attention to whether it's blocked or not.  This will inevitably require the receiver not draining its socket (or dropped acks) and eventually zero-windowing (or close enough depending on the implementation) and the sender can't push a new update onto the socket.  This is the sendholdtimer methodology.

Both approaches will eventually tell you that a receiver isn't draining.  However, the sensitivity to detecting when that happens varies quite a bit across the two proposals.  The sendholdtimer proposal also depends heavily on expected traffic patterns and has some less consistent behavior based on size of PDUs.  (If your window has 19 bytes available, pushing a keepalive in a sluggish connection will reset the timer, but you can't push a single update to similarly reset the timer.)


> My understanding is that tcpstack1<->tcpstack2 will gladly acknowledge packets/tcp-keepalives forever in this wedged state, so how does user-timeout help?

Acknowledgment generally moves the window.  Things like tcp keepalive will happily work without the window budging, but will help with the cases where the failure is half duplex.  Same for BFD.


> From my understanding tcpstack1 only knows the packet has been received by tcpstack2, it has no idea if it's reached application2 or not and user-timeout doesn't help that?

A fault with both methods is you get no hint about application consumption based on window availability.  You simply know that stuff is sent and received.  For all you know, the bgp update has been received from the socket, then buffered by sending using RFC 1149.  

Addressing "has the application consumed the data it was sent" is out of scope here.  If you want it in scope, you'll require an explicit BGP ACK message.

-- Jeff