December 2022 - ripe-atlas - mailman.ripe.net

Verdien 3.0.3
by Ernst J. Oud 07 Sep '23

07 Sep '23

Hi, @Chris Amin: Yes, commit c999953, version 3.0.3 completely solves this. My gratitude is larger than the losses Mr. Musk is making now that Twitter is going down the drain :-) Thanks! Regards, Ernst J. Oud

5 4

Requesting Credits for Research
by Alex Gamero-Garrido 29 Jul '23

29 Jul '23

Hi folks, My name is Alexander Gamero-Garrido and I'm a 5th year PhD student at CAIDA, UC San Diego. We're soon launching a large traceroute campaign for research and could use your generous donation of credits. We'll need about 150 million credits, but any partial amount that gets us closer to that goal is welcome and greatly appreciated. My account is agamerog at eng.ucsd.edu Thank you, Alex -- *Alex Gamero-Garrido* *PhD Student, Computer Science* Web: cseweb.ucsd.edu/~agamerog Center for Applied Internet Data Analysis (CAIDA) San Diego Supercomputer Center UC San Diego Pronouns: He/Him/His <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> I'm using Inbox When Ready <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> to protect my focus.

13 15

Probe DHCPv6 support
by Aleksi Pirttimaa 19 May '23

19 May '23

Hi! I recently received my v4 probe and I'm very happy with it. But unfortunately it doesn't support DHCPv6. I present a practical reason for implementing a DHCPv6 client on the probe. You see, my ISP doesn't send router advertisements with the prefix for stateless autoconfiguration set, and instead DHCPv6 must be used. I believe their decision could have something to do with the fact that the regulating body here requires ISP's to prevent IP address spoofing in consumer plans. And to meet that requirement my ISP may be using a feature similar to Cisco's IP source guard, where switch ports and/or mac addresses are passively associated to leased ip's or prefixes, breaking SLAAC. Unfortunately they hate letting consumers talk with their engineers so it's difficult to speculate this further. For now, I've put a stateful firewall appliance in front of the probe which provides SLAAC, it works just fine. Do you think a DHCPv6 client should be implemented?

8 13

Proposal: Remove support for non-public measurements [ONLY-PUBLIC]
by Robert Kisteleki 11 Jan '23

11 Jan '23

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

15 24

V3 Probe: USB Flash Drive Filesystem Corrupted
by ripe.net＠toppas.net 11 Jan '23

11 Jan '23

Hello, i have two v3 probes and i'm experiencing issues: "USB Flash Drive Filesystem Corrupted" I have tried multiple USB Sticks, including brand new ones and also sticks from "good" brands like Lexar and Sandisk. The issue is not permanent, the error appears and disappears from time to time: 2022-12-22 @ 12:14:04 UTC Probe auto-tagged Your probe #xxxxx was automatically tagged as "system: Flash drive filesystem corrupted" 2022-12-22 @ 18:14:42 UTC Probe auto-untagged Your probe #xxxxx was automatically untagged as "system: Flash drive filesystem corrupted" This leads me to the thought, that the flash storage is not the real problem. It's unlikely, since i tried multiple dongles. Could it be possible, that not the flash storage is broken, but the speed of the USB dongles is too low? All dongles I tried were USB 2.0, not 3.0, since the TP-Link TL-MR3020 is not USB 3.0 capable anyway. But maybe USB 3.0 is a better choice? What do you think? BR, Simon

2 6

Proposal: Add support for STARTTLS measurements [STARTTLS]
by Robert Kisteleki 09 Jan '23

09 Jan '23

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

4 3

Re: [atlas] Ability to traceroute to 240/4 - software vs. hardware probes
by Seth David Schoen 09 Jan '23

09 Jan '23

Hi! I noticed that Phillip Homburg merged a RIPE Atlas client patch in November of last year, based on our request, that removes the Atlas probe's inability to test addresses in 0/8 and 240/4. https://github.com/RIPE-NCC/ripe-atlas-probe-measurements/commit/59475f848b… So, I just tried a couple of measurements to 240.1.2.3 to see how Atlas would handle them: https://atlas.ripe.net/measurements/48100582/ https://atlas.ripe.net/measurements/48100585/ (I don't expect these to succeed, as no part of 240/4 is publicly announced in BGP; the interesting information to be garnered from this isn't whether the probes succeed, but how they fail.) For the first measurement, with ping, 6 hardware probes and 4 software probes all gave the same result: "Unreachable" (which is what you would get if you ran this on any ordinary Internet host with command-line ping). For the second measurement, with traceroute, 6 hardware probes all actually attempted the traceroute (getting failures after some small number of network hops), while 3 software probes all reported back "!address not allowed". What could account for the difference in how hardware and software probes handle this task? I would have thought that the change from last November would make software probes willing to attempt these.

2 2

Magellan report on built-in measurement 1
by Ernst J. Oud 09 Jan '23

09 Jan '23

Asked this question before but that post did not make it to the mailing list: Why can’t Magellan report on built-in measurement 1 (first hop)? It always shows “No packets found”. Met vriendelijke groet/Regards, Ernst J. Oud

2 1

Updating software probe version (with .deb package)
by Seth David Schoen 31 Dec '22

31 Dec '22

Hi, I have a software probe which I installed by creating a Debian package from source (as described in INSTALL.rst). The documentation suggests that one should regularly update software probe versions, and I'm interested in upgrading mine -- I was reminded by my earlier question about 240/4, as I may be running a client version from prior to when the patch allowing 240/4 scans was merged. The documentation doesn't specifically mention how to upgrade; can I assume that making a new .deb from current sources, and then installing that with dpkg on a machine where an older .deb is installed, will maintain the credentials and identity of my existing probe? It won't wipe everything out and require me to re-register as a new software probe, right?

2 1

Proposal: Measure well-known CDNs,[CDN-HTTP]
by Robert Kisteleki 30 Dec '22

30 Dec '22

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

8 9

Re: [atlas] DNS issue
by Mezgani Ali 30 Dec '22

30 Dec '22

> Hello, > > > I set my probe and I got a problem with DNS. > > Please what figure out on my probe ? Maybe I have to set other DNS address into my ADSL Router. > > Any query are welcome. Regards, > > > > Mezgani Ali's home > General > <https://atlas.ripe.net/frames/probes/63005/#tab-general>Network > <https://atlas.ripe.net/frames/probes/63005/#tab-network>Built-ins > <https://atlas.ripe.net/frames/probes/63005/#tab-builtins>UDMs > <https://atlas.ripe.net/frames/probes/63005/#tab-udms>Status (beta) > <https://atlas.ripe.net/frames/probes/63005/#tab-status> > General InformationEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/general/> > Id 63005 > MAC Address D8:58:D7:03:02:C0 > Architecture atlas-mox > Firmware Version None > Router Type > Bandwidth Limit Not set > DNS Entry Simple: > p63005.probes.atlas.ripe.net <http://p63005.probes.atlas.ripe.net/> > Shared Publicly Yes > User Tags <https://atlas.ripe.net/docs/getting-started/probe-tags.html#user-tags> Mobile Datacentre IPv6 Tunnel IPv66to4 ADSL VPN Native IPv4 IPv6-onlyDocker > System Tags <https://atlas.ripe.net/docs/getting-started/probe-tags.html#system-tags> V5 DNS problem suspected > <https://atlas.ripe.net/frames/probes/63005/ripestat/9002/> > Connection & Traffic > > > Connected Time 3 months > > Management SharingEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/sharing/> > Currently you're not sharing this probe within your LIR. > > The management of this probe is not allowed for any other individuals. > > NotificationsEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/notifications/> > There aren't any downtime notifications configured for this probe. > There aren't any uptime reports sent for this probe. > Transfer OwnershipEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/transfer/> > You can transfer ownership of the probe to someone else by submitting this form. Note that this change cannot be undone. > > 3 months > #63005 > Firmware > None > Architecture > atlas-mox > MAC Address > D8:58:D7:03:02:C0 > Update Location <https://atlas.ripe.net/frames/probes/63005/location/> > <3939.jpeg><3940.jpeg><3939.jpeg><3940.jpeg><3939.jpeg><3940.jpeg> > <a51052730657106d6f160440dd590bec.png> > + > <https://atlas.ripe.net/probes/63005/#>- > <https://atlas.ripe.net/probes/63005/#>Leaflet <http://leafletjs.com/> | Tiles © Esri > Kind regards, > > Mezgani Ali > ali.mezgani(a)nativelabs.ma <mailto:ali.mezgani@nativelabs.ma> > https://wiki.debian.org/mezgani <https://wiki.debian.org/mezgani> > > ⢀⣴⠾⠻⢶⣦⠀ Active member of IETF, GNU, Debian, FreeBSD and Kernel. > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋⠀ > ⠈⠳⣄⠀ > > > >> On 30/12/2022, at 17:54, Gert Doering <gert(a)space.net <mailto:gert@space.net>> wrote: >> >> Hi, >> >> On Fri, Dec 30, 2022 at 08:42:18AM -0800, Randy Bush wrote: >>> i asked this quietly before, but let me be more direct. >>> >>> how much private data is there actually? what percentage of the stored >>> data is private? >> >> Indeed, this is a good question. If it turns out that there is a lone >> private measurement from me, or "in the sub-percent range", I'm willing >> to let myself be convinced in the name of "make the measurement backend >> more simple = robust"... >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> -- >> ripe-atlas mailing list >> ripe-atlas(a)ripe.net <mailto:ripe-atlas@ripe.net> >> https://lists.ripe.net/mailman/listinfo/ripe-atlas >

1 0

Probe 24434 down but pingable
by Dave 30 Dec '22

30 Dec '22

Hi, One of my probes is pingable but the status is disconnected for over a day. Could it be that it has troubles with DNS over IPv6 and that it is not smart enough to fall back to IPv4? https://atlas.ripe.net/probes/24434/#tab-general Thanks, Dave

3 4

Re: [atlas] A number of built-ins stopped?
by Ernst J. Oud 23 Dec '22

23 Dec '22

L.S. All the probes in NL that I had a look at, in a variety of different ASN’s, have no data available via the Atlas web of via the api (JSON, Magellan) for a.o. built-in measurement 1009 (ping to a.root-servers.net) and several others after December 22nd, around 18:00 hrs. UTC. When I have a look at German probes there is data available. This thus appears to be a problem with all and only Dutch probes’ data. A normal ping via a Windows command line works fine, i.e. a.root-servers.net is reachable. Creating a ping measurement via Magellan to a.root-servers.net using Dutch probes generates results, i.e. the probe infrastructure works but data storage does not, for data from probes in NL. Rather serious problem I guess. No mentioning on status.ripe.net though. Had an email conversation with Robert from the Atlas team today. No solution yet. Regards, Ernst J. Oud Met vriendelijke groet, Ernst J. Oud

2 1

Apologies for OOO reply
by Guy Meyer 23 Dec '22

23 Dec '22

Hi all, As some of you might have seen, something went wrong with my out-of-office email settings, and I'm sorry that you received the email multiple times. We're cleaning up the mailing list, and I wish you all happy holidays and a great year ahead. Kind regards, Guy Meyer

1 0

A number of built-ins stopped?
by Ernst J. Oud 23 Dec '22

23 Dec '22

Hi, Both on the atlas webpages as via the api, data for a number of built-ins stop at December 22th, at around 18:00 UTC for all my probes in 4 different ISP’s, all in NL. For instance measurement 1009, ping to a.root-servers.net stopped at that time while measurement 1010, ping to b.root-servers.net continues normally. Also stopped are: #1017 Ping to ctr-nue13.atlas.ripe.net #1012 Ping to d.root-servers.net #1013 Ping to e.root-servers.net #1015 Ping to h.root-servers.net #1005 Ping to i.root-servers.net Any idea what is causing this? Regards, Ernst J. Oud

1 0

Proposal: Generic HTTP measurements [GENERIC-HTTP]
by Robert Kisteleki 22 Dec '22

22 Dec '22

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

3 2

Low cost, low energy consumption probe
by Ernst J. Oud 21 Dec '22

21 Dec '22

Hi, I have probes running on VMware (CentOS), Ubuntu (native) and on Docker for Windows. These small PC’s consume a lot more than the Ripe supplied HW probes. So I looked for a cheap and *very* low energy alternative. TP-Link sells the WR802N mini travel router for around USD 20 (o.a. on Amazon) that runs the latest version of OpenWRT fine and the Atlas probe SW has been ported to it. With some acrobatics I managed to turn it into an excellent alternative. Runs fine, energy consumption 700 mW (!). The device is as small as the Ripe supplied probe. Since the flash memory of this device is too small for some of the required libraries, the acrobatics involved copying them to RAM and putting links to them in flash. This means that with FTP after a power outage a couple of files need to be copied to the device and that one command must be given after that. There is a more expensive version with a USB port so that a USB stick can be used to store those files. Will investigate that option. If someone here wants a detailed write-up let me know and I will invest the time to write it. Regards, Ernst J. Oud

3 4

Enable/Disable software probe
by Ernst J. Oud 21 Dec '22

21 Dec '22

Hi, Two questions: 1. What would be the best way to temporarily disable (and enable again) a software probe? Is there some command for this besides killing all processes and run the ATLAS script again? Running a probe on CentOS, OpenWRT and Ubuntu 18.04 (all on separate ISP’s). I am currently logging the latency differences between HW and SW probes (both natively and under VMware emulation). Differences appear to be in the 1.5 ms. range. Negligible for my 4G networks but on my fiber line such a difference is more than 30% of the average latency. Will post more results soon. 2. Why can’t Magellan report on the first ping latency to ping.ripe.net? It always reports “No packets found”. All other reports work fine. TIA. Regards, Ernst J. Oud

2 1

Proposal: Measure well-known CDNs,[CDN-HTTP]
by Dirk-Jan van Helmond 20 Dec '22

20 Dec '22

Hi RIPE Atlas users, I stumbled upon this thread and I wanted to chime in. I work for Cloudflare and we of course use a wide set of external visibility and performance management tools to track our visibility. But on occasions I also use the RIPE Atlas network to perform some specific reachability tests. I believe the distribution of probes and the fact that they're als in eyeball ASN is a really valuable factor that RIPE Atlas has. At the moment I'm running into a limitation around HTTP tests. I would like to use the RIPE Atlas network to curl some pages to retrieve and evaluate the HTTP headers. This is currently not possible with Atlas as it is only allowed to probe Anchors for safety reasons, which I fully understand and support (you don't want to turn Atlas into a botnet). The HTTP targets that I would like to probe would be all on our IP space, so I don't see a direct risk from the outbound part of the request. I can see there is some risk with the return part, where the content from an "unknown" system gets returned to a probe in someone's private network, with possible ramifications. So I was pondering about two possible options that can potentially help me, but not risk the Atlas project or demonstrate favoritism towards particular companies. 1) One of the options would be to open up some of our IP space to the probes for HTTP probes. 2) The other option would be for us to host an Anchor and put our CDN in front of it. That way RIPE has complete control over the returned data. I would love to hear the general consensus on such approach and the viability of it Best Regards, -- Dirk-Jan van Helmond On 17/12/2022 00:19, Barry Raveendran Greene wrote: > > >> On Dec 16, 2022, at 23:29, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote: >> >> There is a larger problem here, a more strategic one: such a feature >> would contribute to the centralisation of the Internet, which is >> already too important. Tagging some targets are "important" and >> "worthy of measurements" would mean that we consider some HTTP servers >> to be more useful than others. That would be a bad message from RIPE. > > We’ve come full circle - we started with centralized PTTs - moved to a decentralized ASN/Paul Baran model - now Re-centralized based on marketing domination. > > +1 with Stephane’s observation. The selection of who to measure is a statement. +1 Also, while the data would be useful, I don't think the role of the ripe ncc is to grade commercial services. Let other companies or individual researchers do that. -- Dirk-Jan van Helmond Leader Solutions Engineering EMEA mobile: +31611645622 email: dirkjan(a)cloudflare.com www.cloudflare.com <https://www.cloudflare.com/>

1 0

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] (Robert Kisteleki)
by Renny Leal 16 Dec '22

16 Dec '22

May the non-public measurements cost more in terms of credits or even money to support the infrastructure? El 16 dic. 2022 11:28 a. m., ripe-atlas-request(a)ripe.net escribió: Send ripe-atlas mailing list submissions to ripe-atlas(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.ripe.net/mailman/listinfo/ripe-atlas or, via email, send a message with subject or body 'help' to ripe-atlas-request(a)ripe.net You can reach the person managing the list at ripe-atlas-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ripe-atlas digest..." Today's Topics: 1. Re: Proposal: Remove support for non-public measurements [ONLY-PUBLIC] (Petr ?pa?ek) 2. RIPE Atlas Quarterly Planning Q1 2023 (Robert Kisteleki) 3. Re: Proposal: Remove support for non-public measurements [ONLY-PUBLIC] (Robert Kisteleki) 4. Re: Proposal: Remove support for non-public measurements [ONLY-PUBLIC] (Magnus Sandberg) 5. Re: Proposal: Generic HTTP measurements [GENERIC-HTTP] (Hugo Salgado) 6. New RIPE Atlas stream release (Chris Amin) 7. Re: Proposal: Measure well-known CDNs,[CDN-HTTP] (Stephane Bortzmeyer) ---------------------------------------------------------------------- Message: 1 Date: Fri, 16 Dec 2022 12:21:03 +0100 From: Petr ?pa?ek <pspacek(a)isc.org> To: ripe-atlas(a)ripe.net Subject: Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] Message-ID: <06d70394-ea13-9be7-486e-a9017a77ba39(a)isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed On 15. 12. 22 19:41, Steve Gibbard wrote: > I worry that that would have a ?chilling effect? on use of the service. I hear your concerns, and have a proposal how to quantify this concern: - First, amend the page to say that all the data are public. (Possibly also switch the flag, but that can be a separate step.) - Second, observe what has changed in the usage pattern. - Third, evaluate. That way we don't need to stay in limbo over hypothetical situations but get real data. Side note about usefulness of one-off measurement history: I think it _might_ be is interesting for anyone doing study on any given outage, or even study about optimization practices over time. For example, the DNS community has service called DNSViz which does just one-off measurements, and yet, researchers come and write papers based on data from DNSViz. HTH. -- Petr ?pa?ek ------------------------------ Message: 2 Date: Fri, 16 Dec 2022 12:32:11 +0100 From: Robert Kisteleki <robert(a)ripe.net> To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] RIPE Atlas Quarterly Planning Q1 2023 Message-ID: <d4aacacc-9691-d6f4-3cbb-ae0e9ad2d18f(a)ripe.net> Content-Type: text/plain; charset=UTF-8; format=flowed Dear colleagues, The quarterly plans for RIPE Atlas can now be found at: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas In the last quarter, we worked on several proposals to change the RIPE Atlas behaviour, including implementing general availability of HTTP measurements and removing the ability to schedule ?non-public? measurements. This quarter, we?ll continue with the distribution of the v5 RIPE Atlas hardware probes to hosts, ambassadors and sponsors as well as work on other items proposed by the community. If you have any input on our plans or want to let us know what you would like to see us work on, please let us know. Kind regards, Robert Kisteleki Research and Development Manager RIPE NCC ------------------------------ Message: 3 Date: Fri, 16 Dec 2022 12:56:45 +0100 From: Robert Kisteleki <robert(a)ripe.net> To: Magnus Sandberg <mem(a)fallback.netnod.se>, ripe-atlas(a)ripe.net Subject: Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] Message-ID: <36a79d58-83e1-4e93-a707-aa47a653ac2e(a)ripe.net> Content-Type: text/plain; charset=UTF-8; format=flowed Hi, > The definition of a "small" test could be something like; > - maximum 20 probes > - runs for maximum 60 minutes > - is repeated maximum 10 times > ? (if you run every 300sec you have to limit the endtime to 50 minutes) What would you propose the API to do if this rule is violated? Should it outright refuse the measurement, or should it silently turn on the public flag (silently, because even if we emit a warning, it is probably never seen by a human...)? > With such limits you can troubleshoot things (non-publicly) but you > can't build your monitoring system on top of that. I guess this hinges on what level of support (legal, technical or other) we're aiming for when it comes to others building services on top of RIPE Atlas. Regards, Robert ------------------------------ Message: 4 Date: Fri, 16 Dec 2022 14:13:47 +0100 From: Magnus Sandberg <mem(a)fallback.netnod.se> To: Robert Kisteleki <robert(a)ripe.net>, ripe-atlas(a)ripe.net Subject: Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] Message-ID: <2ed5e29a-9590-f20c-fd6f-f21e58846d40(a)fallback.netnod.se> Content-Type: text/plain; charset=UTF-8; format=flowed On 2022-12-16 at 12:56, Robert Kisteleki wrote: > Hi, > >> The definition of a "small" test could be something like; >> - maximum 20 probes >> - runs for maximum 60 minutes >> - is repeated maximum 10 times >> ?? (if you run every 300sec you have to limit the endtime to 50 minutes) > > What would you propose the API to do if this rule is violated? Should it > outright refuse the measurement, or should it silently turn on the > public flag (silently, because even if we emit a warning, it is probably > never seen by a human...)? I think the safest thing would be to refuse with an error message. Just override a setting with just a warning is probably not enough, as you wrote. >> With such limits you can troubleshoot things (non-publicly) but you >> can't build your monitoring system on top of that. > > I guess this hinges on what level of support (legal, technical or other) > we're aiming for when it comes to others building services on top of > RIPE Atlas. I really love RIPE Atlas and all the possibilities that come with an open and mature platform. I think as much as possible should be open and reusable by others. However, I understand that some people in some cases have other wishes. Regards, // mem ------------------------------ Message: 5 Date: Fri, 16 Dec 2022 10:15:09 -0300 From: Hugo Salgado <hsalgado(a)nic.cl> To: Robert Kisteleki <robert(a)ripe.net> Cc: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: Re: [atlas] Proposal: Generic HTTP measurements [GENERIC-HTTP] Message-ID: <Y5xvXQ1ICmRBpPEv@pepino> Content-Type: text/plain; charset="us-ascii" Dear Robert, As I have expressed at other times, I think we have to be very careful with enabling HTTP probes due to traffic increase issues. I have personally delivered quite a few probes to remote locations in regions with very poor connectivity, and the host's first concern is how much bandwidth the measurements take up. I have always reassured them that these are only network level connectivity measurements, and no web traffic. It seems to me that in the first world it may be difficult to imagine places where a few megabytes per month of traffic matters, but that is the case in remote regions, and I think the benefit of having an Atlas network with worldwide coverage is greater than being able to perform higher layer measurements or monitoring. It seems to me that the idea of making it "opt-in" with a tag on the probe is the right one, even if it makes its deployment and usability slow at first. I sincerely believe we have a responsibility to hosts that currently help in complex regions. Thanks and regards, Hugo Salgado NIC Chile - .CL On 15:03 14/12, Robert Kisteleki wrote: > Dear RIPE Atlas users, > > We recently published a RIPE Labs article containing a few proposals: > https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. > We'd like to encourage you to express your comments about this proposal (if > you'd like to share them) here. > > Regards, > Robert Kisteleki > For the RIPE Atlas team > > -- > ripe-atlas mailing list > ripe-atlas(a)ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20221216/e…> ------------------------------ Message: 6 Date: Fri, 16 Dec 2022 15:34:04 +0100 From: Chris Amin <camin(a)ripe.net> To: ripe-atlas(a)ripe.net Subject: [atlas] New RIPE Atlas stream release Message-ID: <d278c506-e467-5f3f-040b-296efd878b05(a)ripe.net> Content-Type: text/plain; charset=UTF-8; format=flowed Dear colleagues, The new version of the RIPE Atlas streaming API is now available. As mentioned in the previous e-mail, the API can now be accessed using either plain WebSockets or plain GET requests. Socket.IO support is being maintained for now, so you don't have to immediately change your installations, but the new interfaces should be preferred wherever possible. The documentation can be found at: https://atlas.ripe.net/docs/apis/streaming-api/ Kind regards, Chris Amin RIPE NCC On 30/11/2022 10:31, Chris Amin wrote: > In around three weeks we will be releasing a new version of the RIPE > Atlas stream (https://atlas-stream.ripe.net) with an API based on > WebSockets and plain HTTP requests. > > The current Socket.IO interface will be maintained for backwards > compatibility for the near future, but some subscription parameters will > be dropped due to extremely low or no usage. These are: > > * Historic playback (startTime, endTime) ? note that this does not > include sendBacklog, which will still work as now > * Arbitrary server-side filtering of fields (equalsTo, greaterThan, > lessThan) ? note that filtering by "prb", "msm", "type" etc will work as > now > > We can see from the service logs that each of these parameters has > either not been used at all or used by a single IP address in the past > month, so the impact should be minimal. However, if you happen to be > using one of these parameters then please get in touch with me. > > Aside from these changes, existing use cases should continue to work as > they do now, and we will be monitoring closely for any issues. > > There will be more information on the new API, including complete > documentation, closer to the time. ------------------------------ Message: 7 Date: Fri, 16 Dec 2022 16:28:07 +0100 From: Stephane Bortzmeyer <bortzmeyer(a)nic.fr> To: Robert Kisteleki <robert(a)ripe.net> Cc: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: Re: [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP] Message-ID: <Y5yOh9hvnmGG0PCV(a)nic.fr> Content-Type: text/plain; charset=us-ascii On Wed, Dec 14, 2022 at 03:02:46PM +0100, Robert Kisteleki <robert(a)ripe.net> wrote a message of 15 lines which said: > We recently published a RIPE Labs article containing a few proposals: > https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. > We'd like to encourage you to express your comments about this proposal (if > you'd like to share them) here. (In the Cons) "Possible arguments about which provider to include in this set and which to refuse." There is a larger problem here, a more strategic one: such a feature would contribute to the centralisation of the Internet, which is already too important. Tagging some targets are "important" and "worthy of measurements" would mean that we consider some HTTP servers to be more useful than others. That would be a bad message from RIPE. ------------------------------ Subject: Digest Footer -- ripe-atlas mailing list ripe-atlas(a)ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas ------------------------------ End of ripe-atlas Digest, Vol 136, Issue 15 *******************************************

2 1

Upcoming RIPE Atlas stream release in December
by Chris Amin 16 Dec '22

16 Dec '22

Dear colleagues, In around three weeks we will be releasing a new version of the RIPE Atlas stream (https://atlas-stream.ripe.net) with an API based on WebSockets and plain HTTP requests. The current Socket.IO interface will be maintained for backwards compatibility for the near future, but some subscription parameters will be dropped due to extremely low or no usage. These are: * Historic playback (startTime, endTime) — note that this does not include sendBacklog, which will still work as now * Arbitrary server-side filtering of fields (equalsTo, greaterThan, lessThan) — note that filtering by "prb", "msm", "type" etc will work as now We can see from the service logs that each of these parameters has either not been used at all or used by a single IP address in the past month, so the impact should be minimal. However, if you happen to be using one of these parameters then please get in touch with me. Aside from these changes, existing use cases should continue to work as they do now, and we will be monitoring closely for any issues. There will be more information on the new API, including complete documentation, closer to the time. Kind regards, Chris Amin RIPE NCC

1 1

RIPE Atlas Quarterly Planning Q1 2023
by Robert Kisteleki 16 Dec '22

16 Dec '22

Dear colleagues, The quarterly plans for RIPE Atlas can now be found at: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas In the last quarter, we worked on several proposals to change the RIPE Atlas behaviour, including implementing general availability of HTTP measurements and removing the ability to schedule “non-public” measurements. This quarter, we’ll continue with the distribution of the v5 RIPE Atlas hardware probes to hosts, ambassadors and sponsors as well as work on other items proposed by the community. If you have any input on our plans or want to let us know what you would like to see us work on, please let us know. Kind regards, Robert Kisteleki Research and Development Manager RIPE NCC

1 0

Request for Atlas credits for teaching and research
by Nitinder Mohan 16 Dec '22

16 Dec '22

Dear RIPE Atlas community, I am a postdoctoral researcher in Technical University of Munich, Germany. I am coming to you with a request to transfer some of your surplus Atlas credits to my account nitinder.mohan(a)tum.de if possible. I work on several Internet measurements research problems which rely on Atlas platform for measurements. Additionally, I am also planning to give out a cloud connectivity measurment assignment to my course students to give them hands-on experience with Atlas -- which exceeds my local credit generation rate. Your help will be highly appreciated! Thanks and Regards Nitinder Mohan Technical University Munich (TUM) https://www.nitindermohan.com/

10 11

Re: [atlas] Non-public probes?
by Ernst J. Oud 15 Dec '22

15 Dec '22

Chris, Weird. That probe is on AS15435 (just like me) which is an ISP that not yet offer any ipv6 functionality. So how come ipv4-works is not tagged? But thanks for the clarification that this tag is the reason I can’t add it. I can’t do any ipv6 measurements to try. Regards Ernst J. Oud

1 0

Re: [atlas] Non-public probes?
by Ernst J. Oud 15 Dec '22

15 Dec '22

But what is going on then with: https://atlas.ripe.net/frames/probes/1003690 This probe is within AS15435 and when I list all probes in that AS it is shown, but I cannot add it to a measurement, it is rejected. Using a curl request to: stat.ripe.net/data/atlas-probes/data.json?resouce=15435 shows this probe, with a tag “is_public” : false and I cannot access this probe’s info via the link above, I cannot add it to a measurement and I cannot access any data it collects. How does this rhyme to that non-public “probes are therefore contributing very nearly as much to the network as everybody else”? Regards, Ernst J. Oud

4 4