> On 07 Jan 2015, at 21:34, Bryan Socha <[email protected]> wrote: > > 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.
So the proposal as I understand it has very low limits on the amount of payload that will be sent in the response (4kB, i.e. four packets), which I presume will reduce the temptation to misuse this measurement for bulk transfer capacity estimation (...and please don't get me started on how utterly pointless using a single TCP flow to estimate bulk transfer capacity is in the first place :) ) In the aggregate, though, you're right, this could lead to significant bandwidth usage, which I presume could be capped by the controller...? Cheers, Brian > Bryan Socha > Network Engineer > DigitalOcean > > > On Mon, Jan 5, 2015 at 7:59 AM, Robert Kisteleki <[email protected]> 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 ([email protected]) 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 > >
