Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

Jeffrey Haas <jhaas@pfrc.org> Fri, 18 December 2020 19:02 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A1B3A0ED2 for <idr@ietfa.amsl.com>; Fri, 18 Dec 2020 11:02:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xg4SpSCnWkNg for <idr@ietfa.amsl.com>; Fri, 18 Dec 2020 11:02:57 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 639423A0ED1 for <idr@ietf.org>; Fri, 18 Dec 2020 11:02:57 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 07FD21E355; Fri, 18 Dec 2020 14:20:24 -0500 (EST)
Date: Fri, 18 Dec 2020 14:20:23 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Enke Chen <enchen@paloaltonetworks.com>, "idr@ietf. org" <idr@ietf.org>
Message-ID: <20201218192023.GA23143@pfrc.org>
References: <CANJ8pZ-WMDotkQvhN-NuP7ivZkPRR-9S2KJSar=6463U0VKkow@mail.gmail.com> <EFC56A31-1276-4DAB-9526-9C2F24814D2C@pfrc.org> <CANJ8pZ_LnDna_jtipcLJq9rrS3MM32rLdxRW8ntC2aEi9VvzMg@mail.gmail.com> <CAH1iCio_3MCk8fVL4DiZD=qMsFCe+C-DSsTCgNOBnRYOjGUiMQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAH1iCio_3MCk8fVL4DiZD=qMsFCe+C-DSsTCgNOBnRYOjGUiMQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-wSfPATH5jYtprQW-6Zp2kMQJ6M>
Subject: Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Dec 2020 19:02:59 -0000

On Fri, Dec 18, 2020 at 10:28:48AM -0800, Brian Dickson wrote:
> On Fri, Dec 18, 2020 at 10:09 AM Enke Chen <enchen@paloaltonetworks.com> wrote:
> > No, I am not assuming that packets are getting somewhere. The
> > TCP_USER_TIMEOUT would work as long as there is "pending data" (either
> > unacked, or locally queued). The data can be from the local BGP Keepalives
> > or the TCP_KEEPALIVE.
>
> Actually, my point was not only about packets getting somewhere, but also
> that the LOCAL implementation of the TCP stack should not be assumed to be
> bug-free (in relevant ways).
> 
> Your response is still assuming that those mechanisms actually work 100%
> reliably 100% of the time.
> 
> Yes, if the implementation works correctly, TCP_USER_TIMEOUT would work.
> However, I'm saying the BGP code should not assume that is the case, and
> put some guard-rails around the behavior.
> The overhead of some small amount of checking, regardless of how it is
> done, is likely quite low.

What's also important is that using this option removes the ability for the
BGP implementation to make its own decisions.

In the presence of some level of packet drop, the window may not be able to
advance because the ACK covering the head end isn't getting through.  So,
even if some data is getting through and helping open space in the buffer,
this feature may cause us to close the session.

Jakob also makes the point that zero window in the send direction isn't
really helped here.

> (If packets are flowing, as viewed by updates and/or keepalives being seen
> from the peer, for example, it might not be necessary to invoke those
> checks? Or the check might only need to be done every $INTERVAL, like every
> minute or two.)

My experience is that using the TCP information in an advisory fashion is
helpful, but hard to make work consistently or portably.  Features that tie
into the stack to try to assess liveness or close sluggish sessions are
helpful if you don't care about the impact.  BGP implementations tend to
care about being resilient, especially for ISP circumstances.

-- Jeff