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

John Heasley <heas@shrubbery.net> Wed, 16 December 2020 16:42 UTC

Return-Path: <heas@shrubbery.net>
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 06CEB3A10FF for <idr@ietfa.amsl.com>; Wed, 16 Dec 2020 08:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ZnOD_rqIxtSD for <idr@ietfa.amsl.com>; Wed, 16 Dec 2020 08:42:30 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69AAD3A10E8 for <idr@ietf.org>; Wed, 16 Dec 2020 08:42:30 -0800 (PST)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id EE126CF2C; Wed, 16 Dec 2020 16:42:28 +0000 (UTC)
Date: Wed, 16 Dec 2020 16:42:28 +0000
From: John Heasley <heas@shrubbery.net>
To: Tony Li <tony.li@tony.li>
Cc: John Heasley <heas@shrubbery.net>, "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>, Keyur Patel <keyur@arrcus.com>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <X9o49HgS2ITD0SX6@shrubbery.net>
References: <2F238121-E468-4D0F-A0FF-9D82E44C3247@arrcus.com> <57DF4DA1-256A-4FA9-8827-EFF6D9ED2A2E@gmail.com> <BBEA6C0A-5727-4D9F-8D7C-74E572ED612D@arrcus.com> <BYAPR11MB3207C98296234C953487D6ECC0C90@BYAPR11MB3207.namprd11.prod.outlook.com> <X9lRiQF/y6emL15n@shrubbery.net> <D702B186-6270-42EB-B4C8-315555848A6F@tony.li>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D702B186-6270-42EB-B4C8-315555848A6F@tony.li>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/rgfOHXkb7q4u1aejF-kmeyoypHA>
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: Wed, 16 Dec 2020 16:42:32 -0000

Tue, Dec 15, 2020 at 04:43:31PM -0800, Tony Li:
> > On Dec 15, 2020, at 4:15 PM, john heasley <heas@shrubbery.net> wrote:
> > 
> > Could a sender test the liveliness of a peer by attempting to open a
> > new session?  would a successful 3-way and commencement of BGP OPEN be
> > an indication that it should be more patient, increase its "deadtimer"
> > (HOLDTIME < STUCKTIME < PATHETICTIME)?  Clearly the remote has been
> > sending bgp keepalives, so perhaps not for all implementations.
> > 
> > could an implementation more tightly coupled to its tcp use the urgent
> > pointer to test liveliness?
> 
> 
> Hi Heas,
> 
> In modern implementations that are multi-threaded or multi-process, the ability to open 
> a new connection only demonstrates liveness of the destination stack. The upper
> level thread may not be alive, either due to protocol implementation issues or
> OS issues.
> 
> Tony

Hey tli,
That is why I added "commencement of the BGP OPEN," but I suppose a
threaded implementation could use separate threads for various
operations, not just i/o vs other ops.

rfc721 is another thought, but rfc7805 likely kills that and Stevens IIRC
suggested the implementation was varied - some might separate it from the
normal send/recv buffers (ie: win=0 is irrelevant) and some might not
provide a way to retrieve the data in parrallel.  I haven't tinkered with
it since ~1989 on Encore Umax.