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

[Robert Raszuk <[e-mail]>]

Mikael,

> If application2 stops reading from its socket,

Realistically  - how often will any application continue to write to a
socket and at the same time stop reading from it ?

The more I think about your assumptions the more it seems like soft crafted
to do exactly that for a test.

Best,
Robert


On Wed, Mar 8, 2023 at 11: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.
>
> > 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.
>
> > 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, filling up tcpstack1 buffer
> until it finallly decides to not accept any more data via socket1. What
> we're after is application1 deciding that since it can't send data to
> socket1 for a prolonged amount of time, it should decide session is wedged
> and close it.
>
> My understanding is that tcpstack1<->tcpstack2 will gladly acknowledge
> packets/tcp-keepalives forever in this wedged state, so how does
> user-timeout help? 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?
>
> --
> Mikael Abrahamsson    email: [e-mail]
>