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

[Jeffrey Haas <[e-mail]>]

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