[RSSAC Caucus] [Ext] [Non-DoD Source] Re: FOR REVIEW: Requirements for Measurements of the Local Perspective on the Root Server System

[Warren Kumari]

On Fri, Aug 27, 2021 at 3:20 PM Paul Hoffman <paul.hoffman at icann.org> wrote:

> On Aug 26, 2021, at 4:07 PM, Wessels, Duane <dwessels at verisign.com> wrote:
> >
> >
> >
> >> On Aug 25, 2021, at 10:38 AM, Paul Hoffman <paul.hoffman at icann.org>
> wrote:
> >>
> >> On Aug 25, 2021, at 8:53 AM, Renard, Kenneth D CTR USARMY DEVCOM ARL
> (USA) <kenneth.d.renard.ctr at 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.
>
> Given this, having the document say "the interpretation of any reference
> latency measurements is left to the party performing the data analysis"
> would help clarify the lack of specificity about how the analysis would be
> done.
>

Huh. That's a good point[0], and something which we should add. What's the
process to add something like that at this point? It seems obvious and not
controversial, so...

W


> --Paul Hoffman_______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.



-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/rssac-caucus/attachments/20210827/cf125a17/attachment.html>