On Jan 3, 2020, at 2:13 PM, Wessels, Duane <dwessels@verisign.com> wrote:
On Dec 20, 2019, at 2:49 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
On Dec 20, 2019, at 10:26 AM, Wessels, Duane <dwessels@verisign.com> wrote:
The connectivity diversity text was added because I was concerned that, without it, we might have a situation where a significant number of vantage points are essentially colocated with a significant number of root servers. This would especially impact latency measurements.
If a vantage point and an instance are co-located in a data center (or in topologically adjacent data centers), a connectivity difference will be nearly meaningless unless the connectivity provider makes exceptionally crappy routing choices. Adding 10 or even 50 ms to go out one provider and in the next is swamped by the 250 ms threshold.
--Paul Hoffman
I'm willing to concede that it may be too onerous to have strong expectations of diverse connectivity (per region) and that it might be hard to know which ISPs would be used at a specific location and furthermore to expect that it would remain the same over time. As with many aspects of this work, we are limited by lack of experience at this time. I propose softening the expectations with the following text for section 3.3. Note only the middle paragraph has been changed:
3.3 Connectivity and Other Requirements
Vantage points shall be hosted inside data centers with reliable power and diverse connectivity providers.
The placement of vantage points should be based on the desire to have diverse connectivity providers. Diversity of connectivity providers helps to increase RSS coverage and avoid situations where multiple vantage points all reach the same root server instance.
Vantage points may be deployed on bare metal or virtual machines (VMs). When VMs are utilized, they should provide dedicated IP addresses and a dedicated operating system environment.
This feels good to me. --Paul Hoffman