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

Keyur Patel <keyur@arrcus.com> Wed, 16 December 2020 00:44 UTC

Return-Path: <keyur@arrcus.com>
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 0EF033A09E8 for <idr@ietfa.amsl.com>; Tue, 15 Dec 2020 16:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com
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 gPqEf2PulNth for <idr@ietfa.amsl.com>; Tue, 15 Dec 2020 16:44:36 -0800 (PST)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2040.outbound.protection.outlook.com [40.107.243.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F410A3A0957 for <idr@ietf.org>; Tue, 15 Dec 2020 16:44:35 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=btp8Bh1SanIr9RYGNNfXAQcoV2Y1xE8thb/3WGNMK1TEsl7GaqJJ3DvgKSFLR319Yh7tgaksIDqoriLCiaSJADjCJhTH/B8p2zLY6BPdhJe78NYW8d0pwnne6V/VDEbaUUpL+t/38Uh4kS1U5eQRtjCIKt2y0cUka+5O7frJBYA8TLKbfNlCqaKOpX/17nS+HM/AV7DrwFhfHw12+kG0LjCd7/aDKdyseC2tA3u65A9pwW6T198inMAibr3TRUo1gZc5DPNhm3G2BlOsRfwJ3fPC55TrhIAuCUVjkEIrVmLdypG4p4s566XnW38iy0z4QLIJtE5Gy+hYGQbpz3CSbA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KetNuqS6yyete3VdLy7QXjH4Hbgom3ttOQkf7hvLLb0=; b=hO9Ys9og4jTAaFOFti/t4zkSwXWZF0itxeQmmhJG82geryYezQLWpIL5PFQVloFpY1NvJrusQWlsMykzEmEY7nZ1AQiqJteffExoWm+Ptskwts8FIdgZNWQAA1/oB5ygERn++1/tjcWngVV3TgDyY5EaBdyNF6hvJ8rtthjV12ON5PLD2gE1v9lSLIQ8Nbn/6k+TObKt71w0vEnuLYrTta+XjUGqjUXZQNwBtFe+7AvAlxuriwS2YeGeqqE+jrAfo+uwjoyhlI9ZTck7cSiJ/UB0DVeD6iDHzCfvVHDLcawuG+gABS30fVIjf2jh5fIdsgeZgjgpc55cmZp230Xr4g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KetNuqS6yyete3VdLy7QXjH4Hbgom3ttOQkf7hvLLb0=; b=QOWsDUkt79el6SsqUnR3CvTLTR3zB/dhN0qwXOgysI0YP82VrEMlMWHUBGoMv0mJZ582I0yh8I8QGpn55IyblcHUTDP0aCgn7T6JT32eLJgphiZfvC/L5tEiEkVKSLSho4rT/Tb+m/43f683E/ad5LrbC2svnZ2ZCAvN7FE2+n0=
Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by SJ0PR18MB4041.namprd18.prod.outlook.com (2603:10b6:a03:2e5::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.24; Wed, 16 Dec 2020 00:44:29 +0000
Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::6835:7b3f:491c:74b4]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::6835:7b3f:491c:74b4%4]) with mapi id 15.20.3654.025; Wed, 16 Dec 2020 00:44:29 +0000
From: Keyur Patel <keyur@arrcus.com>
To: john heasley <heas@shrubbery.net>, "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
CC: Jeff Tantsura <jefftant.ietf@gmail.com>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0
Thread-Index: AQHWz/PTKqeqTOTeJ0S3IgM5E+6+BanyUWWA//+zxQCAAI2nAP//lCGAgACnBQCABhMjgP//ghkA
Date: Wed, 16 Dec 2020 00:44:28 +0000
Message-ID: <36B6DC29-F0FE-432C-ADFC-2CB312D16717@arrcus.com>
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>
In-Reply-To: <X9lRiQF/y6emL15n@shrubbery.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.43.20110804
authentication-results: shrubbery.net; dkim=none (message not signed) header.d=none;shrubbery.net; dmarc=none action=none header.from=arrcus.com;
x-originating-ip: [2601:646:9a00:1990:9050:6175:d6b1:be6f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 704c1ed8-6ace-4183-67c8-08d8a15bbefd
x-ms-traffictypediagnostic: SJ0PR18MB4041:
x-microsoft-antispam-prvs: <SJ0PR18MB404129A5C2DEE038421E3450C1C50@SJ0PR18MB4041.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Cuq9gfk2Dam081G92/9iEVNKx2kPq3sogw+J2XIa13WSLjqEEoZ515HOb1r+sUWk8GucGZ0uoyAnf/yzWKpJupg5V4TRdcZUKjz6Asps2JmSD7ciHpe7IwSphHZCk7QqYugrFMaHtW51+ma+by8jR+q3GmykXlcJ0QPb8buyTOWQt/q9U+7ZWSBkARXn4Ft9BT5RTE5TsZUgwqsdQRGUkFwJsBuPAIDGxCC9l04oZHFDxBlgI3ujWHpNL38eAAtp+POz7ujbSY8yvGwYL0AosDcTMQWQ1FAeRK6KC/wENaeS8khHZq9FksI5S8F8BVe9l2Y1Nd1PaxxmFfHhjfNQvaiRfqSdnvhjomOwKUoJFYiDL8zapt+UQc7zvMjwFHsS
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(39830400003)(396003)(376002)(346002)(136003)(366004)(54906003)(110136005)(66446008)(64756008)(8676002)(71200400001)(2906002)(33656002)(186003)(8936002)(6512007)(316002)(6506007)(2616005)(4326008)(66556008)(76116006)(66476007)(6486002)(478600001)(66946007)(83380400001)(5660300002)(86362001)(36756003)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?d3R0TFR4N2N6Q3ZRZ2Q0bm5jdk1kM0VnSTBRdXhYdU9QeWM0MW1Sd3FMcDZu?= =?utf-8?B?L2F6ZlNVeUFpYmNLa1NhSDVUdmdQRnZLMXU5V2VpOVF2eE1iSUZhUXBpaDNK?= =?utf-8?B?ZlJ0b3U5c0JKQkl1SFE3L0FXVm8yVTkzL0JoMXM4d1BSRFBLSXRlWmgwS044?= =?utf-8?B?OC83SXh1WUhualRjQktDV1RrRVh0aXNFV2sxRTdUb0N3Y2VacnhVR0kzQ1hR?= =?utf-8?B?TUl0SFhheFhVMFBXY3ZSZ0FhWld5SVFjUlJOYzJsV2hwdUt5cUdjOTh1dEY5?= =?utf-8?B?T1UweW1IZHhhUFNHcWk0UmNQNlBZc05DZTIyZWc1T3JDeXdWTnRKTDVneUZq?= =?utf-8?B?U1lxYWNySVI1cFNLanlUdFBVdFlIejJ3L09ia3RERVFuNnBJblBzYWhVaVJn?= =?utf-8?B?TFZHc01iUTk4NE1XeFliUldrclg5Z3ExOUVpTGcxK09DSnNpNk5XVkhlZmRU?= =?utf-8?B?cFNvNGlpYStmVmUxSHROd21qZFRXMmxEVkRhbmRqTUNncDBnelpvWm1SZVNW?= =?utf-8?B?aHFubHFseHhWc0ZJZWR4eURac1RDZlMva0tPKzYzOU9NczM2MkFoZC9QazNr?= =?utf-8?B?VlhTK3hjczVIaTdqd2FGSVY3RGUyRFBzWVlkOVB4eWVOcnU0Skllbk01ZnRN?= =?utf-8?B?aE4yK2RMdXZ1ck5nWmxUb2xxNGRRSVJaQmNvaUE4WlRod0FHdkt1NEorbUkv?= =?utf-8?B?OHRMdWJWaWJCZENSbklwY0VQN1VrLytIeWFDeGlVVVFIWWpheVVYbTNEbWJz?= =?utf-8?B?NGZETmVHTGZuR204Uzc4WExDUW5pdk9OcXNTZldpR3BXQVBoMG55M25HbWU2?= =?utf-8?B?eUlJQmk4MUZVdTA2SnJNb1ZHSmVJdTZZODRzMGQwNjdwa3I0Tis3VmhZcS9L?= =?utf-8?B?QzVmcDhrU2dSWTZyVkI3RThCU3FWenVyY3hycW9oY3MvbFdrSW1yK2k2WHlP?= =?utf-8?B?U0xnYnc5RlgrWklyZGNqakdXV0EyTzZUS3pXRDlGNnVTUHBOOUhEMXltazFh?= =?utf-8?B?TDMzMkRqVitTdGt1N3NwbGdHWVlGTEhmdS9jQU9SeWNpSU16eUFNYlBGTmZK?= =?utf-8?B?YUd1c3FXSjlPMzMxSWVoUUd2c3EyS1ZFeWZKMGRIMWwzYlh6bmVvNlh2eDlT?= =?utf-8?B?Vkt6dWZHSXpRWXZmc2tmeUx2dzB1YTlNR2JPRS90RFNZL1J4ZVlqcytCeWJp?= =?utf-8?B?MDlxSC9iQ2NxYkZ2UmdJU1JXcDh0YmNJRDhBR2xRMXNaNXFjZ0R2NVJrQitt?= =?utf-8?B?Y2E2YVZBeW0xT1lFbGpuKzNjS2liZnM3eHhpTWlnUUM0SEp4YlRjNFdoRkh3?= =?utf-8?B?dVBBQ3VOUldHWVlMUk1KNmVYMXlwMXBTNzhHanNtYWp2Uzc1MjMvY3ZTVHBK?= =?utf-8?B?TFV0akwycnE3dVJwbWRzYjlOWFpGd2x3Y2cxVWxEZUVBSFFZMzZVbnc4Y2NP?= =?utf-8?Q?hv1uscO4?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <D3169FFFA4DCEA409A5C16D59B49A661@namprd18.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 704c1ed8-6ace-4183-67c8-08d8a15bbefd
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2020 00:44:29.0239 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LM/qiOlWQZwrr+kg3kPg5d3OQ3Ovhrt8jmgwutGn8W+o0uswdkSTq6+T9nL2S94+Xa0rA2QC0KGcfjDGabXt1g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR18MB4041
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/T1tBq_uzWAgh1uO6q28FqrZkbxU>
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 00:44:37 -0000

Comments inlined #Keyur

On 12/15/20, 4:15 PM, "john heasley" <heas@shrubbery.net> wrote:

    Sat, Dec 12, 2020 at 03:29:02AM +0000, Jakob Heitz (jheitz):
    > Good point Keyur.
    > A receiver may be overwhelmed for a long time and not open its TCP window to avoid
    > silly window syndrome or some other reason. The receiver may still be functional
    > and able to clear its backlog, albeit in a long time. Resetting such a session
    > will only make the situation worse. Telling the difference between this case
    > and a receiver stuck in a bug is difficult.

    It seems that closing after HOLDTIME would be fragile at boot-time of the
    receiver or recovery of an IxP interface, when there is high demand -
    which I think is keyur's comment.  Maybe this should not be enforced until
    an EoR marker, allowing a receiver to retard new, GR, or RtRefresh peers?

#Keyur: Or a normal route-refresh as well.

    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.

#Keyur: Please note that the problem here is mostly a slow/faulty receiver. Any session reset is less likely to solve issues unless the receiving side processing related issues are solved first. 

    could an implementation more tightly coupled to its tcp use the urgent
    pointer to test liveliness?