IETF Logo Mail Archive

Re: [tsvwg] draft-kuhn-quic-careful-resume-02: Linux tcp_metrics

Michael Welzl <michawe@ifi.uio.no> Tue, 08 November 2022 12:17 UTC

Return-Path: <michawe@ifi.uio.no>
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 2277CC14CE37 for <tsvwg@ietfa.amsl.com>; Tue, 8 Nov 2022 04:17:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.007
X-Spam-Level:
X-Spam-Status: No, score=-7.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=ifi.uio.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 QUJpdtM1Ucht for <tsvwg@ietfa.amsl.com>; Tue, 8 Nov 2022 04:17:39 -0800 (PST)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 D725EC14F720 for <tsvwg@ietf.org>; Tue, 8 Nov 2022 04:17:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ifi.uio.no; s=key2103; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version: Content-Type:Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=QyqHFS8xNDkNEFPVmRZEoAYfoWnNKv0teuqj74/Mgpk=; b=hfjQSvXRuSX/2qzcoVCekFt1ki Qys2N9MN4HJScCc1UFtVDJoC9nq1nAnQtgaDycawHBndw3sPzPIxsHcKzjb4jsVrO7uGhsSrV47Ok iaH47d7O39vUmQbgRcyQ28DN6PC+USJMgj7pvLBAVTFky2a4VtIxxpL4k/514t8wKly8oa9s9KtrI Vud12U+1K210TMjVRKOE/2Pt9lMb9t6UKTAF8na0qsbHkYHoFmKBgY6ZKMyxMeyt0Gtb3ZIfH3oZW vd36WdKZaIWDUEX2JyfwTDmLi4Phyvc/gaNEoW7wiwlUNT/fnjHQsfPCEumTqlxLoW5Y7p3ie4Tp5 bmSBTwbg==;
Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <michawe@ifi.uio.no>) id 1osNXq-00FlXE-0w; Tue, 08 Nov 2022 13:17:34 +0100
Received: from dhcp-938c.meeting.ietf.org ([31.133.147.140] helo=smtpclient.apple) by mail-mx03.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.96) (envelope-from <michawe@ifi.uio.no>) id 1osNXp-000Fqs-20; Tue, 08 Nov 2022 13:17:34 +0100
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <AF5947E2-6E88-4B1F-9447-1D0F5DEF4042@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_24651799-A76F-4F3C-9CB6-319C45260D76"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Tue, 08 Nov 2022 12:17:32 +0000
In-Reply-To: <245BEDAD-9E69-4D4D-A669-926EB12D6738@bbc.co.uk>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
To: Piers O'Hanlon <piers.ohanlon@bbc.co.uk>
References: <245BEDAD-9E69-4D4D-A669-926EB12D6738@bbc.co.uk>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 31.133.147.140 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.147.140; envelope-from=michawe@ifi.uio.no; helo=smtpclient.apple;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.2, required=5.0, autolearn=disabled, AWL=-0.199, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: CD347C2D9AAD171F3CC375FA4EB54D3801E828C2
X-UiOonly: 0AE578F2ADB3B1A42DC20E2B20DFA68615E794C0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/dKIdzTpCdTmwy9KRE7VuNQ0zNYE>
Subject: Re: [tsvwg] draft-kuhn-quic-careful-resume-02: Linux tcp_metrics
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2022 12:17:44 -0000

Some related information, from Jan’21, is also available in RFC 9040, specifically at:
https://www.rfc-editor.org/rfc/rfc9040.html#name-implementation-observations <https://www.rfc-editor.org/rfc/rfc9040.html#name-implementation-observations>

Cheers,
Michael


> On Nov 8, 2022, at 8:52 AM, Piers O'Hanlon <piers.ohanlon@bbc.co.uk> wrote:
> 
> Hi,
> 
> As suggested by Gorry in yesterday’s WG meeting I’m posting what I brought to the mic.
> 
> I wanted to highlight that it would be useful to examine the existing related Linux kernel mechanisms which re-use cached metrics for TCP connections. I’ve briefly looked at the logic which stores a metric block for all connections that finish successfully (net/ipv4/tcp_metrics.c:tcp_update_metrics()) which are accessible via the `ip` command:
> e.g.
> $ ip tcp_metrics
> 192.168.0.1 age 528954.152sec ssthresh 14 cwnd 15 rtt 14439us rttvar 18665us source 10.10.10.3
> …
> 
> When a new connection starts metrics are reused according to rules defined (net/ipv4/tcp_metrics.c:tcp_init_metrics()).
> 
> I understand some of this also happens in other operating systems but I’m not aware of the details.
> 
> Piers

v2.23.0 | Report a Bug | By Email