<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <div dir="auto"> <div>May the non-public measurements cost more in terms of credits or even money to support the infrastructure? <div class="gmail_extra"> <div class="gmail_quote">El 16 dic. 2022 11:28 a. m., ripe-atlas-request@ripe.net escribió: <blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div> <div>Send ripe-atlas mailing list submissions to ripe-atlas@ripe.net To subscribe or unsubscribe via the World Wide Web, visit <a href="https://mailman.ripe.net/">https://mailman.ripe.net/</a> or, via email, send a message with subject or body 'help' to ripe-atlas-request@ripe.net You can reach the person managing the list at ripe-atlas-owner@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@isc.org> To: ripe-atlas@ripe.net Subject: Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] Message-ID: <06d70394-ea13-9be7-486e-a9017a77ba39@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@ripe.net> To: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Subject: [atlas] RIPE Atlas Quarterly Planning Q1 2023 Message-ID: <d4aacacc-9691-d6f4-3cbb-ae0e9ad2d18f@ripe.net> Content-Type: text/plain; charset=UTF-8; format=flowed Dear colleagues, The quarterly plans for RIPE Atlas can now be found at: <a href="https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas">https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas</a> 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@ripe.net> To: Magnus Sandberg <mem@fallback.netnod.se>, ripe-atlas@ripe.net Subject: Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] Message-ID: <36a79d58-83e1-4e93-a707-aa47a653ac2e@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@fallback.netnod.se> To: Robert Kisteleki <robert@ripe.net>, ripe-atlas@ripe.net Subject: Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] Message-ID: <2ed5e29a-9590-f20c-fd6f-f21e58846d40@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@nic.cl> To: Robert Kisteleki <robert@ripe.net> Cc: "ripe-atlas@ripe.net" <ripe-atlas@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: > <a href="https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/"> https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/</a>. > 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@ripe.net > <a href="https://mailman.ripe.net/">https://mailman.ripe.net/</a> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <<a href="/ripe/mail/archives/ripe-atlas/attachments/20221216/e4c2b03f/attachment-0001.sig">/ripe/mail/archives/ripe-atlas/attachments/20221216/e4c2b03f/attachment-0001.sig</a>> ------------------------------ Message: 6 Date: Fri, 16 Dec 2022 15:34:04 +0100 From: Chris Amin <camin@ripe.net> To: ripe-atlas@ripe.net Subject: [atlas] New RIPE Atlas stream release Message-ID: <d278c506-e467-5f3f-040b-296efd878b05@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: <a href="https://atlas.ripe.net/docs/apis/streaming-api/">https://atlas.ripe.net/docs/apis/streaming-api/</a> 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 (<a href="https://atlas-stream.ripe.net">https://atlas-stream.ripe.net</a>) 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@nic.fr> To: Robert Kisteleki <robert@ripe.net> Cc: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Subject: Re: [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP] Message-ID: <Y5yOh9hvnmGG0PCV@nic.fr> Content-Type: text/plain; charset=us-ascii On Wed, Dec 14, 2022 at 03:02:46PM +0100, Robert Kisteleki <robert@ripe.net> wrote a message of 15 lines which said: > We recently published a RIPE Labs article containing a few proposals: > <a href="https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/"> https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/</a>. > 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@ripe.net <a href="https://mailman.ripe.net/">https://mailman.ripe.net/</a> ------------------------------ End of ripe-atlas Digest, Vol 136, Issue 15 ******************************************* </div> </div> </blockquote> </div> </div> </div> </div> </body> </html>