From moeller0@gmx.de  Wed Dec 13 12:05:34 2023
Return-Path: <moeller0@gmx.de>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 290ADC14F5ED
 for <ippm@ietfa.amsl.com>; Wed, 13 Dec 2023 12:05:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.853
X-Spam-Level: 
X-Spam-Status: No, score=-6.853 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,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,
 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
 header.d=gmx.de
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 ODX_V1QLkaNn for <ippm@ietfa.amsl.com>;
 Wed, 13 Dec 2023 12:05:30 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest
 SHA256) (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 0750DC14F5E0
 for <ippm@ietf.org>; Wed, 13 Dec 2023 12:05:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417;
 t=1702497928; x=1703102728; i=moeller0@gmx.de;
 bh=OmF02cxYXWxQ0DLHQpzcbJJqvvvmPZy+6hXPW8yfE+o=;
 h=X-UI-Sender-Class:From:Subject:Date:To;
 b=VSjG0AbhZyXSYn17TO1kyHAGXwa7awCIIW3w/suYT7Kakeaq9EkUA7eAy0eHcthf
 VlO6FZLzxT4nQomhRUq5AVJ1m6KTkoISIE1fHPUCcQNtbf+nuYgXqNnnAHYIwF2dA
 BnJCqH8lazJZCRAAX8N19D+Lq9Lse2QEnEd3B93Zdjx7E4yqpJPYC06UImk2wmJ0m
 POzKLrDLr4pwX6Uzjbb4mbhcgL6ARjoiPe8fI/7VLSal8uhN73Ci8Pe5BMrRGI1/S
 84f0PtKHVVvvP6YQvy4pVHVhOoScC7NHxpqodmdgwnETvDkZRPH0hghziIBGlxnpY
 vKT/81fhzeWM6gvfCQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from smtpclient.apple ([77.8.9.232]) by mail.gmx.net (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MbzuH-1rlS7j18Yx-00dZS1 for
 <ippm@ietf.org>; Wed, 13 Dec 2023 21:05:28 +0100
From: Sebastian Moeller <moeller0@gmx.de>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\))
Message-Id: <494C914A-D9CC-4822-85D5-63F6DE849E71@gmx.de>
Date: Wed, 13 Dec 2023 21:05:27 +0100
To: IETF IPPM WG <ippm@ietf.org>
X-Mailer: Apple Mail (2.3696.120.41.1.4)
X-Provags-ID: V03:K1:TxKSe3UHvfHnK/xmfZLIZPwoyG19oS5fhZDptEX5gGjBGLMFclY
 gjyEdkXv2f93YJbVcgnp/nbL74T8Dgo/D6Ei6zyHyIwxYE1i1MYFT4mDxiBSpMdm6w6dlmM
 0Q2J9n/ciAB3j2cPa6RkWEnvMU6XevAq3+XkbIKaxdOyBAW5wTq+GsQBpJHbEcbM6HHw5ig
 s7YPIPGoNiWUKZkFVJYEQ==
UI-OutboundReport: notjunk:1;M01:P0:p8f08+5mcSI=;nyCao1EDn0IdzPzbQLYAUdsSTLN
 RTxKHIBvW1Bi2MOAMz2hCr8ymwmyo9+uHIoHytTkz6uijnCgM+t57Y7BFwjLWqFFwXc7zmb46
 6etL6kJwZRGyd+lgdo62nHotpuVAB08J1CUFdFx1RHeb0AoNGoPHEON0kYxv+Mn4lJjUd9IE2
 J9rQ3KsKK5GpANzWdi7VfGHFKWKQLhV1RbZnEgDZ+IbHYp4fgVShSG1cFzKuKNYFXoGTJzeTy
 JFfJO5lEL3wRRIzx0VNwk1RjO/3AzuoSFb2XMhZWtX+k/NL5grtqFabPgYVu6GlO2/2sOag+4
 6xJ3joIuVewE5+75AMHCFXBonY3teTC8kbHSEz98PqioYjZm4bMHwiY2d0aypsU/SXbvQe321
 45pVEki6jJLLl0i5EO/cHnjNu+K9HQlVbNvcbESmz5UWodeRo08ye6LgQnyYbbs5uORLuxICD
 tubywZw562kUrKx3u6MFQ5Pb4kRUXFhjycY38GEuO4RWbGl43EClPJJh+RevSnWUgBpyjBoxH
 Em/tBs/Naun1Fg5qivj46wthY0UUSnTWwl2JPuxIEcx15VNgldutpZLhMvGHHqLcVkk3JKyGB
 da47MJ5I4PoL1GWsLo2axNTDkbRGERaajWZFnwF0WLhZdVO6zzuPGMnl3z9XgGdu/UOgitP5y
 RJBQctzSEqgCWSD8Z2NVX693juGzI6QFwNMT8ScbS3AjqxLNKjW7BsvoRXFewvtSnZhtPPE39
 Dt33mLbvMR5CrfFHfCQUjiM4bU00JLZnxxCxJGeb73aJfCv4NialMFL4tBxyGad7SHtmfmYJS
 SaUDqZ2l3Nx2G5h2lrS5S1HaFwSXk7+hRk+3xF/oMJdOZtGSfiHsq4UwtH3JdcHzuC3ilEuEb
 DIO7DD7ieQMq1gH3tu/4rfmsPkU4poHhw7Y0OOPO7ghdjwlzRpJm224aS/5kv+13KpixxN7KE
 XA4MdA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/8cVaPjEqZw-XJvBxyTvR3r2ustA>
Subject: [ippm]
 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-responsiveness-03
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>,
 <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>,
 <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Dec 2023 20:05:34 -0000

Dear List,

I revisited my assessment of the actual calculation, and think we can do =
better (with little effort):


"The responsiveness is then calculated as the weighted mean:
Responsiveness =3D 60000 /
(1/6*(TM(tcp_f) + TM(tls_f) + TM(http_f)) + 1/2*TM(http_s))

This responsiveness value presents round-trips per minute (RPM)."

And this makes sense for a single value result; though I believe that =
mixing up the self and the foreign probes into one aggregate is not the =
best we can do. At least for a standardized verbose output I think we =
should report self and foreign RPM values separately, exactly because =
they do measure subtly different things:
foreign: inter-flow queueing
self: intra-flow queueing

these are not the same and hence aggregating them into a single number =
will not be the optimal to predict how well a link will behave under =
realistic loads.

Especially, since the different types of queueing delay have different =
remedies (e.g. flow queuing will help foreign RPM, while AQMs will help =
self RPM, some more and some less).


I also had a look at the recommendations regarding L4S testing:

"As clients and servers become deployed that use L4S congestion control =
(e.g., TCP Prague with ECT(1) packet marking), for their normal traffic =
when it is available, and fall back to traditional loss-based congestion =
controls (e.g., Reno or CUBIC) otherwise, the same strategy SHOULD be =
used for Responsiveness Test traffic. This is RECOMMENDED so that the =
synthetic traffic generated by the Responsiveness Test mimics real-world =
traffic for that server."

I think this at least needs to be selectable via command line switches =
(and the question arises whether working latency would not require a mix =
of L4S and non-L4S TCP flows with separate RPM reports for each type).

Regards
	Sebastian=

