[atlas] HTTP measurement proposals [CDN-HTTP] [GENERIC-HTTP] [PEERING-HTTP]

Hi Robert, all:

I was considering emailing about the possibility of HTTP measurements to
our PEERING <https://peering.ee.columbia.edu/> testbed when I stumbled on
the five proposals that Robert posted in December.

I want to express my strong support for the two HTTP proposals.
Hourly [CDN-HTTP] would be great (eventually with HTTPS support).

([STARTTLS] also sounds good, but I haven't thought deeply about it,
and [ONLY-PUBLIC] sounds good unless it costs RIPE Atlas support / probe
hosts)

I was wondering about the feasibility of allowing HTTP measurements towards
PEERING experiments (meaning, towards our address space announced from an
experiment via our routers). Is that something that you might be open to
supporting?

This came to mind because we are in the process of onboarding PEERING to
some bring-your-own-prefix services offered by CDNs and cloud providers,
and so an increasing number of PEERING experiments are about content
delivery/cloud hosting, and it would be great if RIPE Atlas could act as
measurement clients to provide widespread vantage points.

One hands-off option that comes to mind is to set them up similar to the
proposal for CDN-HTTP, where probes will regularly fetch an object at a
fixed URL, say http://ripeatlas.ee.columbia.edu/testobject. Normally, that
could resolve to our project webserver, which is hosted in AWS. When an
experiment needs this HTTP capability (all experiments undergo review by at
least 2 people for safety, and we enable only the capabilities they request
and need, following the principle of least privilege), we could instead
redirect it to a PEERING address allocated to the project that would host
the same test object but that would be announced from cloud/CDN/PEERING
sites however the experiment had configured. Alternatively, it could be a
measurement available to approved accounts, and we could pass on which
experiments are approved, or perhaps available to all accounts. We have
fixed address space, if you have a way to whitelist. We maintain our list
of prefixes as RS-PEERING-TESTBED on RIPE's IRR.

I believe Johan recently contacted Kevin Vermeulen about talking to us
about RIPE Atlas in the context of another one of our projects, so possibly
we can have a discussion covering both topics.

Thanks for all your work providing the platform -- it's great!

Ethan

-- 
http://www.columbia.edu/~ebk2141/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20230306/0c506363/attachment.html>