This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] Proposal for public HTTP measurements
- Previous message (by thread): [atlas] Proposal for public HTTP measurements
- Next message (by thread): [atlas] [mat-wg] Proposal for public HTTP measurements
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Robert Kisteleki
robert at ripe.net
Fri Jan 9 10:44:34 CET 2015
Dear All, I'd like to provide some background information mostly about bandwidth usage that can help this discussion. For RIPE Atlas anchors, we're always asking the host to be prepared for traffic up to 10Mb/sec. However, in reality we're very far from using this much at the moment: anchors that are involved in DNSMON measurements use about 256kb/sec, whereas anchors that don't do DNSMON measurements use about 50kb/sec. About probes: a v4 only probe uses ~4kb/sec, a v4+v6 probe uses ~7kb/sec. See also: https://atlas.ripe.net/about/faq/#how-much-bandwidth-will-the-probe-consume All of these numbers are on average, based on checking some random anchors/probes. Surely there are probes that use more (or less) average bandwidth than the numbers I mentioned. The HTTP service provided by the anchors limits the response size to about 4KB, so even with all the overhead it fits in a few TCP packets, which is practically in the same ballpark as the other measurements we already allow (or even less, if one thinks about traceroutes...) We'll also enforce the usual limits like maximum number of probes per measurement and minimum measurement frequency. Regards, Robert On 2015-01-07 21:34, Bryan Socha 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. > > > > > Bryan Socha > Network Engineer > DigitalOcean
- Previous message (by thread): [atlas] Proposal for public HTTP measurements
- Next message (by thread): [atlas] [mat-wg] Proposal for public HTTP measurements
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]