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> Wed, 08 March 2023 17:06 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 69783C1522DA for <idr@ietfa.amsl.com>; Wed, 8 Mar 2023 09:06:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.394
X-Spam-Level:
X-Spam-Status: No, score=-4.394 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_DNSWL_MED=-2.3, 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 gXUWvqxJXBt4 for <idr@ietfa.amsl.com>; Wed, 8 Mar 2023 09:06:19 -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 48191C1524AE for <idr@ietf.org>; Wed, 8 Mar 2023 09:06:18 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1BBF9B4; Wed, 8 Mar 2023 18:06:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1678295173; bh=Lt8nvFOgWXrqmrMjNjQwGqJ0dI1HPmz/siJaTdJ6xug=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Buop2BJHZUd5peF14aKwjTMQRsdo7s5weDz7V+SdgAI1ceJS2Tn6b/5T7lWntf5jY D5xC2gcwp6YieKpjU2ueth8B72F/TpE7taG6buHPSPoQeGFCmtHl3dwMf7pnEch1BY rhbRywZjw8Mkme3kAXIhiMdbPSVCFClHlPTSsG5U=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 17065B3; Wed, 8 Mar 2023 18:06:13 +0100 (CET)
Date: Wed, 08 Mar 2023 18:06:13 +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: <9505159A-F31F-4C1C-84BB-C9A2E7E46ED4@pfrc.org>
Message-ID: <alpine.DEB.2.20.2303081757460.2636@uplift.swm.pp.se>
References: <BYAPR08MB4872FD426205CAC6F82D22BEB3AD9@BYAPR08MB4872.namprd08.prod.outlook.com> <m2edq1ac7s.wl-randy@psg.com> <ZAZSyywxxg0HkaDw@snel> <CAOj+MMGiB8iiqKbj40kZsSFAQXCQ+baGQWuA7oQ1D0qF5aygeQ@mail.gmail.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>
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/SxneRm0tEjo-nZo-KeiP6NOm75I>
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: Wed, 08 Mar 2023 17:06:24 -0000

On Wed, 8 Mar 2023, Jeffrey Haas wrote:

> In one case, it's not necessary for a sender to block due to lack of 
> buffer.  TCP can provide the necessary information via user-timeout that 
> the receiver is not consuming the things sent to it.  This is the 
> user-timeout methodology.

This is not how I read RFC5482 (which I hope is the one we're discussing).

That's why I don't understand how user-timeout solves anything we're 
discussing here. User-timeout seems to just solve issues on the wire, not 
application layer.

> Both approaches will eventually tell you that a receiver isn't draining.

Does it? If the receiver is not reading the socket, window goes to 0 and 
there's no data to be left un-acknowledged as it hasn't been sent yet, so 
I don't see how user-timeout will help.

There is running code for the sendholdtimer proposal that has been shown 
to help, can the people proposing user-timeout please provide code and 
test-case to show that it actually works the way they think?

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

v2.23.0 | Report a Bug | By Email