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.

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.




Bryan Socha
Network Engineer
DigitalOcean


On Mon, Jan 5, 2015 at 7:59 AM, Robert Kisteleki <robert@ripe.net> wrote:

Dear RIPE Atlas users,

The topic of publicly available HTTP measurements in RIPE Atlas comes up
from time to time. There were a number of discussions about pros and cons
for this feature over the years (including exposing probe hosts to
unnecessary risks of other users "measuring" just about any kind of HTTP
content out there), with no firm outcome.

While we understand that this feature would come handy for some of our
users, it does not benefit everyone. Therefore our proposal is the following:

1. We'll enable HTTP measurements to be performed by all atlas users, from
any probes.

2. The targets of such measurements can only be RIPE Atlas anchors (these
already run HTTP servers, see https://atlas.ripe.net/docs/anchors/).

3. Parameters like costs, minimum frequency, maximum number of probes
involved, etc. will be set by the development team, just as with the other
measurements.

4. The RIPE NCC will still be able to support other, vetted HTTP
measurements as long as it benefits the community, as well as other HTTP
measurements that we deem operationally useful. These will be evaluated on a
case by case basis.


Please speak up at the MAT working group list (mat-wg@ripe.net) if you
support / don't support this proposal, of if you have any other opinion
about it.

Regards,
Robert Kisteleki
RIPE NCC R&D manager, for the RIPE Atlas team