Re: [Idr] WG LC for draft-ietf-idr-bgp-sendholdtimer-03 (3/23 to 4/12/2024) - Extended to 4/19/2024

[Robert Raszuk <[e-mail]>]

Hi Jeff,

> My suggestion to you is to rethink whether your objection is "this doesn't
> work" or "this is an incomplete solution".

I thought I already expressed myself that I think the latter.

> Support for tcp user timeout is nowhere near pervasive enough to try to
> force this as the only option to address the issue.

If I would go for  "TCP User Timeout" as the only option I would not
suggest including in the current subject draft a paragraph or a section
simply listing the alternative. It does not even need to be a formal merge
.. the current author list of draft-ietf-idr-bgp-sendholdtimer could stay
intact.

Or if you think this could be dangerous when "excessively short timer
values can lead to unstable BGP when there's CPU congestion that delays
timely acks" then subject draft should say perhaps even as normative MUST
to either keep it to 0 for BGP connections or set it to safe value ("safe"
being perhaps reasonably long).

Best,
Robert



On Mon, Apr 15, 2024 at 7:53 PM Jeffrey Haas <[e-mail]> wrote:

> Robert,
>
> On Mon, Apr 15, 2024 at 10:31:59AM +0200, Robert Raszuk wrote:
> > Just for the record I do not support this WG LC.
> >
> > The proposed solution is not granular enough. While it is better
> > than nothing, why to concentrate energy on a solution which may only
> react
> > to stuck peer for hours (send buffer fill time when only keepalives are
> > sent) and only cover subset of cases ?
> >
> > We have proposed a TCP extension (which is already in the main kernel
> > distro for a long time) which addresses the problem in a much more
> > universal way.
> >
> > https://www.ietf.org/archive/id/draft-chen-idr-tcp-user-timeout-01.txt
>
> As a reminder to the list, each of the proposals has corner cases that
> don't
> fully alleviate the problem individually.
>
> https://mailarchive.ietf.org/arch/msg/idr/Rai4amR5Q0ZuZ60HaLWFGKhKuBA/
>
> As a reminder from the above, in the case of tcp user timeout, excessively
> short timer values can lead to unstable BGP when there's CPU congestion
> that
> delays timely acks.  Or, when  there's sufficient packet loss to degrade
> TCP
> throughput, it may now contribute to sessions dropping rather than staying
> congested until repair of the loss.
>
> But as you point out, a large TCP window plus minimal BGP traffic has
> problems in the sendholdtimer behavior.
>
> Support for tcp user timeout is nowhere near pervasive enough to try to
> force this as the only option to address the issue.  Everyone using POSIX
> sockets can benefit from the subsets of the problem addressed by
> sendholdtimer.
>
> My suggestion to you is to rethink whether your objection is "this doesn't
> work" or "this is an incomplete solution".  If it's an incomplete solution,
> instead focus on moving the tcp user timeout document forward separately
> rather than trying to quash other work addressing at least a portion of the
> problem that every BGP implementation can do today.
>
> With regards to this last second appeal to force a merge of the proposals,
> support for tcp user timeout was light during the poll.  I suggest spending
> the effort to build support for a next round of adoption call.
>
> https://mailarchive.ietf.org/arch/msg/idr/sXpqVZMJCgkRcQ6OHKws_HMdcg0/
>
> -- Jeff
>