From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7753A3B2A4 for ; Sun, 3 Dec 2023 13:13:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1701627228; x=1702232028; i=moeller0@gmx.de; bh=xGSwLtJ15EJ28NxPZbRREXKmjS04tyEJCOhCVyx921c=; h=X-UI-Sender-Class:From:Subject:Date:To; b=neg0jiViPNxMp54rCV/AWa0izd9j17N+dLDt9x8bEcy6VU5ZY5JZNfcVRVnRjWvF pWQ7jyrUPu0DAkHcSDF48k+bdOCezXVC+XEcTtk0VW3SY7WGeZ1l8QkSB04Vx8ZrT Duy5NEWQbUf1UmkRR47MA/j1LWigSq+UP7H4MQjBFgAHRtqcwyTPOEmQ78TIqYO9o 0sBDdZpjdOIGUv/OOSg6olI9jL+xh0eIal0sRJAAvd2myuG0AzEWB5jTeRGADrf95 NPsRvxTCVa2g++tMmSKQwb4tldtZzYyNPZr3c8TDLL+Le8yJ9RcefAbNcZQ857+9n bGOnlTnYt9Rjva/MSg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([77.10.198.105]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MHG8g-1r5VOO0NzE-00DH4R; Sun, 03 Dec 2023 19:13:48 +0100 From: Sebastian Moeller Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Message-Id: Date: Sun, 3 Dec 2023 19:13:47 +0100 To: IETF IPPM WG , Rpm X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:BO7PAH0jzkpTa9I01uK8lb9N5H2D+H9kw0N237f2bsQLcCoNZdg 30B1a1AcOHpx5oOqlFbjLbz4cTLkW1xm1bBFx3ss6a+NBz8UheSbrXUth6f/SDXjDnWE4zI 1ZgHr63WEIu43RG+VMV/MulzG/Jhu1AxAwhib9ZxCifGqQgJ5GryAUKBi5GcXSNOEVxe3KP 6zAmG5+D8CjduO+uu0N5A== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:JzhmKkuHwiw=;/Eqp4o7TuhTSp8zgwkx8HtL75v4 ulmeL42E4f8DXV0Riu1UFpMr3afm+SyFPB9FlMM0rdAjzjoGHFS0w35DUi3fhE323GKQ0WMW+ pX5yFktg3SJSqkJJPiynLHTLb4sa7XFIoF/rFxFUwIpEDnx6ouBjUExvtOx0jP+tsydco+/3d sWO3Autsc8Be7qwvpZOrkTLWfEx+YUVrVaavop5TUFJWLG4YF49TxH3adnIU5+PpkF20Q67MW o6JhDMXazxyESWTpu9/E1kqaZSiqCTjGZbd75I7ayT4hls1IGX4Umr7UKWpVIR16fRmLc3gO6 7/WBKSylBptxSQInlWw3EiIQIKEsNgBb3mpxzI5wb0ONI713HBaTdWTvUbCRqPvyD8RmDWPdA wI9L050TQTg2hCUQzZwXHAQTrPdjLC6WO70ts+EhXrwy7FfATPQLbK4p0cv9j95WyqIX7iDIz MCgUIbPnJHUKnLO/e5VwmyNre0mjNm/zuNU7L9J06Z9xXSZD7csjf7AYKSLH0BZ/WvcnCcK2N EmOElm0MLC1oOkuXrOlYMI37yYzKcACjdqrXqvHG1DwcntpcROLkL/Rl8SwrokE4aJaSG0fky VEZ4OsLI3lsF/wZ3lhBFmlyQPCYpUOq9VWJd9qVp97KZvju+H5Nj+gM3VtKcFvP0WpH18pyrI 6E9DD81lHSbH/Yj4tqBiQ7JoBkhVggH092pd1omWEIo5Q8JsL1+NKwPH5qv08Gg71POPGsuYV utmJv/Dae3WdZgmm06nL7eneaoGyqPRGQ5ikpH7HCt66cgvEM//LerCh3QMWF0kelGi3n+xo9 hNvRpOYYTxuTmBze3NB2z2B1SwzrUPeUGX00gLpzV3WWgPIPrs+ruUKGzxsiY91s+mwBITvXJ pkZ9/iSUJ7qM7ikeFFId2d2HDWQ6/+Zk8vAx1m52qecnxyv2snzfEltg600P3miF6Tz4DAjEB MlXfM48dDyjsPlbFVZccvTtDUkY= Subject: [Rpm] 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: Sun, 03 Dec 2023 18:13:49 -0000 Dear IPPM members, On re-reading the current responsiveness draft I stumbled over the = following section: Parallel vs Sequential Uplink and Downlink 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. One approach could be to measure responsiveness in the uplink and = downlink in parallel. It would allow for a shorter test run-time. However, a number of caveats come with measuring in parallel: =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. 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. 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. 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). Best Regards Sebastian=