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

[Dessalegn Yehuala]

I don't see the importance of putting any specific statement on how the
analysis should be done. It can only be known at the time of doing
exploratory analysis of the data.Any suggestion on how the data analysis
should be done needs to be informed at least by conducting exploratory
analysis on historical data.

Dessalegn

On Fri, Aug 27, 2021 at 10:25 PM Warren Kumari <warren at kumari.net> wrote:

>
>
> 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
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/rssac-caucus/attachments/20210828/b2089a7d/attachment.html>