IETF Logo Mail Archive

Re: [Idr] WG Adoption call for draft-spaghetti-idr-bgp-sendholdtimer-09 (2/28/2023 to 3/14/2023)

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 09 March 2023 07:59 UTC

Return-Path: <swmike@swm.pp.se>
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 81820C14CF01 for <idr@ietfa.amsl.com>; Wed, 8 Mar 2023 23:59:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtuU9LyrBEAE for <idr@ietfa.amsl.com>; Wed, 8 Mar 2023 23:59:38 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 822A3C14CEFF for <idr@ietf.org>; Wed, 8 Mar 2023 23:59:36 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7CDACB2; Thu, 9 Mar 2023 08:59:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1678348772; bh=dZTpQou7zCFaBp33lSsiJwIUKLaxWUnINAosORcD2lE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=4YmM/L/QjIDUDA8KuM+TDRlnVuI7IQWaf3JybxhPRs9ZXIxeqGw5pj0FFjXh9NCuG 76MA17/DDPfXi2JQysobj4a3qROsQcNjw2bjAGGSoZFxMNW8eSQPpr/Qt4nHxvhLDM HpExHAQHHGCSD8lR+VgY5bPfbS+T5dakWJsyUfoc=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 77825AF; Thu, 9 Mar 2023 08:59:32 +0100 (CET)
Date: Thu, 09 Mar 2023 08:59:32 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Jeffrey Haas <jhaas@pfrc.org>
cc: Robert Raszuk <robert@raszuk.net>, idr@ietf.org
In-Reply-To: <8B30B017-295F-4D4E-B8EA-FF0E15471F47@pfrc.org>
Message-ID: <alpine.DEB.2.20.2303090854300.2636@uplift.swm.pp.se>
References: <BYAPR08MB4872FD426205CAC6F82D22BEB3AD9@BYAPR08MB4872.namprd08.prod.outlook.com> <alpine.DEB.2.20.2303070725390.2636@uplift.swm.pp.se> <CAOj+MMGUfxd1LLta9=_HU+uMKcbVVE6ijkG84-ST0LDo3m2MYQ@mail.gmail.com> <alpine.DEB.2.20.2303070953000.2636@uplift.swm.pp.se> <CAOj+MMF8gELjxXB=kmn3eTu8X96vP7ueOTSA6Q+V_086wfO=NQ@mail.gmail.com> <alpine.DEB.2.20.2303071107360.2636@uplift.swm.pp.se> <3caaea46-cc66-f084-ec9b-98783d6daa49@foobar.org> <CAOj+MME=-drWX_1=9T8jqBGvEfwB59PmjLoh65i8wvdppKFKYg@mail.gmail.com> <alpine.DEB.2.20.2303071224040.2636@uplift.swm.pp.se> <CAOj+MMFc29DOAL6QK3u9gzPBQPv3wRdhTRHRPD_1ABebtuX0=w@mail.gmail.com> <alpine.DEB.2.20.2303071246590.2636@uplift.swm.pp.se> <DB2B7372-D021-4E86-AF83-C6A55EF72D75@pfrc.org> <alpine.DEB.2.20.2303081108250.2636@uplift.swm.pp.se> <9505159A-F31F-4C1C-84BB-C9A2E7E46ED4@pfrc.org> <alpine.DEB.2.20.2303081757460.2636@uplift.swm.pp.se> <8B30B017-295F-4D4E-B8EA-FF0E15471F47@pfrc.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/C8I2307PGrn5b88cv3XYQQp9POw>
Subject: Re: [Idr] WG Adoption call for draft-spaghetti-idr-bgp-sendholdtimer-09 (2/28/2023 to 3/14/2023)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 09 Mar 2023 07:59:43 -0000

On Wed, 8 Mar 2023, Jeffrey Haas wrote:

> The headache at hand is missing acks and signaling a half duplex 
> disconnect compared to acks getting through but the window not opening. 
> That's your point, yes?

The ACKs aren't missing because there's no data to send because the window 
is 0. The wire part is perfect and no acks are missed, so I don't see how 
user-timeout helps.

> Mostly the scenario where you get sender backpressure because of lost acks.

If the some of the ACKs are lost on the wire then we'll still be able to 
send data and sendholdtimer won't kick in. If all the ACKs are lost then 
receiver won't get the messages and if it's working correctly, it'll close 
the session.

User-timeout addresses a wire issue, which isn't what sendholdtimer is try 
to address.

> At the API layer, you just know that you're blocked.

Correct.

> Does that solve the entirety of this problem?  No.  And that no is why 
> I'm not presenting the timeout as "this is THE SOLUTION to the problem". 
> At best, it's a useful tool in helping out.  Even then, I'm 
> uncomfortable with what an appropriate timeout would need to be.

If we want to solve wire issue then I'd suggest to use tcp keepalives and 
a configurable tcp keepalive timeout.

But that's not what's trying to be addresses here, neither "bailing out 
early". We're trying to address when sessions are stuck for hours or even 
days, and notifying/closing in reasonable time, which would be in the 
10-20 minute range, but could be up to hours if there's not much bgp 
traffic.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email