<div dir="ltr"><div>I love the idea but unless you can profile what available capacity the probe/anchor has I don't think the resulting measurements will be useable.    There is no way to know your http request was slow because someone with the end point is a hard core torrent user maxing their location out.   Also valid for the areas where you have a hard limit and minimal extra bandwidth.    ping/traceroute while not always a good test does squeeze through with minimal variance in result when the site bandwidth is congested.<br><br></div>also as an anchor host, can I limit the max bps because some locations is not low cost if everyone decides to http test some speedtest file.    Our singapore anchor for example would cost more per month then we spent on the hardware to host an anchor in the first place.   I suspect the probe/anchor hosts in other areas like africa, australia, new zealand, and south america would get even larger monthly bills.<br><br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br>Bryan Socha<br>Network Engineer<br>DigitalOcean<br><br></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Jan 5, 2015 at 7:59 AM, Robert Kisteleki <span dir="ltr"><<a href="mailto:robert@ripe.net" target="_blank">robert@ripe.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Dear RIPE Atlas users,<br>
<br>
The topic of publicly available HTTP measurements in RIPE Atlas comes up<br>
from time to time. There were a number of discussions about pros and cons<br>
for this feature over the years (including exposing probe hosts to<br>
unnecessary risks of other users "measuring" just about any kind of HTTP<br>
content out there), with no firm outcome.<br>
<br>
While we understand that this feature would come handy for some of our<br>
users, it does not benefit everyone. Therefore our proposal is the following:<br>
<br>
1. We'll enable HTTP measurements to be performed by all atlas users, from<br>
any probes.<br>
<br>
2. The targets of such measurements can only be RIPE Atlas anchors (these<br>
already run HTTP servers, see <a href="https://atlas.ripe.net/docs/anchors/" target="_blank">https://atlas.ripe.net/docs/anchors/</a>).<br>
<br>
3. Parameters like costs, minimum frequency, maximum number of probes<br>
involved, etc. will be set by the development team, just as with the other<br>
measurements.<br>
<br>
4. The RIPE NCC will still be able to support other, vetted HTTP<br>
measurements as long as it benefits the community, as well as other HTTP<br>
measurements that we deem operationally useful. These will be evaluated on a<br>
case by case basis.<br>
<br>
<br>
Please speak up at the MAT working group list (<a href="mailto:mat-wg@ripe.net">mat-wg@ripe.net</a>) if you<br>
support / don't support this proposal, of if you have any other opinion<br>
about it.<br>
<br>
Regards,<br>
Robert Kisteleki<br>
RIPE NCC R&D manager, for the RIPE Atlas team<br>
<br>
</blockquote></div><br></div>