Metrics vantage point connectivity
Greetings again. The current text on vantage point connectivity says:
3.3 Connectivity and Other Requirements
Vantage points shall be hosted inside data centers with reliable power and diverse connectivity providers.
Vantage points within the same geographic region should use different connectivity providers if at all possible. E.g., VP#1 uses ISP#1, VP#2 uses ISP#2, etc. 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.
In essence, the text in the second paragraph requires that every vantage point allow provisioning of the connectivity provider. It basically restricts the kind of VMs that could be used, since none of the widely-used VM providers I have found allow for such provisioning. In fact, it kinda pushes the vantage points to be on bare metal, since those rentals are more likely to allow such provisioning. Given that the regions are quite large and so the cities could be quite far from each other, it is not clear how much advantage (if any) this restriction would have. It is also not clear why the diversity is given just for within a region. Separately, the text "E.g., VP#1 uses ISP#1, VP#2 uses ISP#2, etc." is not terribly grammatical. It also uses "ISP" instead of "connectivity provider". It doesn't add anything to the paragraph, and can safely be removed. If this is really what RSSAC wants, that's fine, but it will place limits on which cities can have vantage points because not all cities have data centers that allow this kind of provisioning. If RSSAC instead wants to give itself more freedom for vantage point placement, maybe just change the second paragraph to: Having diverse connectivity providers for the vantage points helps to increase RSS coverage and avoid situations where multiple vantage points all reach the same root server instance. The network routing used by vantage points is detectable using the measurements described in Section 4.8. If configuring particular vantage points allows selecting a connectivity provider, this can be used to increase the diversity of the measurement system. --Paul Hoffman
Hi Paul, I do not remember why the following requirements have been added. Though, I am reading "should" as non mandatory, so I am find with the text as it is, but I would not object this sentence to be removed either. """ When VMs are utilized, they should provide dedicated IP addresses and a dedicated operating system environment. """ Yours, Daniel On Thu, Dec 19, 2019 at 4:04 PM Paul Hoffman <paul.hoffman@icann.org> wrote:
Greetings again. The current text on vantage point connectivity says:
3.3 Connectivity and Other Requirements
Vantage points shall be hosted inside data centers with reliable power and diverse connectivity providers.
Vantage points within the same geographic region should use different connectivity providers if at all possible. E.g., VP#1 uses ISP#1, VP#2 uses ISP#2, etc. 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.
In essence, the text in the second paragraph requires that every vantage point allow provisioning of the connectivity provider. It basically restricts the kind of VMs that could be used, since none of the widely-used VM providers I have found allow for such provisioning. In fact, it kinda pushes the vantage points to be on bare metal, since those rentals are more likely to allow such provisioning. Given that the regions are quite large and so the cities could be quite far from each other, it is not clear how much advantage (if any) this restriction would have. It is also not clear why the diversity is given just for within a region.
Separately, the text "E.g., VP#1 uses ISP#1, VP#2 uses ISP#2, etc." is not terribly grammatical. It also uses "ISP" instead of "connectivity provider". It doesn't add anything to the paragraph, and can safely be removed.
If this is really what RSSAC wants, that's fine, but it will place limits on which cities can have vantage points because not all cities have data centers that allow this kind of provisioning. If RSSAC instead wants to give itself more freedom for vantage point placement, maybe just change the second paragraph to:
Having diverse connectivity providers for the vantage points helps to increase RSS coverage and avoid situations where multiple vantage points all reach the same root server instance. The network routing used by vantage points is detectable using the measurements described in Section 4.8. If configuring particular vantage points allows selecting a connectivity provider, this can be used to increase the diversity of the measurement system.
--Paul Hoffman_______________________________________________ rssac-caucus mailing list rssac-caucus@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.
-- Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160
On Dec 19, 2019, at 6:21 PM, Daniel Migault <mglt.biz@gmail.com> wrote:
Hi Paul,
I do not remember why the following requirements have been added. Though, I am reading "should" as non mandatory, so I am find with the text as it is, but I would not object this sentence to be removed either.
""" When VMs are utilized, they should provide dedicated IP addresses and a dedicated operating system environment. """
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. DW
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
Hi Paul and Duane, My impression is that colocation of the vantage points and the root servers in a data center is a corner case the vantage point operator will have to address. I am not sure it is necessary we indicate how this should be treated here, and simply raising this might be sufficient - without going into the solution space. I am not able to say whether these measurements are representative or not and also suspect it depends on the other vantage points. I would propose maybe something around the following lines. OLD: """ 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. """ NEW: """ Measurement that result from a colocation of vantage points and root servers in a data center needs to be appropriately treated in order to make the measurement representative. """ Yours, Daniel On Fri, Dec 20, 2019 at 5:50 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_______________________________________________ rssac-caucus mailing list rssac-caucus@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.
-- Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160
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. DW
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
On Dec 19, 2019, at 1:04 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
Greetings again. The current text on vantage point connectivity says:
3.3 Connectivity and Other Requirements
Vantage points shall be hosted inside data centers with reliable power and diverse connectivity providers.
Vantage points within the same geographic region should use different connectivity providers if at all possible. E.g., VP#1 uses ISP#1, VP#2 uses ISP#2, etc. 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.
Hi Paul, thanks for the comments.
In essence, the text in the second paragraph requires that every vantage point allow provisioning of the connectivity provider.
I don't see it as a strict requirement. It says "should" and "if at all possible." If the "if at all possible" part makes the statement too strong then its okay with me to remove it.
It basically restricts the kind of VMs that could be used, since none of the widely-used VM providers I have found allow for such provisioning. In fact, it kinda pushes the vantage points to be on bare metal, since those rentals are more likely to allow such provisioning.
If bare metal gives us better connectivity diversity then I think thats the right way to go.
Given that the regions are quite large and so the cities could be quite far from each other, it is not clear how much advantage (if any) this restriction would have. It is also not clear why the diversity is given just for within a region.
Diversity within a region seems like a reasonable compromise to me, rather than specifying global diversity, which would be harder.
Separately, the text "E.g., VP#1 uses ISP#1, VP#2 uses ISP#2, etc." is not terribly grammatical. It also uses "ISP" instead of "connectivity provider". It doesn't add anything to the paragraph, and can safely be removed.
Agreed its not good grammar. I'm okay with removing it or improving its grammar.
If this is really what RSSAC wants, that's fine, but it will place limits on which cities can have vantage points because not all cities have data centers that allow this kind of provisioning. If RSSAC instead wants to give itself more freedom for vantage point placement, maybe just change the second paragraph to:
Having diverse connectivity providers for the vantage points helps to increase RSS coverage and avoid situations where multiple vantage points all reach the same root server instance. The network routing used by vantage points is detectable using the measurements described in Section 4.8. If configuring particular vantage points allows selecting a connectivity provider, this can be used to increase the diversity of the measurement system.
IMO, at this point, RSSAC should say how it would like the system to work. i.e., that connectivity diversity is a design goal. I like the first part of your paragraph but I don't like that the latter part prioritizes VM selection over connectivity diversity. DW
On Dec 20, 2019, at 10:22 AM, Wessels, Duane <dwessels@verisign.com> wrote:
In essence, the text in the second paragraph requires that every vantage point allow provisioning of the connectivity provider.
I don't see it as a strict requirement. It says "should" and "if at all possible." If the "if at all possible" part makes the statement too strong then its okay with me to remove it.
That would be good. The "should" seems sufficient: if there are multiple choices in a location, pick one that gives better diversity across the set of vantage points.
IMO, at this point, RSSAC should say how it would like the system to work. i.e., that connectivity diversity is a design goal. I like the first part of your paragraph but I don't like that the latter part prioritizes VM selection over connectivity diversity.
Understood, and agree that RSSAC should give its priorities. I figured that the "data centers in different cities" was top priority and, once you had that, connectivity providers would not add much diversity. The couple of very low numbers we have seen so far are likely to be because the vantage point and the instance are in the same data center, so using different providers would only increase the latency by a few milliseconds if at all. --Paul Hoffman
IMO, at this point, RSSAC should say how it would like the system to work. ... Understood, and agree that RSSAC should give its priorities.
IMHO (with no hats), I think one of the goals should be to design the requirements based on what the community, not RSSAC, thinks is the right measurement. The point of this effort is drive a community consensus on what "we" (the ICANN community) thinks is the best set of metrics for monitoring the expectations of the RSOs and the RSS. -- Wes Hardaker USC/ISI
participants (4)
-
Daniel Migault -
Paul Hoffman -
Wes Hardaker -
Wessels, Duane