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., [email protected] escribió: Send ripe-atlas mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 <[email protected]> To: [email protected] Subject: Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] Message-ID: <[email protected]> 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 <[email protected]> To: "[email protected]" <[email protected]> Subject: [atlas] RIPE Atlas Quarterly Planning Q1 2023 Message-ID: <[email protected]> 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 <[email protected]> To: Magnus Sandberg <[email protected]>, [email protected] Subject: Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] Message-ID: <[email protected]> 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 <[email protected]> To: Robert Kisteleki <[email protected]>, [email protected] Subject: Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] Message-ID: <[email protected]> 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 <[email protected]> To: Robert Kisteleki <[email protected]> Cc: "[email protected]" <[email protected]> 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 > [email protected] > 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/e4c2b03f/attachment-0001.sig> ------------------------------ Message: 6 Date: Fri, 16 Dec 2022 15:34:04 +0100 From: Chris Amin <[email protected]> To: [email protected] Subject: [atlas] New RIPE Atlas stream release Message-ID: <[email protected]> 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 <[email protected]> To: Robert Kisteleki <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP] Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii On Wed, Dec 14, 2022 at 03:02:46PM +0100, Robert Kisteleki <[email protected]> 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 [email protected] https://lists.ripe.net/mailman/listinfo/ripe-atlas ------------------------------ End of ripe-atlas Digest, Vol 136, Issue 15 *******************************************
-- ripe-atlas mailing list [email protected] https://lists.ripe.net/mailman/listinfo/ripe-atlas
