[tsvwg] What to do when TCP receive window is closed

Adrian Farrel <adrian@olddog.co.uk> Tue, 04 June 2024 10:25 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6228CC14F6A6 for <tsvwg@ietfa.amsl.com>; Tue, 4 Jun 2024 03:25:47 -0700 (PDT)
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 (2048-bit key) header.d=olddog.co.uk
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 vLgozdUxvI7E for <tsvwg@ietfa.amsl.com>; Tue, 4 Jun 2024 03:25:42 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 8E7D7C14F6A2 for <tsvwg@ietf.org>; Tue, 4 Jun 2024 03:25:41 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.7/8.14.7) with ESMTP id 454APdc8001886 for <tsvwg@ietf.org>; Tue, 4 Jun 2024 11:25:39 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 90A8E46052 for <tsvwg@ietf.org>; Tue, 4 Jun 2024 11:25:39 +0100 (BST)
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8EE6E4604C for <tsvwg@ietf.org>; Tue, 4 Jun 2024 11:25:39 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS for <tsvwg@ietf.org>; Tue, 4 Jun 2024 11:25:39 +0100 (BST)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 454APZEW004393 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <tsvwg@ietf.org>; Tue, 4 Jun 2024 11:25:35 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: tsvwg@ietf.org
Date: Tue, 04 Jun 2024 11:25:34 +0100
Organization: Old Dog Consulting
Message-ID: <0b1901dab669$8bc1b4c0$a3451e40$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: Adq2ZfvIbLsNE+DuTyWErFnMuEQCKw==
Content-Language: en-gb
X-Originating-IP: 82.69.109.75
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=20221128; bh=kBnbV2lzN2FMNnPbD4na2 POLpzSarAgj4OPCdsA/DwY=; b=qe5uxeZ6DTKvedXu+eG+p4TuUS7Hn9Jg+SFN8 7xqbCguyNsFo3+efrU4m+KKpK9GUcA2/O2CuXXP8eMhBI59eX8Hm/eK4MRSTnoVj b/X1ChX+nMy9elbc4vulgkoAh/9TC2y1+Mdkb2Nh1W1WzbFw9tztHJ5CHJqk3O68 rp7c8snBf0Seam0DexvVwDuiujNRFaFXETFlmmLvYGFLBdAr3jmhu7kvYpO+b9Pj ulpDD4FdUEjac06hhnow4OR0s99Krb79ZnNfjruJyBRmtLj6TFIzR0EbTcBkAuO4 0SNM9OpG4MkGvZMOaJWejuxZ7+ihlGNL1ONF+q+W/0YmLprFg==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28352.003
X-TM-AS-Result: No--15.757-10.0-31-10
X-imss-scan-details: No--15.757-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003
X-TMASE-Result: 10--15.756900-10.000000
X-TMASE-MatchedRID: pjj54ow6YrYOwAmmWH5kBIh/ebSxR/HnRealVAhocE9o5YsPsbyLXcZ1 F88rHoscLOuN9XNS1XV7L4dx4z+0QClp37hedPpaaDCzqDR7DPYoJgWvWZKR0ExoJnTb6pJfS48 IjXi9YDkzttiZ3Ke8YyN5cCsKkJ8NWkm9KQacZuhVXhlmZsTdjDWRH7TlULWGrQYkvYRXmkwymo xuOHqiDDg42mgh6SZtkaHqUIIvrPIusKlLTWoTlQQ6EfMOwvTmBGvINcfHqhcKz90vj69pJNcui tm8VQRh36Mvc7iD5208S9lzU4VSlDcpdZ3fQiLdOX/V8P8ail1bCjvvWZW+SY7xHquoAJGGzejQ nCWkgU8LbigRnpKlKT4yqD4LKu3A
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Message-ID-Hash: 42CUSSDDAW4MIBTLLBOSGWYH3NLSAJSA
X-Message-ID-Hash: 42CUSSDDAW4MIBTLLBOSGWYH3NLSAJSA
X-MailFrom: adrian@olddog.co.uk
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Reply-To: adrian@olddog.co.uk
Subject: [tsvwg] What to do when TCP receive window is closed
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/s8te82neovylFWAYFdBV_ceJISs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>

Hi,

I wanted to draw your attention to four new I-Ds.

https://datatracker.ietf.org/doc/draft-lin-mpls-ldp-holdtimer/
https://datatracker.ietf.org/doc/draft-lin-pcep-sendholdtimer/
https://datatracker.ietf.org/doc/draft-liu-pim-msdp-sendholdtimer/
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-sendholdtimer/

Note that the last in this has already been passed to the AD as a
publication request.

They all offer protocol solutions for clients of TCP that find they are
unable to send protocol messages because (e.g.) the remote peer's TCP
receive window has been closed and appears to be stuck shut. 

The assumption seems to be that it is "normally" the responsibility of the
remote peer to close the client protocol session (that runs over TCP) if a
problem occurs that causes it to (permanently) close the receive window, but
that that might not happen (perhaps, including the problem being a
processing loop or very high workload).

The solution in all four drafts seems to be the same: run a timer in the
client protocol to detect how long the sender has been blocked. Have the
sender close the TCP session when the timer expires. (The sender can't shut
the client protocol session, because it can't send protocol messages.)

A key element of this is that the client doesn't know that the remote
receive window is shut except, perhaps, by a shortage of send buffers. So
the solution relies on a timer applied in the client protocol to check the
progress of handshake keepalive messages in the client protocol.

Given that this solution is proposed across multiple client protocols, and
given that the solution is to pull down the TCP session on a timer, I
wondered why this isn't part of TCP. 

Anyway, this email is just to flag to the TCP-aware bit of the IETF that
this discussion is happening in the Routing Area.

Cheers,
Adrian