From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bobcat.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0991E3CB39 for ; Fri, 19 Jan 2024 15:35:19 -0500 (EST) Received: from mail.rjmcmahon.com (bobcat.rjmcmahon.com [45.33.58.123]) by bobcat.rjmcmahon.com (Postfix) with ESMTPA id 422941B280; Fri, 19 Jan 2024 12:35:19 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 bobcat.rjmcmahon.com 422941B280 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjmcmahon.com; s=bobcat; t=1705696519; bh=/0KA6WyHl8FL/Q2EjDXuZkOnxHN9DjeAZhCaj0PToNM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=VcKXaI200CJb0tufNpHOIURYHr3zI1NZPeN7aSdsU75CrIZUORGvBVvXVozGakFgF QgaB7P/JDQsqa+1qdh1LQyau+wRIqSVVe3F24KF0RqKq/aSUy4gMDvPFkNiMIaXTgP svgytL87y2IZIU0rh7/bq1SQVrhWUQNW476QQ+7I= MIME-Version: 1.0 Date: Fri, 19 Jan 2024 12:35:19 -0800 From: rjmcmahon To: Christoph Paasch Cc: Sebastian Moeller , Rpm , IETF IPPM WG In-Reply-To: <628E2A62-5C2F-448A-83B8-08FC4FB57E7C@apple.com> References: <7494CC8D-7BAB-41DB-9FF7-7306747F2DC9@apple.com> <14EC339A-9A84-40C5-AFCC-474DF03C16B6@gmx.de> <628E2A62-5C2F-448A-83B8-08FC4FB57E7C@apple.com> Message-ID: <966b41f794e95ca8675d613ca84d22a8@rjmcmahon.com> X-Sender: rjmcmahon@rjmcmahon.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Fri, 19 Jan 2024 20:35:20 -0000 >> 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 ? > > [SM] Yes in a sense.... but that could be a a small process that > simply updates the content of that file every couple of milliseconds, > so would not strictly need to be the server process... > > Which would kill the in-memory caching the servers do. And some > webserver implementations actually have the ability to generate > “random” data on-the-fly without a backing file behind it (like > “statichit” in ATS > https://docs.trafficserver.apache.org/en/9.0.x/release-notes/whats-new.en.html). > >>> We opted against this because the “power” 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 >>> “POST” 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 “deployability” and >>> “debuggability”. 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 ? >> >> [SM] I really really would like some way to get OWDs if only >> optional, but even more than that I think RPM should get as wide a >> deployment as possible, ubiquity has its own inherent value for >> measurement platforms, so if this makes deployment harder it would >> be a no-go. >> >> Now, I get that this is a long shot, but I fear that if the draft >> does not mention this at all the chance will be gone forever.... >> Could we maybe add a description of an optional 'time' payload, so >> clients could expect a single standardised format for that, if a >> server would optionally support it? > > Well, if we describe the optional ’time’ payload, we also need to > specify how the clients are gonna use it and expose that information. > Meaning also, having some kind of implementation experience with it, > running code, … > I wonder if a solution here is to have a secondary tool that supports OWD in more of a diagnostic manner would be an approach that works. RPM indications are only the beginning to trigger and affect a full diagnostic panel using standard tools that have been statistically vetted and can be trusted as accurate? That's what we'll do in WiFi automation testing, use RPM as a first level test and use more advanced tooling for more complete diagnostics. Bob