From tpauly@apple.com Tue Jan 9 14:03:09 2024 Return-Path: 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 480F2C15198C for ; Tue, 9 Jan 2024 14:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.103 X-Spam-Level: X-Spam-Status: No, score=-7.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 wTP_WApzQSFX for ; Tue, 9 Jan 2024 14:03:05 -0800 (PST) Received: from ma-mailsvcp-mx-lapp03.apple.com (ma-mailsvcp-mx-lapp03.apple.com [17.32.222.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 E8DE8C1654EB for ; Tue, 9 Jan 2024 14:03:04 -0800 (PST) Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma-mailsvcp-mx-lapp03.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S7000TPSL8T5G30@ma-mailsvcp-mx-lapp03.apple.com> for ippm@ietf.org; Tue, 09 Jan 2024 14:03:03 -0800 (PST) X-Proofpoint-ORIG-GUID: 2XTgktIh_FNt5aPhYRwjeRLytQ1rXG5m X-Proofpoint-GUID: 2XTgktIh_FNt5aPhYRwjeRLytQ1rXG5m X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2024-01-09_11:2024-01-09, 2024-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 adultscore=0 mlxlogscore=999 spamscore=0 malwarescore=0 phishscore=0 mlxscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2401090175 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=VLwDiyoQpkUSZNMjBDtLkYrK+X3daAmzJpQC6kALCEo=; b=AWIG3CDsqyRkeX0YvNvhtwxdRht9TKsUIbtT2Eia4O7ejp7Y2ONb+WdWv3yNzYJbWwBD d4cd+73JHlxUlt26PVoFhRyYTEFRyBmm4wKdgltB17r6vCrt8uYkvRDeM8wmJ55aYrzC JF9MK30HJxetrxtnw/xDM1pOpdSTeo/lWI11WRgX9cLWwIcGQ+dHR7N0gALPqOc1sWQk IOPqHZvahA3zQ4xBxaWoq45w5aqR0s82GN1iesg6IFgzM7JEwo524cuVER5eqV3Hl+ZR gVrQYrAPbDUYflVEyzAX6AERuzCApsDsBSwd6tAGXZsMkzpu/T9AqScYe5zJ2bspc8IW mQ== Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S7000NB6L8ZOR80@rn-mailsvcp-mta-lapp01.rno.apple.com>; Tue, 09 Jan 2024 14:02:59 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0S7000O00L56S800@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 09 Jan 2024 14:02:59 -0800 (PST) X-Va-A: X-Va-T-CD: 8a90716d4ae5659fdb9c0479be8fa08c X-Va-E-CD: be978c52084b6976624ddc06deb6d36d X-Va-R-CD: f705b5fccc3809fe41b6e32e358534d4 X-Va-ID: 575dd53a-48a2-4609-8785-998a9b84afa2 X-Va-CD: 0 X-V-A: X-V-T-CD: 8a90716d4ae5659fdb9c0479be8fa08c X-V-E-CD: be978c52084b6976624ddc06deb6d36d X-V-R-CD: f705b5fccc3809fe41b6e32e358534d4 X-V-ID: 568d4992-b2e7-49b8-b907-9a88404fd940 X-V-CD: 0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2024-01-09_11:2024-01-09, 2024-01-09 signatures=0 Received: from smtpclient.apple ([17.192.171.188]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0S7000G84L8ZQU00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 09 Jan 2024 14:02:59 -0800 (PST) From: Tommy Pauly Message-id: <18707C05-DCA2-49D0-AAE8-6BCCE311A9D5@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_77F5588D-7FD8-4C90-A49B-C156170B582E" MIME-version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Date: Tue, 09 Jan 2024 14:02:54 -0800 In-reply-to: Cc: Marcus Ihlar , "draft-ietf-ippm-responsiveness.authors@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" To: Sebastian Moeller References: <494C914A-D9CC-4822-85D5-63F6DE849E71@gmx.de> X-Mailer: Apple Mail (2.3774.300.61.1.2) Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2024 22:03:09 -0000 --Apple-Mail=_77F5588D-7FD8-4C90-A49B-C156170B582E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Sebastian, Please note that this is a Working Group Last Call, so the call is for = sending up to IETF last call, not for adoption. Thanks for your reviews! Best, Tommy > On Jan 9, 2024, at 9:27=E2=80=AFAM, Sebastian Moeller = wrote: >=20 > Dear Marcus, >=20 > I apologize for forgetting to actually state, that I consider the = draft, well reasoned and written. While I would appreciate discussion of = the points I raised, I think this should be adopted, if need be as is. >=20 > On 9 January 2024 18:14:38 CET, Marcus Ihlar = > wrote: >> Hi Sebastian, >> Since this review was submitted during an ongoing working group last = call, it would be good to understand you support progressing this = document given that you get sufficient answers to your comments and = suggestions. >> Authors, it would be great if you could address the comments of this = review. >>=20 >> BR >> Marcus >>=20 >> -----Original Message----- >> From: ippm On Behalf Of Sebastian Moeller >> Sent: Wednesday, 13 December 2023 21:05 >> To: IETF IPPM WG >> Subject: [ippm] = https://datatracker.ietf.org/doc/html/draft-ietf-ippm-responsiveness-03 >>=20 >> Dear List, >>=20 >> I revisited my assessment of the actual calculation, and think we can = do better (with little effort): >>=20 >>=20 >> "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)) >>=20 >> This responsiveness value presents round-trips per minute (RPM)." >>=20 >> 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 >>=20 >> 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. >>=20 >> 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). >>=20 >>=20 >> I also had a look at the recommendations regarding L4S testing: >>=20 >> "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." >>=20 >> 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). >>=20 >> Regards >> Sebastian >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >=20 > --=20 > Sent from my Android device with K-9 Mail. Please excuse my brevity. >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_77F5588D-7FD8-4C90-A49B-C156170B582E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Sebastian,

Please note that this is a Working Group = Last Call, so the call is for sending up to IETF last call, not for = adoption.

Thanks for your = reviews!

Best,
Tommy

On Jan 9, 2024, at 9:27=E2=80=AFAM, Sebastian Moeller = <moeller0=3D40gmx.de@dmarc.ietf.org> wrote:

Dear Marcus,

I = apologize for forgetting to actually state, that I consider the draft, = well reasoned and written. While I would appreciate discussion of the = points I raised, I think this should be adopted, if need be as = is.

On 9 January 2024 = 18:14:38 CET, Marcus Ihlar <marcus.ihlar=3D40ericsson.com@dmarc.ietf.org> wrote:
Hi Sebastian,
Since this review was submitted = during an ongoing working group last call, it would be good to = understand you support progressing this document given that you get = sufficient answers to your comments and suggestions.
Authors, it = would be great if you could address the comments of this = review.

BR
Marcus

-----Original Message-----
From: = ippm <ippm-bounces@ietf.org> On Behalf Of Sebastian = Moeller
Sent: Wednesday, 13 December 2023 21:05
To: IETF IPPM WG = <ippm@ietf.org>
Subject: [ippm] = https://datatracker.ietf.org/doc/html/draft-ietf-ippm-responsiveness-03
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
= _______________________________________________
ippm mailing = list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

-- 
Sent from my Android device with K-9 Mail. = Please excuse my brevity.

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

= --Apple-Mail=_77F5588D-7FD8-4C90-A49B-C156170B582E--