[Witarea] TCPM@IETF119

tuexen@fh-muenster.de Wed, 20 March 2024 07:46 UTC

Return-Path: <tuexen@fh-muenster.de>
X-Original-To: witarea@ietfa.amsl.com
Delivered-To: witarea@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D77C1DA2F2; Wed, 20 Mar 2024 00:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 VjCE9zBLzfP7; Wed, 20 Mar 2024 00:46:15 -0700 (PDT)
Received: from mx-out-02.fh-muenster.de (mx-out-02.fh-muenster.de [212.201.120.206]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB26C14F60F; Wed, 20 Mar 2024 00:46:13 -0700 (PDT)
Received: from mail-director-01.fh-muenster.de (mail-director-01.fh-muenster.de [185.149.215.227]) by mx-out-02.fh-muenster.de (Postfix) with ESMTPS id B44D4E0308; Wed, 20 Mar 2024 08:45:40 +0100 (CET)
Received: from smtpclient.apple (ip4d15f54e.dynamic.kabel-deutschland.de [77.21.245.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: tuexen) by mail-director-01.fh-muenster.de (Postfix) with ESMTPSA id 68B791A0057; Wed, 20 Mar 2024 08:45:40 +0100 (CET)
From: tuexen@fh-muenster.de
Content-Type: multipart/signed; boundary="Apple-Mail=_0B431411-4A48-43F5-8469-2F1E660FE555"; protocol="application/pkcs7-signature"; micalg="sha-256"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Message-Id: <F19CC6FA-7DBC-4DDF-B084-675EA65DB438@fh-muenster.de>
Date: Wed, 20 Mar 2024 08:45:39 +0100
Cc: tcpm-chairs <tcpm-chairs@ietf.org>
To: witarea@ietf.org
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/witarea/EWOl5Ytq2NV_ZVIEoZNPPBi3vpA>
Subject: [Witarea] TCPM@IETF119
X-BeenThere: witarea@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Web and Internet Transport \(WIT\) Area" <witarea.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/witarea>, <mailto:witarea-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/witarea/>
List-Post: <mailto:witarea@ietf.org>
List-Help: <mailto:witarea-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/witarea>, <mailto:witarea-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2024 07:46:19 -0000

Dear all,

TCPM met on Monday and discussed:

1. https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-08
   An update for RFC 6937 (Proportional Rate Reduction for TCP) which
   also brings RFC 6937bis to PS.
   This document is after WGLC and will be handed over to the IESG shortly
   after this IETF meeting.

2. https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-ack-rate-request-04
   This document described a TCP option which allows an TCP endpoint to
   request the sending of an ACK immediately or with a specific rate.
   It needs further discussion.

3. https://datatracker.ietf.org/doc/html/draft-wang-tcpm-tcp-service-affinity-option-04
   This document proposes a TCP extension which allows TCP to be
   used in an anycast environment. The document got some pushback and it was
   suggested to solve the problem at a layer different from TCP.

4. The handling of ghost ACKs was discussed. A Ghost ACK is a TCP
   segment acknowledging a sequence number which was never sent.
   Improving the handling of ghost ACKs can help in mitigating spoofing
   attacks for TCP. This will be described in a paper presented later
   this year at a conference.
   It was suggested to write a short ID, which can be used as a
   basis for further discussion.

Best regards
Michael