Re: [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP]

[Massimo Candela]

On 17/12/2022 00:19, Barry Raveendran Greene wrote:




On Dec 16, 2022, at 23:29, Stephane Bortzmeyer  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.


--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP]

[Barry Raveendran Greene]

> On Dec 16, 2022, at 23:29, Stephane Bortzmeyer  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. 



-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Randy Bush]

i do not understand the big fuss here.  so a teensie fraction of probes
are not public.  big deal.

some weeks we seem to want to be maxed out regulators and keepers of the
total moral truth.  the net is complex and rich.  this is a good thing.

randy

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Daniel Suchy via ripe-atlas]

Hello,
I support Gert here, network operators (LIRs) can have valid reasons to 
make some their measurements non-public. So I don't support removal of 
this feature. It's a bad idea...


If some probe host has problem with that, why don't mark such probes as 
not-available for private measurements (this can be implemented easily)? 
And I think there will be only minority of probes marked like that. 
Majority of hosts will not care at all...


And keep in mind that Atlas is funded by LIRs and their money. All the 
big-data infrastructure (and also making of hardware probes) costs real 
(and not small) money. Existence of rivate measurements might be one 
reason, why LIRs allow spending money for this useful project. Probe 
hosting is only small piece in expenses within this project...


- Daniel

On 12/16/22 19:13, Gert Doering wrote:

Hi,

On Thu, Dec 15, 2022 at 10:41:42AM -0800, Steve Gibbard wrote:

Atlas, and the RIPE NCC, have two fairly separate constituencies:  researchers 
and operators.


This.

Operators (like me) are willing to host Atlas anchors and probes, and
thus contribute to the system.

I might be troubleshooting something in our network where I have no
interest in making the results public.  So I value the option to have
non-public measurements.

There's no "right to see all measurements" here - if someone wants to
see something, they are free to run their own measurements with their
own credits.  What I do with my credits (which do not come for free)
and who can see the results should be my decision.

Gert Doering
 -- NetMaster




--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Taavi Eomäe]

> RIPE Atlas is primarily designed for INTERnet measurements, not Intranet.

Emphasize on the "primarily", that doesn't directly mean private
measurements shouldn't exist.

> If one has a problem with open-data philosophy, he shouldn't participate
in this project.

The existence of a token system already incentivizes contributing, without
just making good public measurements that contribute back open data.

> It shouldn't be necessary to run the same measurement multiple times. For
what reason?

Because things change in the wild?

> There's only one exception

Well... So in addition to lack of a good basis in principle, non-private
measurements might also pose an unnecessary additional information leakage.
In addition to that, many measurements are just absolutely useless for
others.

I am also certain there are people who only contribute (by hosting a probe)
for that reason - running a few private measurements.
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] (Robert Kisteleki)

[Gert Doering]

Hi,

On Fri, Dec 16, 2022 at 07:13:15PM +, Renny Leal wrote:
> May the non-public measurements cost more in terms of credits or even money 
> to support the infrastructure?

To be able to run "non-public measurements", people need to have earned
the credits beforehand - those do not fall from the sky.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Gert Doering]

Hi,

On Fri, Dec 16, 2022 at 08:07:14PM +0100, ripe@toppas.net wrote:
> Sorry Gert, but i strongly disagree.
> 
> > I might be troubleshooting something in our network where I have no 
> > interest in making the results public.
> RIPE Atlas is primarily designed for INTERnet measurements, not Intranet. To 
> see, how things look like from other networks. If you want to troubleshoot 
> something inside your own network and need privacy, you can do it the classic 
> way, by using your internal test-equipment or monitoring.

I am an ISP.  So I *must* see how things look like from the outside - 
but in case I've done stupid things to my own networks before, I might
not want the world to see that.

> > There's no "right to see all measurements" here
> I highly appreciate RIPE NCCs efforts for maximum transparency and open-data, 
> and i hope this will never change. This is what Atlas was intended to be (as 
> far as i can tell).

All my probes do public and open measurements "for everyone", and they
are happy to do measurements for you.  And I'm happy to bear the costs
for that (an Atlas Anchor costs real money).

> > if someone wants to see something, they are free to run their own 
> > measurements with their own credits.
> In this point, i disagree as well. It shouldn't be necessary to run the same 
> measurement multiple times. For what reason? It would be a waste of credits, 
> time and ressources. Also, keep in mind that this redundant data has to be 
> stored somewhere.

You wouldn't run the same measurements that I want to do, if I have to
do some troubleshooting.

> If one has a problem with open-data philosophy, he shouldn't participate in 
> this project.

> _There's only one exception_ i could agree with: measurements can be private, 
> if you only deploy your own probes/anchors for that measurement. But if you 
> decide to use other peoples probes, the results should be public.

This is a valid opinion for a network researcher, I guess.

For those that actually run the show here, we might see things in a
different light...  (as I'm not the only one explaining the desire for
private measurements).

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] (Robert Kisteleki)

[Renny Leal]

.@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 
To: Robert Kisteleki 
Cc: "ripe-atlas@ripe.net" 
Subject: Re: [atlas] Proposal: Generic HTTP measurements
[GENERIC-HTTP]
Message-ID: 
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@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/e4c2b03f/attachment-0001.sig>

--

Message: 6
Date: Fri, 16 Dec 2022 15:34:04 +0100
From: Chris Amin 
To: ripe-atlas@ripe.net
Subject: [atlas] New RIPE Atlas stream release
Message-ID: 
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) 

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[ripe . net]

Sorry Gert, but i strongly disagree.


I might be troubleshooting something in our network where I have no interest in 
making the results public.

RIPE Atlas is primarily designed for INTERnet measurements, not Intranet. To 
see, how things look like from other networks. If you want to troubleshoot 
something inside your own network and need privacy, you can do it the classic 
way, by using your internal test-equipment or monitoring.


There's no "right to see all measurements" here

I highly appreciate RIPE NCCs efforts for maximum transparency and open-data, 
and i hope this will never change. This is what Atlas was intended to be (as 
far as i can tell).


if someone wants to see something, they are free to run their own measurements 
with their own credits.

In this point, i disagree as well. It shouldn't be necessary to run the same 
measurement multiple times. For what reason? It would be a waste of credits, 
time and ressources. Also, keep in mind that this redundant data has to be 
stored somewhere.


If one has a problem with open-data philosophy, he shouldn't participate in 
this project.

_There's only one exception_ i could agree with: measurements can be private, 
if you only deploy your own probes/anchors for that measurement. But if you 
decide to use other peoples probes, the results should be public.

BR,
Simon



On 16.12.22 19:13, Gert Doering wrote:

Hi,

On Thu, Dec 15, 2022 at 10:41:42AM -0800, Steve Gibbard wrote:

Atlas, and the RIPE NCC, have two fairly separate constituencies:  researchers 
and operators.

This.

Operators (like me) are willing to host Atlas anchors and probes, and
thus contribute to the system.

I might be troubleshooting something in our network where I have no
interest in making the results public.  So I value the option to have
non-public measurements.

There's no "right to see all measurements" here - if someone wants to
see something, they are free to run their own measurements with their
own credits.  What I do with my credits (which do not come for free)
and who can see the results should be my decision.

Gert Doering
 -- NetMaster

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Gert Doering]

Hi, 

On Fri, Dec 16, 2022 at 07:13:25PM +0100, Gert Doering wrote:
> There's no "right to see all measurements" here - if someone wants to
> see something, they are free to run their own measurements with their
> own credits.  What I do with my credits (which do not come for free)
> and who can see the results should be my decision.

... I could see a compromise here, making non-public measurements
require more credits, or so...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Gert Doering]

Hi,

On Thu, Dec 15, 2022 at 10:41:42AM -0800, Steve Gibbard wrote:
> Atlas, and the RIPE NCC, have two fairly separate constituencies:  
> researchers and operators.

This.

Operators (like me) are willing to host Atlas anchors and probes, and
thus contribute to the system.

I might be troubleshooting something in our network where I have no
interest in making the results public.  So I value the option to have
non-public measurements.

There's no "right to see all measurements" here - if someone wants to
see something, they are free to run their own measurements with their
own credits.  What I do with my credits (which do not come for free)
and who can see the results should be my decision.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP]

[Stephane Bortzmeyer]

On Wed, Dec 14, 2022 at 03:02:46PM +0100,
 Robert Kisteleki  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.

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

[atlas] New RIPE Atlas stream release

[Chris Amin]

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.


--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Generic HTTP measurements [GENERIC-HTTP]

[Hugo Salgado]

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@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas
> 


signature.asc
Description: PGP signature
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Magnus Sandberg]

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

--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Robert Kisteleki]

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


--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

[atlas] RIPE Atlas Quarterly Planning Q1 2023

[Robert Kisteleki]

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

--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Petr Špaček]

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

--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Robert Kisteleki]

If you can count on one hand the number of users using >90% of the
private measurements over a longer timeframe than two weeks, then I
submit that the choice is clear.


This information is somewhat harder to extract, but we'll try and get 
back to you!


Cheers,
Robert


--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Magnus Sandberg]

Hi,

One idea could be that "small" tests can be non-public but when the 
setup passes some limits it has to be public. I understand your 
/business needs/ contra the public interest.


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)

With such limits you can troubleshoot things (non-publicly) but you 
can't build your monitoring system on top of that.


Regards,
// mem



Den 2022-12-15 kl. 19:41, skrev Steve Gibbard:

The “one specific user” is www.globaltraceroute.com, an Atlas front end I 
created a few years ago that does instant one-off traceroutes, pings, and DNS 
lookups.  It has become a well-used operational troubleshooting tool.  It 
operates as a free service, with operational costs slowly draining the bank 
account of my mostly defunct consulting firm, and Atlas credits coming from a 
couple probes I operate plus some other donors.

What I think is worth considering here:

Atlas, and the RIPE NCC, have two fairly separate constituencies:  researchers 
and operators.

In the research community, there’s an expectation that data be made available 
so that others can review it, judge the validity of research results, do their 
own work based on it, etc.  Atlas, in its native form with long running 
repeatable measurements, gets a lot of research use.  It is useful to have 
those datasets available to the public.

The operations use case for Global Traceroute is different.  It’s generally 
either “I set up a new CDN POP, and want to make sure the networks it’s 
supposed to serve are getting there are on a direct path,” or “some other 
source is telling me my performance is bad from ISP X, and I want to know why.” 
 Instead of calling the other ISP’s NOC or trying to track down a random 
customer to help troubleshoot, they can do a one-off traceroute, see where the 
traffic is going, and hopefully figure out what to adjust or who to talk to to 
fix the situation.

Making those operational troubleshooting results public may not be worthwhile.  
The results themselves, being one-offs, are not something it would be all that 
interesting to track over time.  If anybody does want a one-off traceroute to a 
particular target, they can go get it themselves.  It is pretty obvious who is 
doing the traceroutes.  If there are a bunch of traceroutes to a certain CDN 
operators’ services, they almost always come from that CDN operators’ corporate 
network, so it does show who is concerned about network performance issues in 
certain regions at certain times.  That info might be potentially interesting — 
color for a news story about an outage saying “as the outage unfolded, 
engineers from company X unleashed a series of measurements to see paths into 
their network from region Y.”  Given the fear a lot of companies have about 
releasing internal information to the public, I worry that that would have a 
“chilling effect” on use of the service.

So, I think think Global Traceroute and Atlas are together a useful operational 
tool.  I think it’s made more useful by setting is_public to false in the 
query.  I’d really like to be able to continue proxying non-public one-off 
measurements into Atlas.

Thanks,
Steve


On Dec 14, 2022, at 9:57 PM, Alexander Burke via ripe-atlas 
 wrote:

Hello,

 From the linked page:


A total of 173 users scheduled at least one, 81 users have at least two, one 
specific user scheduled 91.5% of all of these.


That is surprising. What do those numbers look like if you zoom out to the past 
6/12/24 months?

If you can count on one hand the number of users using >90% of the private 
measurements over a longer timeframe than two weeks, then I submit that the choice 
is clear.

Cheers,
Alex

--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas





--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Request for Atlas credits for teaching and research

[Daniel Romero]

Hi Nitinder,

Just  sent 17 million. Have fun with your research!

Best Regards,
Daniel Romero Peña

 

> On 15-12-2022, at 10:29, Nitinder Mohan  wrote:
> 
> 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.mo...@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/ -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net 
> https://lists.ripe.net/mailman/listinfo/ripe-atlas 
> 
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Request for Atlas credits for teaching and research

[Erik-Jan Bos]

Hi Nitinder:

And another 50M sent to you.

Kind regards,
Erik-Jan Bos.


On 16-12-2022 09:37, Magnus Sandberg wrote:

Hi,

50M on the way over.

Regards,
// mem



Den 2022-12-15 kl. 14:29, skrev Nitinder Mohan:

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.mo...@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/






--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Request for Atlas credits for teaching and research

[Magnus Sandberg]

Hi,

50M on the way over.

Regards,
// mem



Den 2022-12-15 kl. 14:29, skrev Nitinder Mohan:

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.mo...@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/




--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas