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

Michael Tuexen <michael.tuexen@lurchi.franken.de> Tue, 04 June 2024 12:19 UTC

Return-Path: <michael.tuexen@lurchi.franken.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 42B87C14F73E for <tsvwg@ietfa.amsl.com>; Tue, 4 Jun 2024 05:19:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.628
X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.259, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gIGqf2x4tGg4 for <tsvwg@ietfa.amsl.com>; Tue, 4 Jun 2024 05:19:24 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2B0C14F6F7 for <tsvwg@ietf.org>; Tue, 4 Jun 2024 05:19:23 -0700 (PDT)
Received: from smtpclient.apple (p200300cd6f4f01000ccafb44b2cd53f3.dip0.t-ipconnect.de [IPv6:2003:cd:6f4f:100:cca:fb44:b2cd:53f3]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id E111A721E2806; Tue, 4 Jun 2024 14:19:17 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <0b1901dab669$8bc1b4c0$a3451e40$@olddog.co.uk>
Date: Tue, 04 Jun 2024 14:19:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E46CDEB8-FC28-49ED-9D7C-2A44C4CD0439@lurchi.franken.de>
References: <0b1901dab669$8bc1b4c0$a3451e40$@olddog.co.uk>
To: adrian@olddog.co.uk
X-Mailer: Apple Mail (2.3774.600.62)
X-MailFrom: michael.tuexen@lurchi.franken.de
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
CC: tsvwg@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tsvwg] Re: 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/ezJuBGEnz7JhX9tuno_rjvkeRIQ>
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>

> On 4. Jun 2024, at 12:25, Adrian Farrel <adrian@olddog.co.uk> wrote:
> Hi,
> I wanted to draw your attention to four new I-Ds.
Hi Adrian,

you might also want to send this mail to tcpm@ietf.org <mailto:tcpm@ietf.org>.

Best regards
> 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