On Aug 25, 2021, at 10:38 AM, Paul Hoffman <paul.hoffman@icann.org> wrote:
On Aug 25, 2021, at 8:53 AM, Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) <kenneth.d.renard.ctr@army.mil> wrote:
Hi, Paul. Thanks for the feedback.
The reasoning behind these latency measurements is to have some context for interpreting latency to root server instances. For example, a slow "last mile" link would likely have effects on both root server and open resolver latencies. The work party decided on using popular open resolvers as a reference latency target since they are a well-deployed service and have similar processing times (non-recursive DB lookup). The exact math for such an analysis is not described in this document, but the reasoning is laid out at the end of section 2.1, under item #4 in the list of "measurements of interest".
If you think that additional text is required, I would be glad to propose something and work with you to address this.
It's not just text: I think additional analysis is needed. In the eventual tool, let's assume that from a particular point a user gets times of 25 ms to Cloudflare, 35 ms to GPDNS, 80 ms to OpenDNS, and 50 ms to Quad9. What value would be used for the "last mile"? The mean of those? The median? Saying "are intended to be aggregated" indicates that we (I think correctly) don't know how to estimate a base latency.
--Paul Hoffman
I don't agree that additional analysis is needed, nor do I think this document needs to specify rules or formulas for calculating last mile latency, at this time. While those things might be really nice to have, I don't think we have the collective will to come to agreement on that in any reasonable amount of time. I think it will have to suffice to leave the interpretation of any reference latency measurements to the party performing the data analysis. Since this is all new we don't have to get it right the first time. If it turns out to be wrong or useless or under-specified then we can revise the document after acquiring some experience. DW