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

[Robert Raszuk <[e-mail]>]

>
> > 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.
>

Ok I was talking about time even before we get to zero window phase.


> This isn't a connectivity problem. It's an application problem.
>

But this is exactly why we have BGP Keepalives in the first place.
We trust that BGP implementation can act on it.






>
> > /* 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.
>
> This isn't a TCP problem, that can be solved by keepalives etc, because
> the problem isn't at the TCP level. It's at the remote application end and
> it's being pushed back to us all the way through their TCP stack, through
> the 0 window size, and through our TCP stack, which now won't let us put
> more data into the socket because our sending buffer is full.
>
> >> What is it that will not clear in 8 minutes but that will clear in 60
> >> minutes, that you're concerned about?
> >
> > 8 min is not the normative MUST minimum. It is only "recommended". And
> not
> > even written in a normative language.
>
> You didn't answer the question.
>

Well I am pointing out that IMO we need a normative MUST and to declare
some safe and sane minimum value.

I am much less concerned about the absolute value of it irrespective of 8
or 60 min. (60 was
just taken as an example from Nick's use case).

Thx,
R.









>
> --
> Mikael Abrahamsson    email: [e-mail]
>