From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ma-mailsvcp-mx-lapp01.apple.com (ma-mailsvcp-mx-lapp01.apple.com [17.32.222.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C11983B29D for ; Tue, 16 Jan 2024 14:01:25 -0500 (EST) Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma-mailsvcp-mx-lapp01.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S7D00CY4BHMTX30@ma-mailsvcp-mx-lapp01.apple.com> for rpm@lists.bufferbloat.net; Tue, 16 Jan 2024 11:01:25 -0800 (PST) X-Proofpoint-ORIG-GUID: CDR1lOF9NsRh1lk4SxZ-sllUL30SHJA2 X-Proofpoint-GUID: CDR1lOF9NsRh1lk4SxZ-sllUL30SHJA2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2024-01-16_11:2024-01-15, 2024-01-16 signatures=0 X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 spamscore=0 bulkscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2401160150 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=wlZ9SUfpq2IXVtLafUFrI298l9tzQ0ePjkh8pKPZaD8=; b=NbzdIHyppnCkCu8LcC1QOA3cNaqKj3DddKpDyfXdcHgPwIys3rnZensMSZ2sUbFUu0Mb z/lZSJ2GF/CySq6JHlEFfIqEqZ3kWPCr+wnV1JdHPZeFeUBj9lBbGTwLWJ82wbbXTKFv h7Fxh1lB3fZNAJYGZkkT5R63GCFceTbsown/czzSFUFlRaXmkas0eNIh3gxJsTQxvYTm 7WOvUeZWWJgY0YKLFalYcQ0f50S+dDDp6kF62TWpiKXBtjS2e1j6YG8N+3XI8HHk62rf e/VUCk8iHc4RuX2NhyjUO/9oVUyCGxvUy3zvbz5kB1YdK/OtkNervgZhXYAoc0/f/bLh GA== Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) 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 <0S7D00NO4BI7F610@rn-mailsvcp-mta-lapp01.rno.apple.com>; Tue, 16 Jan 2024 11:01:19 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0S7D00900BH0SY00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Tue, 16 Jan 2024 11:01:19 -0800 (PST) X-Va-A: X-Va-T-CD: 0af778c0afa90afa8c4c05937d25c782 X-Va-E-CD: c271acf190fbf832db5ab77cfa01cf54 X-Va-R-CD: 13f3c1abb006b363887502e732d00f42 X-Va-ID: d4aca382-bccc-4b14-ae63-52db5191a4dd X-Va-CD: 0 X-V-A: X-V-T-CD: 0af778c0afa90afa8c4c05937d25c782 X-V-E-CD: c271acf190fbf832db5ab77cfa01cf54 X-V-R-CD: 13f3c1abb006b363887502e732d00f42 X-V-ID: 9c2ef190-b816-4646-b8b0-642f7ceee23b X-V-CD: 0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2024-01-16_11:2024-01-15, 2024-01-16 signatures=0 Received: from smtpclient.apple ([17.192.155.119]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0S7D006LFBI78A00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Tue, 16 Jan 2024 11:01:19 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) From: Christoph Paasch In-reply-to: Date: Tue, 16 Jan 2024 11:01:08 -0800 Cc: IETF IPPM WG , Rpm Content-transfer-encoding: quoted-printable Message-id: <7494CC8D-7BAB-41DB-9FF7-7306747F2DC9@apple.com> References: To: Sebastian Moeller X-Mailer: Apple Mail (2.3774.300.61.1.2) Subject: Re: [Rpm] [ippm] draft-ietf-ippm-responsiveness X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2024 19:01:25 -0000 Hello Sebastian, thanks for the feedback, please see inline! > On Dec 3, 2023, at 10:13=E2=80=AFAM, Sebastian Moeller = wrote: >=20 > Dear IPPM members, >=20 > On re-reading the current responsiveness draft I stumbled over the = following section: >=20 >=20 > Parallel vs Sequential Uplink and Downlink >=20 > Poor responsiveness can be caused by queues in either (or both) the = upstream and the downstream direction. Furthermore, both paths may = differ significantly due to access link conditions (e.g., 5G downstream = and LTE upstream) or routing changes within the ISPs. To measure = responsiveness under working conditions, the algorithm must explore both = directions. >=20 > One approach could be to measure responsiveness in the uplink and = downlink in parallel. It would allow for a shorter test run-time. >=20 > However, a number of caveats come with measuring in parallel: >=20 > =E2=80=A2 Half-duplex links may not permit simultaneous uplink = and downlink traffic. This restriction means the test might not reach = the path's capacity in both directions at once and thus not expose all = the potential sources of low responsiveness. > =E2=80=A2 Debuggability of the results becomes harder: During = parallel measurement it is impossible to differentiate whether the = observed latency happens in the uplink or the downlink direction. > Thus, we recommend testing uplink and downlink sequentially. Parallel = testing is considered a future extension. >=20 >=20 > I argue, that this is not the correct diagnosis and hence not the = correct decision. > For half-duplex links the given argument is not incorrect, but = incomplete, as it is quite likely that when forced to multiplex more = bi-directional traffic (all TCP testing is bi-directional, so we only = argue about the amount of reverse traffic, not whether it exist, and = even if we would switch to QUIC/UDP we would still need a feed-back = channel) we will se different "potential sources of low responsiveness" = so ignoring any of the two seems ill advised. You are saying that parallel bi-directional traffic exposes different = sources of responsiveness issues than uni-directional traffic (up and = down) ? What kind of different sources would that expose ? Can you give = some examples and maybe a suggestion on how to word things ? > Debuggability is not "rocket science" either, all one needs is a three = value timestamp format (similar to what NTP uses) and one can, even = without synchronized clocks! establish baseline OWDs and then under = bi-directional load one can see which of these unloaded OWDs actually = increases, so I argue that "it is impossible to differentiate whether = the observed latency happens in the uplink or the downlink direction" is = simply an incorrect assertion... (and we are actually doing this = successfully in the existing internet as part of the cake-autorate = project [h++ps://github.com/lynxthecat/cake-autorate/tree/master] = already, based on ICMP timestamps). The relevant observation here is = that we are not necessarily interested in veridical OWDs under idle = conditions, but we want to see which OWD(s) increase during = working-conditions, and that works with desynchronized clocks and is = also robust against slow clock drift. Unfortunately, this would require for the server to add timestamps to = the HTTP-response, right ? We opted against this because the =E2=80=9Cpower=E2=80=9D of the = responsiveness methodology is that it is extremely lightweight on the = server-side. And with lightweight I mean not only from an = implementation/CPU perspective but also from a deployment perspective. = All one needs to do on the server in order to provide a = responsiveness-measurement-endpoint is to host 2 files (one very large = one and a very small one) and provide an endpoint to =E2=80=9CPOST=E2=80=9D= data to. All of these are standard capabilities in every webserver that = can easily be configured. And we have seen a rise of endpoints showing = up thanks to the simplicity to deploy it. So, it is IMO a balance between =E2=80=9Cdeployability=E2=80=9D and = =E2=80=9Cdebuggability=E2=80=9D. The responsiveness test is clearly = aiming towards being deployable and accessible. Thus I think we would = prefer keeping things on the server-side simple. Thoughts ? That being said, I=E2=80=99m not entirely opposed to recommending the = parallel mode as well. The interesting bit about the parallel mode is = not so much the responsiveness measurement but rather the capacity = measurement. Because, surprisingly many modems/=E2=80=A6 that are = supposedly (according to their spec-sheet) able to handle 1 Gbps = full-duplex suddenly show their weakness and are no more able to handle = line-rate. So, it is more about capacity than responsiveness IMO. However, as a frequent user of the networkQuality-tool I realize myself = that whenever I want to test my network I end up using a sequential test = in favor of the parallel test. Christoph >=20 > Given these observations, I ask that we change this design parameter = to default requiring both measurement modes and defaulting to parallel = testing (or randomly select between both modes, but report which it = choose). >=20 > Best Regards > Sebastian > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm