- mat-wg - mailman.ripe.net

RIPE Atlas, RIPEstat and RIS Quarterly Planning Q3 2023
by Robert Kisteleki 28 Jun '23

28 Jun '23

Dear colleagues, The quarterly plans for RIPE Atlas, RIPEstat and RIS can now be found at: https://www.ripe.net/support/documentation/quarterly-planning We hope that by providing these plans, we can better inform the community of the ongoing developments on the tools we operate and get feedback on our work. 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 RIPE NCC

1 0

RIPE86 MAT WG agenda, 2023-05-25 (Thursday)
by Stephen Strowes 25 May '23

25 May '23

Hi folks, This week's MAT WG session will take place on Thursday, 25th of May, starting at 09:00 UTC+2 [07:00 UTC] We received many great submissions! Our current agenda is available at: https://ripe86.ripe.net/programme/meeting-plan/mat-wg/ See you there! -Stephen

2 1

Open House: RIPE IPmap and Infrastructure Geolocation
by Chris Amin 15 May '23

15 May '23

Dear colleagues, This is a reminder that the RIPE NCC Open House: RIPE IPmap and Infrastructure Geolocation is taking place this Friday, 19th May at 09:00 UTC (11:00 CEST). This Open House is for anyone interested in RIPE IPmap, the RIPE NCC's API for getting geolocation data for core Internet infrastructure. It will be a sixty-minute remote session where RIPE NCC staff will share context and information about RIPE IPmap, and invite questions and discussion from the community. Details and free registration can be found at: https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-ri… Kind regards, Chris Amin RIPE NCC

1 0

The Resilience of the Internet in Ukraine - One Year On
by Emile Aben 17 Apr '23

17 Apr '23

Dear Colleagues, A year ago I wrote about the resilience of the Internet in Ukraine a few weeks after the war broke out in the country. In this article I revisit the topic and analyse what has changed after more than a year of war, based on data the RIPE NCC collects through RIPE RIS and RIPE Atlas: https://labs.ripe.net/author/emileaben/the-resilience-of-the-internet-in-uk… kind regards, Emile Aben RIPE NCC

1 0

Contribution submission for MAT WG at RIPE86
by Marco Polverini 10 Apr '23

10 Apr '23

Dear Nina, Massimo and Stephen My name is Marco Polverini, an assistant professor at Sapienza University of Rome. I would like to submit the following proposal to be presented at the next MAT WG. This work has been accepted to be presented at the IEEE NOMS 23 ( https://noms2023.ieee-noms.org/) Attached to this email you can find the original paper (in case you need further details about the topic of the presentation I would like to do). Thanks Marco *Title:* A Digital Twin based Framework to Enable "What-If" Analysis in BGP Optimization *Outline of the speech:* - introduction and motivation: in this talk we aim to introduce a framework for the creation of Digital Twins of Autonomous Systems in order to enable the execution of "what if" analysis in the context of inter domain routing optimization - background on digital twins: this section is to introduce the basic terminology and concepts on Digital Twins - presentation of the proposed framework: in this section we provide an overview of the architecture of the proposed framework and detail the responsibilities of each functional block - proof of concept: a simple proof of concept is presented, with the aim of showing the effectiveness of the proposal - conclusion and future work *Abstract:* Nowadays, inter domain routing optimization is performed based on the so called "Tweak and Pray" approach, which consists in performing changes in the configuration of the BGP protocol without knowing in advance the consequences of such a modification. This is due to the lack of cooperation among Network Operators in the configuration of the BGP to optimize the inter domain routing. Inefficiency in the resource usage, network anomalies and outages are common consequences of wrong configuration changes performed by Network Operators in an attempt to improve the performance of their infrastructures. In this paper we propose a novel framework based on the Digital Twin technology to enable the execution of "what-if" analysis in the context of Traffic Engineering performed by tuning BGP parameters. Such a paradigm shift will allow Network Operators to be aware of the effects of BGP configuration changes before their actual execution. A proof of concept related to the balancing of inbound traffic in an Autonomous System network, based on the use of the AS Path Prepending technique, is realized to validate the feasibility of the proposed approach.

2 1

delegate LIR portal access to specific user for specific resources - was: [address-policy-wg] 2023-02 New Policy Proposal (Minimum Size for IPv4 Temporary Assignments)
by Massimo Candela 07 Apr '23

07 Apr '23

Hi Elvis, On 14/03/2023 08:42, Elvis Daniel Velea wrote: > Hi Massimo, > > thank you for your message. Let me see if I have an answer to some of > your questions/comments. See inline. > > ------- > I also mention below a variation of this proposal, which could be it's > own proposal/thread (suggestions welcome): > > There should be an easy way to do "temporary assignments" (which may or > may not be the correct term in this case) to researchers/developers, > starting from address space of a company which is "sponsoring" the > research. > > > The key part of what I would like to have is the possibility to provide > somebody with access to LIR portal services but limited to a specific > subset of my resources. > > In general, a company is not going to support a research/experiment by > providing indiscriminate access to the LIR portal. Creating a new > LIR or > transferring prefixes is not a plausible solution in this context. > > > An existing LIR can do an assignment to a researcher/developer as we > speak. All assignments an LIR makes are ‘temporary’, some may last a day > and some may last 10 years… Can you explain this better? I have been asking to several ncc contacts and there was no suitable solution for this at the moment. Asking researchers/developers to create their own LIRs so that resources can be transferred is not a practical solution, but I'm not sure you are referring to this. Giving the researcher/developer access to the LIR portal/APIs for all the resources is also not a solution. > > If you want the researcher to have access to services like RPKI, they > can ask their LIR. In some cases, maybe temporary transfers could also > be of use. Again, I don't see a way to do this at the moment. > > Note that this proposal aims to update the temporary assignment proposal > that is currently in place. The RIPE NCC makes these temporary > assignments from a pool of IPs they have reserved specifically for this > purpose. I understand. This is why I said that this could be a different proposal (even if related by a similar purpose). I changed the email subject to avoid confusion. > > > Also, I believe this would remove the need for an approval procedure > from the RIPE NCC side: (1) if the address space used is of a company, > there is less need to validate the research project motivations; and > (2) > the company "sponsoring" is also the one responsible for the address > space. > > > I am not sure I understand what you mean by this. The NCC does not need > to approve any assignments made by LIRs. The NCC will need to approve > temporary assignments if the request is sent by an LIR (for an end-user) > based on the current temporary assignment policy. That's exactly what I'm saying. Assignments done by LIRs of their own resources do not require approval, while they would satisfy the research use case (in summary: using prefixes from the ncc stash is not needed in all cases). Thanks for your answers. Ciao, Massimo

1 0

Call for presentations for MAT WG at RIPE86 in May
by Stephen Strowes 06 Apr '23

06 Apr '23

Hi all, RIPE86 is coming up fast: 22 -- 26 May! We are seeking your presentations for the next MAT WG session during that week. Presentations for the WG session are preferably 10-15min long. Please include in your proposal: * a title * a draft of your proposed presentation, even if just an outline * a paragraph describing the topic, and why the topic is of interest for the community. Interesting topics include (but are not limited to): recent measurement research which has an operational impact; recent operational work that may open avenues to research; projects, tools, or datasets that support either operations or research. Please submit your presentation proposal by Friday 28 April by emailing us at mat-wg-chairs at ripe.net. We will make our selections and post the agenda soon after. RIPE meetings are fully hybrid, and we encourage presentations from anywhere. Sessions are facilitated through meetecho. For our planning, we'd appreciate it if you can indicate whether you are likely to be online or on-site. Please ask if you have any questions regarding the setup on either side. Thanks! Cheers, Nina, Massimo, Stephen, as WG co-chairs

1 1

Subject: RIPE Atlas, RIPEstat and RIS Quarterly Planning Q2 2023
by Robert Kisteleki 30 Mar '23

30 Mar '23

Dear colleagues, The quarterly plans for RIPE Atlas, RIPEstat and RIS can now be found at: https://www.ripe.net/support/documentation/quarterly-planning The goal of our quarterly planning is to communicate the work we’re doing for the coming months, get your input and start a discussion on other developments we should work on. 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 RIPE NCC

1 0

Re: [mat-wg] [address-policy-wg] 2023-02 New Policy Proposal (Minimum Size for IPv4 Temporary Assignments)
by Massimo Candela 07 Mar '23

07 Mar '23

Hi all, I added in cc the MAT mailing list, which is frequented by researchers. I believe that is the right audience for this proposal. @MAT: Support for this proposal should be expressed before this Friday (March 10). See proposal below. Reply by keeping both list. @Addres-policy: I support this proposal. ------- I also mention below a variation of this proposal, which could be it's own proposal/thread (suggestions welcome): There should be an easy way to do "temporary assignments" (which may or may not be the correct term in this case) to researchers/developers, starting from address space of a company which is "sponsoring" the research. The key part of what I would like to have is the possibility to provide somebody with access to LIR portal services but limited to a specific subset of my resources. In general, a company is not going to support a research/experiment by providing indiscriminate access to the LIR portal. Creating a new LIR or transferring prefixes is not a plausible solution in this context. Also, I believe this would remove the need for an approval procedure from the RIPE NCC side: (1) if the address space used is of a company, there is less need to validate the research project motivations; and (2) the company "sponsoring" is also the one responsible for the address space. Ciao, Massimo On 27/02/2023 16:44, Leo Vegoda wrote: > Hi, > > We've not had any feedback on this proposal yet. > > As a reminder, this proposal would set "the minimum assignment size to > a /24 while still allowing for a smaller assignment if requested by > the End User. This policy proposal also allows routing requirements to > justify the request for more than a /24 for research purposes." > > Support for the proposal, or arguments against it are welcome. > > Many thanks, > > Leo Vegoda > Address Policy WG co-chair > > On Thu, 9 Feb 2023 at 00:26, Angela Dall'Ara <adallara(a)ripe.net> wrote: >> >> Dear colleagues, >> >> A new RIPE Policy Proposal, 2023-02, "Minimum Size for IPv4 Temporary >> Assignments" >> is now available for discussion. >> >> This policy proposal recommends setting the minimum assignment size for >> temporary assignments to a /24 while still allowing for a smaller >> assignment if requested by the End User. This policy proposal also >> allows routing requirements to justify the request for more than a /24 >> for research purposes. >> >> You can find the full proposal at: >> https://www.ripe.net/participate/policies/proposals/2023-02 >> >> As per the RIPE Policy Development Process (PDP), the purpose of this >> four-week Discussion Phase is to discuss the proposal and provide >> feedback to the proposers. >> >> At the end of the Discussion Phase, the proposers, with the agreement of >> the WG Chairs, will decide how to proceed with the proposal. >> >> The PDP document can be found at: >> https://www.ripe.net/publications/docs/ripe-781 >> >> We encourage you to review this proposal and send your comments to >> address-policy-wg(a)ripe.net before 10 March 2023. >> >> >> Kind regards, >> >> Angela Dall'Ara >> Policy Officer >> RIPE NCC >> >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg >

1 0

Improved timeliness of RIS dump files
by Emile Aben 07 Mar '23

07 Mar '23

Dear colleagues, We are planning to replace the pipeline that generates MRT dump files publicly available from the RIPE NCC. The new pipeline will have significantly less delay, and also some changes on the structure of the MRT file format [*]. Files in the newer format are available for testing here: https://www.ris.ripe.net/dumps-per-rrc-rest/prototype/ We have received feedback from MRT parser implementers that these files work fine for their parsers, but in case you haven't tested your MRT parser implementation, we ask you to test the new files before we make the switch. Our plan is to make this switch on 3 April 2023. After we make the switch the bview files available at our main location for downloading MRT files will be generated using the new pipeline and we will be able to produce these files in a more timely manner. Kind regards, Emile Aben RIPE NCC [*] These changes are documented here: https://ris.ripe.net/docs/40_Prototypes/15_per_rrc_dumps.html, but beware at this point we are only changing the files, not the frequency of dump files, nor putting the API in production. We did not receive feedback about these, but please let us know if you find them useful.

1 0

Re: [mat-wg] [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]
by Stephen Strowes 11 Jan '23

11 Jan '23

Hi, On 12/31/22 18:37, Randy Bush wrote: > hi robert, > > and thanks > >> I seem to remember that a typical non-public measurement is a one-off, >> and as such the data volume collected and stored is likely to be >> relatiely low. > interesting There is an old (late 2016) labs post worth referring to for this discussion [1]. In 2020 there was a survey of the users of private measurements [2], which was intended to get feedback on their actual use-cases. I seem to recall a very small set of respondents from an already small set of surveyees. The results are probably lost in the ether. I feel there's an aspect of the broader question that is rarely touched upon in these discussions: would user behaviour actually change if non-public measurements went away? I'm never sure how many use-cases are truly secret. Cheers, S. [1] https://labs.ripe.net/author/kistel/non-public-measurements-in-ripe-atlas/ [2] https://www.ripe.net/participate/forms/apply/ripe-atlas-private-measurement… > >> I don't have the numbers readily available to me at this moment, but >> we can certainly dig up recent statistics about this. > i did not intend to create a lot of work for you. but, as a measurement > person, i am a bit fond of basing decisions on facts. > > randy >

1 0

Fwd: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]
by Stephen Strowes 22 Dec '22

22 Dec '22

Hi all, I'm forwarding these five threads into the MAT WG because they're all probably of interest to folks here. Please share your feedback with the NCC! Cheers, S. -------- Forwarded Message -------- Subject: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] Date: Wed, 14 Dec 2022 15:04:40 +0100 From: Robert Kisteleki <robert(a)ripe.net> Organization: RIPE NCC To: ripe-atlas(a)ripe.net <ripe-atlas(a)ripe.net> 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

2 1

Re: [mat-wg] [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP]
by Massimo Candela 17 Dec '22

17 Dec '22

On 17/12/2022 00:19, Barry Raveendran Greene wrote: > > >> On Dec 16, 2022, at 23:29, Stephane Bortzmeyer <bortzmeyer(a)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.

1 0

RIPE Atlas, RIPEstat and RIS Quarterly Planning Q1 2023
by Robert Kisteleki 16 Dec '22

16 Dec '22

Dear colleagues, We’ve now published our quarterly planning for RIPE Atlas, RIPEstat and RIS. These are available at: https://www.ripe.net/support/documentation/quarterly-planning The goal of our quarterly planning is to communicate the work we’re doing for the coming months, get your input and start a discussion on other developments we should work on. 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

Fwd: [atlas] Proposal: Add support for STARTTLS measurements [STARTTLS]
by Stephen Strowes 14 Dec '22

14 Dec '22

Hi all, I'm forwarding these five threads into the MAT WG because they're all probably of interest to folks here. Please share your feedback with the NCC! Cheers, S. -------- Forwarded Message -------- Subject: [atlas] Proposal: Add support for STARTTLS measurements [STARTTLS] Date: Wed, 14 Dec 2022 15:04:06 +0100 From: Robert Kisteleki <robert(a)ripe.net> Organization: RIPE NCC To: ripe-atlas(a)ripe.net <ripe-atlas(a)ripe.net> 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

1 0

Fwd: [atlas] Proposal: Generic HTTP measurements [GENERIC-HTTP]
by Stephen Strowes 14 Dec '22

14 Dec '22

Hi all, I'm forwarding these five threads into the MAT WG because they're all probably of interest to folks here. Please share your feedback with the NCC! Cheers, S. -------- Forwarded Message -------- Subject: [atlas] Proposal: Generic HTTP measurements [GENERIC-HTTP] Date: Wed, 14 Dec 2022 15:03:32 +0100 From: Robert Kisteleki <robert(a)ripe.net> Organization: RIPE NCC To: ripe-atlas(a)ripe.net <ripe-atlas(a)ripe.net> 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

1 0

Fwd: [atlas] Proposal: Measure well-known CDNs, [CDN-HTTP]
by Stephen Strowes 14 Dec '22

14 Dec '22

Hi all, I'm forwarding these five threads into the MAT WG because they're all probably of interest to folks here. Please share your feedback with the NCC! Cheers, S. -------- Forwarded Message -------- Subject: [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP] Date: Wed, 14 Dec 2022 15:02:46 +0100 From: Robert Kisteleki <robert(a)ripe.net> Organization: RIPE NCC To: ripe-atlas(a)ripe.net <ripe-atlas(a)ripe.net> 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

1 0

Fwd: [atlas] Proposal: remove per-hop “late” packets from traceroute [LATE-PACKETS]
by Stephen Strowes 14 Dec '22

14 Dec '22

Hi all, I'm forwarding these five threads into the MAT WG because they're all probably of interest to folks here. Please share your feedback with the NCC! Cheers, S. -------- Forwarded Message -------- Subject: [atlas] Proposal: remove per-hop “late” packets from traceroute [LATE-PACKETS] Date: Wed, 14 Dec 2022 15:02:13 +0100 From: Robert Kisteleki <robert(a)ripe.net> Organization: RIPE NCC To: ripe-atlas(a)ripe.net <ripe-atlas(a)ripe.net> 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

1 0

MAT Working Group Minutes - RIPE 85
by Massimo Candela 29 Nov '22

29 Nov '22

Dear all, The MAT Working Group Minutes for RIPE 85 are available at https://www.ripe.net/participate/ripe/wg/active-wg/mat/minutes/mat-working-… Ciao, Massimo (on behalf of the MAT Chairs)

1 0

Format change for index pages of RIS MRT data files and RIPE Atlas daily dataset dumps
by Oleg Muravskiy 24 Nov '22

24 Nov '22

Dear RIS and RIPE Atlas users, On Wednesday, 30 November 2022 we are planning to migrate the web server at <https://data.ris.ripe.net/> as well as <https://data-store.ripe.net> from Apache httpd to nginx. This will affect how the file listings in HTML index pages are generated, including the following: * RIS MRT data files (updates and dumps) * RIPE Atlas daily dataset dumps If you rely on the format of these pages, you need to update your software. Before we do the upgrade, you could check the new format of the index pages at: https://test-data.ris.ripe.net/rrc00/ We would like to ask you to avoid relying on the specific format of the index.html files. If you are fetching BGP dump files, please use the REST API that is described at: https://ris.ripe.net/docs/40_Prototypes/15_per_rrc_dumps.html You might also consider using per-peer dump files instead: https://ris.ripe.net/docs/40_Prototypes/10_per_peer_dumps.html We want to encourage you to provide your feedback on the API, so that we could improve it and build a similar API for the update files. If you are fetching update files, please use direct URLs to files as described at: https://ris.ripe.net/docs/20_raw_data_mrt.html#name-and-location Kind regards, Oleg Muravskiy, Robert Kisteleki RIPE NCC

1 0

streaming link MAT session ripe85
by Massimo Candela 27 Oct '22

27 Oct '22

The MAT session started at RIPE85. Streaming here: https://ripe85.ripe.net/live/side/

1 0

MAT agenda for RIPE85
by Massimo Candela 26 Oct '22

26 Oct '22

Dear all, I'm pleased to announce that we have an agenda for RIPE85! https://ripe85.ripe.net/programme/meeting-plan/mat-wg/ Ciao, Massimo (on behalf of the MAT chairs)

2 1

Re: [mat-wg] [ippm] [Rpm] [M-Lab-Discuss] misery metrics & consequences
by J Ignacio Alvarez-Hamelin 26 Oct '22

26 Oct '22

Dear all, After some time in silence on the IPPM list, I like to make some comments here. As we presented in the draft-ietf-ippm-route-00 (now the RFC9198), the main problem is the traffic follows heavy-tailed distributions when it is seen from the end-to-end points: the origin of most of the issues in that video. Therefore, treating it as parametric distribution is not possible, unless you are dealing with a complex distribution like the Stable distribution: • B. Mandelbrot, “New methods in statistical economics,” Journal of political economy, vol. 71, no. 5, pp. 421–440, 1963. • ——, “The variation of certain speculative prices,” The journal of business, vol. 36, no. 4, pp. 394–419, 1963. (and so it will be extremely complex a high computing demands.) This is why we propose to use quartiles to characterize delays in the RFC9198. Then, I am doing some research to understand how the delay can change with network load, using the quartiles. I attach some measurements done during the pandemic, showing the congestion as a function of the time. Best, Ignacio _______________________________________________________________ Dr. Ing. José Ignacio Alvarez-Hamelin CONICET and Facultad de Ingeniería, Universidad de Buenos Aires Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina +54 (11) 5285 0716 / 5285 0705 e-mail: ihameli(a)cnet.fi.uba.ar web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ _______________________________________________________________ > On 23 Oct 2022, at 08:57, Sebastian Moeller <moeller0(a)gmx.de> wrote: > > Hi Glenn, > > >> On Oct 23, 2022, at 02:17, Glenn Fishbine via Rpm <rpm(a)lists.bufferbloat.net> wrote: >> >> As a classic died in the wool empiricist, granted that you can identify "misery" factors, given a population of 1,000 users, how do you propose deriving a misery index for that population? >> >> We can measure download, upload, ping, jitter pretty much without user intervention. For the measurements you hypothesize, how you you automatically extract those indecies without subjective user contamination. >> >> I.e. my download speed sucks. Measure the download speed. >> >> My isp doesn't fix my problem. Measure what? How? >> >> Human survey technology is 70+ years old and it still has problems figuring out how to correlate opinion with fact. >> >> Without an objective measurement scheme that doesn't require human interaction, the misery index is a cool hypothesis with no way to link to actual data. What objective measurements can be made? Answer that and the index becomes useful. Otherwise it's just consumer whining. >> >> Not trying to be combative here, in fact I like the concept you support, but I'm hard pressed to see how the concept can lead to data, and the data lead to policy proposals. > > [SM] So it seems that outside of seemingly simple to test throughput numbers*, the next most important quality number (or the most important depending on subjective ranking) is how does latency change under "load". Absolute latency is also important albeit static high latency can be worked around within limits so the change under load seems more relevant. > All of flent's RRUL test, apple's networkQuality/RPM, and iperf2's bounceback test offer methods to asses latency change under load**, as do waveforms bufferbloat tests and even to a degree Ookla's speedtest.net. IMHO something like latency increase under load or apple's responsiveness measure RPM (basically the inverse of the latency under load calculated on a per minute basis, so it scales in the typical higher numbers are better way, unlike raw latency under load numbers where smaller is better). > IMHO what networkQuality is missing ATM is to measure and report the unloaded RPM as well as the loaded the first gives a measure over the static latency the second over how well things keep working if capacity gets tight. They report the base RTT which can be converted to RPM. As an example: > > macbook:~ user$ networkQuality -v > ==== SUMMARY ==== > Upload capacity: 24.341 Mbps > Download capacity: 91.951 Mbps > Upload flows: 20 > Download flows: 16 > Responsiveness: High (2123 RPM) > Base RTT: 16 > Start: 10/23/22, 13:44:39 > End: 10/23/22, 13:44:53 > OS Version: Version 12.6 (Build 21G115) > > Here RPM 2133 corresponds to 60000/2123 = 28.26 ms latency under load, while the Base RTT of 16ms corresponds to 60000/16 = 3750 RPM, son on this link load reduces the responsiveness by 3750-2123 = 1627 RPM a reduction by 100-100*2123/3750 = 43.4%, and that is with competent AQM and scheduling on the router. > > Without competent AQM/shaping I get: > ==== SUMMARY ==== > Upload capacity: 15.101 Mbps > Download capacity: 97.664 Mbps > Upload flows: 20 > Download flows: 12 > Responsiveness: Medium (427 RPM) > Base RTT: 16 > Start: 10/23/22, 13:51:50 > End: 10/23/22, 13:52:06 > OS Version: Version 12.6 (Build 21G115) > latency under load: 60000/427 = 140.52 ms > base RPM: 60000/16 = 3750 RPM > reduction RPM: 100-100*427/3750 = 88.6% > > > I understand apple's desire to have a single reported number with a single qualifier medium/high/... because in the end a link is only reliably usable if responsiveness under load stays acceptable, but with two numbers it is easier to see what one's ISP could do to help. (I guess some ISPs might already be unhappy with the single number, so this needs some diplomacy/tact) > > Regards > Sebastian > > > > *) Seemingly as quite some ISPs operate their own speedtest servers in their network and ignore customers not reaching the contracted rates into speedtest-servers located in different ASs. As the product is called internet access I a inclined to expect that my ISP maintains sufficient peering/transit capacity to reach the next tier of AS at my contracted rate (the EU legislative seems to agree, see EU directive 2015/2120). > > **) Most do by creating load themselves and measuring throughput at the same time, bounceback IIUC will focus on the latency measurement and leave the load generation optional (so offers a mode to measure responsiveness of a live network with minimal measurement traffic). @Bob, please correct me if this is wrong. > > >> >> >> On Fri, Oct 21, 2022, 5:20 PM Dave Taht <dave.taht(a)gmail.com> wrote: >> One of the best talks I've ever seen on how to measure customer >> satisfaction properly just went up after the P99 Conference. >> >> It's called Misery Metrics. >> >> After going through a deep dive as to why and how we think and act on >> percentiles, bins, and other statistical methods as to how we use the >> web and internet are *so wrong* (well worth watching and thinking >> about if you are relying on or creating network metrics today), it >> then points to the real metrics that matter to users and the ultimate >> success of an internet business: Timeouts, retries, misses, failed >> queries, angry phone calls, abandoned shopping carts and loss of >> engagement. >> >> https://www.p99conf.io/session/misery-metrics-consequences/ >> >> The ending advice was - don't aim to make a specific percentile >> acceptable, aim for an acceptable % of misery. >> >> I enjoyed the p99 conference more than any conference I've attended in years. >> >> -- >> This song goes out to all the folk that thought Stadia would work: >> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656… >> Dave Täht CEO, TekLibre, LLC >> >> -- >> You received this message because you are subscribed to the Google Groups "discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to discuss+unsubscribe(a)measurementlab.net. >> To view this discussion on the web visit https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAA93jw4w27a…. >> _______________________________________________ >> Rpm mailing list >> Rpm(a)lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/rpm > > _______________________________________________ > ippm mailing list > ippm(a)ietf.org > https://www.ietf.org/mailman/listinfo/ippm

2 1

Re: [mat-wg] [Rpm] [ippm] [M-Lab-Discuss] misery metrics & consequences
by J Ignacio Alvarez-Hamelin 25 Oct '22

25 Oct '22

Dear Bob, I answer inline. Thank you for your comments. P.D. It seems that I have no rights to send emails to the Measurement Analysis and Tools Working Group: how I can join it? _______________________________________________________________ Dr. Ing. José Ignacio Alvarez-Hamelin CONICET and Facultad de Ingeniería, Universidad de Buenos Aires Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina +54 (11) 5285 0716 / 5285 0705 e-mail: ihameli(a)cnet.fi.uba.ar web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ _______________________________________________________________ > On 25 Oct 2022, at 14:02, rjmcmahon <rjmcmahon(a)rjmcmahon.com> wrote: > > I don't understand the information in the link. It looks like lines on a map to some form of dials which are too small to read. I suppose that depends on the zoom of your browser, try to put 100% (command+ to zoom-in in chrome). You will see a 24 hour clock where some hours are green (no congestion), yellow (some congestion) or red (congestion). But all of that is just an example. > > One can sample and create a Gaussian per the central limit theorem (CLT) if the underlying process probability density functions converge, i.e. can be integrated to 1. With that said, normalizing does lose information and doesn't say much about tails, outliers, etc. The Stable distribution is a generalization over all the distributions. Consider that Gaussian has finite moments, and heavy-tailed distribution not, this is where Stable one enters as a generalization. > > We should be careful in assuming only the tails matter and that all traffic follows heavy-tailed distributions. With bufferbloat it's the minimum of the latency PDF that shifts. Codel watches a minimum. "Jacobson suggested that average queue length actually contains no information at all about packet demand or network load.[3][5] He suggested that a better metric might be the minimum queue length during a sliding time window." Well, it depends on which point of the network you really are, but there a lot where this is true. In the other hand, no heavy tailed distributions do not cause problems if you use statistical tools that suport anything. For example, the median (Q2) converges to the mean (fist statistical moment) for Poisson distributions. > > We need statistical tools that also allow for the analysis of non-parametric distributions too. Hotelling T2 assumes the multivariate distributions are Gaussian. Kolmogorov-Smirnov tests can be used for non-parametric distributions. We find both are needed for SPC used by our automation systems. Yes, I did a lot of this kind of test, and I found very interesting things, even in the very important links (important ISP with important CDN), verifying Stable distributions with certain parameters (even some ones with heavy-tailed distributions). The problem is how to do this a low computable cost, and this why you can use quartiles. > > Sample subgroups of one really don't give sufficient information about any type of distribution, parametric or non-parametric. Here I cannot understand: which are the subgroups? > > Bob >> Dear all, >> After some time in silence on the IPPM list, I like to make some >> comments here. As we presented in the draft-ietf-ippm-route-00 (now >> the RFC9198), the main problem is the traffic follows heavy-tailed >> distributions when it is seen from the end-to-end points: the origin >> of most of the issues in that video. Therefore, treating it as >> parametric distribution is not possible, unless you are dealing with a >> complex distribution like the Stable distribution: >> • B. Mandelbrot, “New methods in statistical economics,” Journal of >> political economy, vol. 71, no. 5, pp. 421–440, 1963. >> • ——, “The variation of certain speculative prices,” The journal of >> business, vol. 36, no. 4, pp. 394–419, 1963. >> (and so it will be extremely complex a high computing demands.) >> This is why we propose to use quartiles to characterize delays in the >> RFC9198. Then, I am doing some research to understand how the delay >> can change with network load, using the quartiles. >> You can see some measurements done during the pandemic, showing the >> congestion as a function of the time (24 hours maximum): >> https://cnet.fi.uba.ar/ignacio.alvarez-hamelin/RIPE-Atlas-measurement-24681… >> [you can zoom in and out, pan it, clicking on the Xs you can close >> dialogs, to reopen them click on the link] >> Best, >> Ignacio >> ___________________________________ >> _______________________________________________________________ >> Dr. Ing. José Ignacio Alvarez-Hamelin >> CONICET and Facultad de Ingeniería, Universidad de Buenos Aires >> Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina >> +54 (11) 5285 0716 / 5285 0705 >> e-mail: ihameli(a)cnet.fi.uba.ar >> web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ >> _______________________________________________________________ >>> On 23 Oct 2022, at 08:57, Sebastian Moeller <moeller0(a)gmx.de> wrote: >>> Hi Glenn, >>>> On Oct 23, 2022, at 02:17, Glenn Fishbine via Rpm <rpm(a)lists.bufferbloat.net> wrote: >>>> As a classic died in the wool empiricist, granted that you can identify "misery" factors, given a population of 1,000 users, how do you propose deriving a misery index for that population? >>>> We can measure download, upload, ping, jitter pretty much without user intervention. For the measurements you hypothesize, how you you automatically extract those indecies without subjective user contamination. >>>> I.e. my download speed sucks. Measure the download speed. >>>> My isp doesn't fix my problem. Measure what? How? >>>> Human survey technology is 70+ years old and it still has problems figuring out how to correlate opinion with fact. >>>> Without an objective measurement scheme that doesn't require human interaction, the misery index is a cool hypothesis with no way to link to actual data. What objective measurements can be made? Answer that and the index becomes useful. Otherwise it's just consumer whining. >>>> Not trying to be combative here, in fact I like the concept you support, but I'm hard pressed to see how the concept can lead to data, and the data lead to policy proposals. >>> [SM] So it seems that outside of seemingly simple to test throughput numbers*, the next most important quality number (or the most important depending on subjective ranking) is how does latency change under "load". Absolute latency is also important albeit static high latency can be worked around within limits so the change under load seems more relevant. >>> All of flent's RRUL test, apple's networkQuality/RPM, and iperf2's bounceback test offer methods to asses latency change under load**, as do waveforms bufferbloat tests and even to a degree Ookla's speedtest.net. IMHO something like latency increase under load or apple's responsiveness measure RPM (basically the inverse of the latency under load calculated on a per minute basis, so it scales in the typical higher numbers are better way, unlike raw latency under load numbers where smaller is better). >>> IMHO what networkQuality is missing ATM is to measure and report the unloaded RPM as well as the loaded the first gives a measure over the static latency the second over how well things keep working if capacity gets tight. They report the base RTT which can be converted to RPM. As an example: >>> macbook:~ user$ networkQuality -v >>> ==== SUMMARY ==== >>> Upload capacity: 24.341 Mbps >>> Download capacity: 91.951 Mbps >>> Upload flows: 20 >>> Download flows: 16 >>> Responsiveness: High (2123 RPM) >>> Base RTT: 16 >>> Start: 10/23/22, 13:44:39 >>> End: 10/23/22, 13:44:53 >>> OS Version: Version 12.6 (Build 21G115) >>> Here RPM 2133 corresponds to 60000/2123 = 28.26 ms latency under load, while the Base RTT of 16ms corresponds to 60000/16 = 3750 RPM, son on this link load reduces the responsiveness by 3750-2123 = 1627 RPM a reduction by 100-100*2123/3750 = 43.4%, and that is with competent AQM and scheduling on the router. >>> Without competent AQM/shaping I get: >>> ==== SUMMARY ==== >>> Upload capacity: 15.101 Mbps >>> Download capacity: 97.664 Mbps >>> Upload flows: 20 >>> Download flows: 12 >>> Responsiveness: Medium (427 RPM) >>> Base RTT: 16 >>> Start: 10/23/22, 13:51:50 >>> End: 10/23/22, 13:52:06 >>> OS Version: Version 12.6 (Build 21G115) >>> latency under load: 60000/427 = 140.52 ms >>> base RPM: 60000/16 = 3750 RPM >>> reduction RPM: 100-100*427/3750 = 88.6% >>> I understand apple's desire to have a single reported number with a single qualifier medium/high/... because in the end a link is only reliably usable if responsiveness under load stays acceptable, but with two numbers it is easier to see what one's ISP could do to help. (I guess some ISPs might already be unhappy with the single number, so this needs some diplomacy/tact) >>> Regards >>> Sebastian >>> *) Seemingly as quite some ISPs operate their own speedtest servers in their network and ignore customers not reaching the contracted rates into speedtest-servers located in different ASs. As the product is called internet access I a inclined to expect that my ISP maintains sufficient peering/transit capacity to reach the next tier of AS at my contracted rate (the EU legislative seems to agree, see EU directive 2015/2120). >>> **) Most do by creating load themselves and measuring throughput at the same time, bounceback IIUC will focus on the latency measurement and leave the load generation optional (so offers a mode to measure responsiveness of a live network with minimal measurement traffic). @Bob, please correct me if this is wrong. >>>> On Fri, Oct 21, 2022, 5:20 PM Dave Taht <dave.taht(a)gmail.com> wrote: >>>> One of the best talks I've ever seen on how to measure customer >>>> satisfaction properly just went up after the P99 Conference. >>>> It's called Misery Metrics. >>>> After going through a deep dive as to why and how we think and act on >>>> percentiles, bins, and other statistical methods as to how we use the >>>> web and internet are *so wrong* (well worth watching and thinking >>>> about if you are relying on or creating network metrics today), it >>>> then points to the real metrics that matter to users and the ultimate >>>> success of an internet business: Timeouts, retries, misses, failed >>>> queries, angry phone calls, abandoned shopping carts and loss of >>>> engagement. >>>> https://www.p99conf.io/session/misery-metrics-consequences/ >>>> The ending advice was - don't aim to make a specific percentile >>>> acceptable, aim for an acceptable % of misery. >>>> I enjoyed the p99 conference more than any conference I've attended in years. >>>> -- >>>> This song goes out to all the folk that thought Stadia would work: >>>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656… >>>> Dave Täht CEO, TekLibre, LLC >>>> -- >>>> You received this message because you are subscribed to the Google Groups "discuss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an email to discuss+unsubscribe(a)measurementlab.net. >>>> To view this discussion on the web visit https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAA93jw4w27a…. >>>> _______________________________________________ >>>> Rpm mailing list >>>> Rpm(a)lists.bufferbloat.net >>>> https://lists.bufferbloat.net/listinfo/rpm >>> _______________________________________________ >>> ippm mailing list >>> ippm(a)ietf.org >>> https://www.ietf.org/mailman/listinfo/ippm >> _______________________________________________ >> Rpm mailing list >> Rpm(a)lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/rpm

1 0

Re: [mat-wg] [ippm] [Rpm] [M-Lab-Discuss] misery metrics & consequences
by J Ignacio Alvarez-Hamelin 25 Oct '22

25 Oct '22

Dear all, After some time in silence on the IPPM list, I like to make some comments here. As we presented in the draft-ietf-ippm-route-00 (now the RFC9198), the main problem is the traffic follows heavy-tailed distributions when it is seen from the end-to-end points: the origin of most of the issues in that video. Therefore, treating it as parametric distribution is not possible, unless you are dealing with a complex distribution like the Stable distribution: • B. Mandelbrot, “New methods in statistical economics,” Journal of political economy, vol. 71, no. 5, pp. 421–440, 1963. • ——, “The variation of certain speculative prices,” The journal of business, vol. 36, no. 4, pp. 394–419, 1963. (and so it will be extremely complex a high computing demands.) This is why we propose to use quartiles to characterize delays in the RFC9198. Then, I am doing some research to understand how the delay can change with network load, using the quartiles. You can see some measurements done during the pandemic, showing the congestion as a function of the time (24 hours maximum): https://cnet.fi.uba.ar/ignacio.alvarez-hamelin/RIPE-Atlas-measurement-24681… [you can zoom in and out, pan it, clicking on the Xs you can close dialogs, to reopen them click on the link] Best, Ignacio ___________________________________ _______________________________________________________________ Dr. Ing. José Ignacio Alvarez-Hamelin CONICET and Facultad de Ingeniería, Universidad de Buenos Aires Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina +54 (11) 5285 0716 / 5285 0705 e-mail: ihameli(a)cnet.fi.uba.ar web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ _______________________________________________________________ > On 23 Oct 2022, at 08:57, Sebastian Moeller <moeller0(a)gmx.de> wrote: > > Hi Glenn, > > >> On Oct 23, 2022, at 02:17, Glenn Fishbine via Rpm <rpm(a)lists.bufferbloat.net> wrote: >> >> As a classic died in the wool empiricist, granted that you can identify "misery" factors, given a population of 1,000 users, how do you propose deriving a misery index for that population? >> >> We can measure download, upload, ping, jitter pretty much without user intervention. For the measurements you hypothesize, how you you automatically extract those indecies without subjective user contamination. >> >> I.e. my download speed sucks. Measure the download speed. >> >> My isp doesn't fix my problem. Measure what? How? >> >> Human survey technology is 70+ years old and it still has problems figuring out how to correlate opinion with fact. >> >> Without an objective measurement scheme that doesn't require human interaction, the misery index is a cool hypothesis with no way to link to actual data. What objective measurements can be made? Answer that and the index becomes useful. Otherwise it's just consumer whining. >> >> Not trying to be combative here, in fact I like the concept you support, but I'm hard pressed to see how the concept can lead to data, and the data lead to policy proposals. > > [SM] So it seems that outside of seemingly simple to test throughput numbers*, the next most important quality number (or the most important depending on subjective ranking) is how does latency change under "load". Absolute latency is also important albeit static high latency can be worked around within limits so the change under load seems more relevant. > All of flent's RRUL test, apple's networkQuality/RPM, and iperf2's bounceback test offer methods to asses latency change under load**, as do waveforms bufferbloat tests and even to a degree Ookla's speedtest.net. IMHO something like latency increase under load or apple's responsiveness measure RPM (basically the inverse of the latency under load calculated on a per minute basis, so it scales in the typical higher numbers are better way, unlike raw latency under load numbers where smaller is better). > IMHO what networkQuality is missing ATM is to measure and report the unloaded RPM as well as the loaded the first gives a measure over the static latency the second over how well things keep working if capacity gets tight. They report the base RTT which can be converted to RPM. As an example: > > macbook:~ user$ networkQuality -v > ==== SUMMARY ==== > Upload capacity: 24.341 Mbps > Download capacity: 91.951 Mbps > Upload flows: 20 > Download flows: 16 > Responsiveness: High (2123 RPM) > Base RTT: 16 > Start: 10/23/22, 13:44:39 > End: 10/23/22, 13:44:53 > OS Version: Version 12.6 (Build 21G115) > > Here RPM 2133 corresponds to 60000/2123 = 28.26 ms latency under load, while the Base RTT of 16ms corresponds to 60000/16 = 3750 RPM, son on this link load reduces the responsiveness by 3750-2123 = 1627 RPM a reduction by 100-100*2123/3750 = 43.4%, and that is with competent AQM and scheduling on the router. > > Without competent AQM/shaping I get: > ==== SUMMARY ==== > Upload capacity: 15.101 Mbps > Download capacity: 97.664 Mbps > Upload flows: 20 > Download flows: 12 > Responsiveness: Medium (427 RPM) > Base RTT: 16 > Start: 10/23/22, 13:51:50 > End: 10/23/22, 13:52:06 > OS Version: Version 12.6 (Build 21G115) > latency under load: 60000/427 = 140.52 ms > base RPM: 60000/16 = 3750 RPM > reduction RPM: 100-100*427/3750 = 88.6% > > > I understand apple's desire to have a single reported number with a single qualifier medium/high/... because in the end a link is only reliably usable if responsiveness under load stays acceptable, but with two numbers it is easier to see what one's ISP could do to help. (I guess some ISPs might already be unhappy with the single number, so this needs some diplomacy/tact) > > Regards > Sebastian > > > > *) Seemingly as quite some ISPs operate their own speedtest servers in their network and ignore customers not reaching the contracted rates into speedtest-servers located in different ASs. As the product is called internet access I a inclined to expect that my ISP maintains sufficient peering/transit capacity to reach the next tier of AS at my contracted rate (the EU legislative seems to agree, see EU directive 2015/2120). > > **) Most do by creating load themselves and measuring throughput at the same time, bounceback IIUC will focus on the latency measurement and leave the load generation optional (so offers a mode to measure responsiveness of a live network with minimal measurement traffic). @Bob, please correct me if this is wrong. > > >> >> >> On Fri, Oct 21, 2022, 5:20 PM Dave Taht <dave.taht(a)gmail.com> wrote: >> One of the best talks I've ever seen on how to measure customer >> satisfaction properly just went up after the P99 Conference. >> >> It's called Misery Metrics. >> >> After going through a deep dive as to why and how we think and act on >> percentiles, bins, and other statistical methods as to how we use the >> web and internet are *so wrong* (well worth watching and thinking >> about if you are relying on or creating network metrics today), it >> then points to the real metrics that matter to users and the ultimate >> success of an internet business: Timeouts, retries, misses, failed >> queries, angry phone calls, abandoned shopping carts and loss of >> engagement. >> >> https://www.p99conf.io/session/misery-metrics-consequences/ >> >> The ending advice was - don't aim to make a specific percentile >> acceptable, aim for an acceptable % of misery. >> >> I enjoyed the p99 conference more than any conference I've attended in years. >> >> -- >> This song goes out to all the folk that thought Stadia would work: >> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656… >> Dave Täht CEO, TekLibre, LLC >> >> -- >> You received this message because you are subscribed to the Google Groups "discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to discuss+unsubscribe(a)measurementlab.net. >> To view this discussion on the web visit https://groups.google.com/a/measurementlab.net/d/msgid/discuss/CAA93jw4w27a…. >> _______________________________________________ >> Rpm mailing list >> Rpm(a)lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/rpm > > _______________________________________________ > ippm mailing list > ippm(a)ietf.org > https://www.ietf.org/mailman/listinfo/ippm

1 0

misery metrics & consequences
by Dave Taht 22 Oct '22

22 Oct '22

One of the best talks I've ever seen on how to measure customer satisfaction properly just went up after the P99 Conference. It's called Misery Metrics. After going through a deep dive as to why and how we think and act on percentiles, bins, and other statistical methods as to how we use the web and internet are *so wrong* (well worth watching and thinking about if you are relying on or creating network metrics today), it then points to the real metrics that matter to users and the ultimate success of an internet business: Timeouts, retries, misses, failed queries, angry phone calls, abandoned shopping carts and loss of engagement. https://www.p99conf.io/session/misery-metrics-consequences/ The ending advice was - don't aim to make a specific percentile acceptable, aim for an acceptable % of misery. I enjoyed the p99 conference more than any conference I've attended in years. -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656… Dave Täht CEO, TekLibre, LLC

2 2

RIPE Atlas, RIPEstat and RIS Quarterly Planning Q4 2022
by Robert Kisteleki 27 Sep '22

27 Sep '22

Dear colleagues, We’ve now published our quarterly planning for RIPE Atlas, RIPEstat and RIS. These are available at: https://www.ripe.net/support/documentation/quarterly-planning The goal of our quarterly planning is to communicate the work we’re doing for the coming months, get your input and start a discussion on other developments we should work on. 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

Open House: Exploring RIPEstat
by Christian Teuschel 21 Sep '22

21 Sep '22

Dear colleagues, A quick note to remind you that the RIPE NCC Open House: Exploring RIPEstat is taking place on Wednesday, 28 September at 10:00 (UTC). During this online event, we will talk about what makes this tool a favourite for network operators, CERTs and a wide group of Internet stakeholders. I will be joined by guests who will speak in detail about RIPEstat datasets, a number of new features and the new UI. Check out the details and register for free at: https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-ex… Best regards, Christian Teuschel

1 0

Internet Measurement Day - Tomorrow, 13 September, Online
by Gergana Petrova 12 Sep '22

12 Sep '22

Dear colleagues, A quick note to remind you that the Internet Measurement Day Serbia is taking place tomorrow, 13 September, online. During this online event we will talk about tools on how to measure the Internet, such as RIPE Atlas, the Identifier Technology Health Indicators (ITHI Metrics), Routing Information System (RIS), Resource Public Key Infrastructure (RPKI) and the RIPE NCC’s open data platform RIPEstat. You will also hear from a number of local and international organisations, such as RATEL, SOX, CAIDA and more. Even though the particular focus is on Serbia, a lot of the presentations would be general. Perhaps even the more local presentations would be relevant for those of you who are doing business in neighbouring countries. Check out the agenda and if interested, register for free here: https://www.ripe.net/participate/meetings/internet-measurement-day/internet… Best regards, Gergana -- Gergana Petrova Community Development Manager RIPE NCC

1 0

Fwd: Join Virtual En-ROADS Climate Workshop on September 8!
by Vesna Manojlovic 07 Sep '22

07 Sep '22

Dear MAT-WG, here's an invitation to en_ROADS workshop: https://www.climateinteractive.org/get-involved/webinars/ This is a great showcase for the visualisation of complex & open data, measured over long time periods, analysed and fit into models that are predicting outcomes in the future. I find it highly relevant for the operations of Internet infrastructure, since it has elements of: - water availability https://www.datacenterdynamics.com/en/opinions/why-data-centers-need-to-tal… - sea-level rise https://labs.ripe.net/author/ggm/surviving-the-flood-how-data-centres-and-t… - energy consumption https://www.consultancy.uk/news/28772/10-ways-businesses-can-reduce-their-d… I hope you find it useful, regards, Vesna

1 0

samknows reports 853 ms of latency under load for US DSL.
by Dave Taht 26 Aug '22

26 Aug '22

US DSL, according to their measurements, has 853 ms of latency under load, as reported to the FCC. pretty good podcast and blog at: https://samknows.com/blog/bufferbloat - where they also discuss their current and planned methods of measurement. Also, speedtest.net is finally reporting on "working latency", and their new speedtest apps showing it to the user. https://www.ookla.com/articles/introducing-loaded-latency It would be really great if y'all could join in on helping us finally solve the bufferbloat problem internet wide. -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC

1 0

New on RIPE Labs: 240/4 As Seen by RIPE Atlas
by Qasim Lone 23 Aug '22

23 Aug '22

Dear colleagues, In this new article on RIPE Labs, we use data from RIPE Atlas probes to investigate the usage of 240/4, a block of IPv4 addresses 'reserved for future use' and formally known as Class E in the wild. https://labs.ripe.net/author/qasim-lone/2404-as-seen-by-ripe-atlas/ Kind regards, Qasim

1 0

Call for presentations MAT WG at RIPE85
by Massimo Candela 15 Aug '22

15 Aug '22

Dear MAT WG, We should start getting ready for RIPE85! This year we have a 1.5 hours slot on Thursday 27 October at 09:00 CEST (draft, things may change). Please, submit your presentation proposal by September 9th by sending an email at mat-wg-chairs(a)ripe.net. We prefer talks of 15min. Include in your email a title, a draft of the presentation, and a paragraph describing what you will talk about and why the topic is of interest for the community. Please, let us know if you are planning to present in person or remotely. Thanks! Cheers, Nina, Stephen, Massimo

1 1

Announcement of new RIS prototype services
by Oleg Muravskiy 05 Aug '22

05 Aug '22

Dear RIS users, Over the past few months, we have created several prototype services that expose RIS data in different ways. These services provide a REST API, and the data they expose is closer to real-time, as compared to our traditional "bview" and "updates" files. These services are: - Per-peer dumps https://ris.ripe.net/docs/40_Prototypes/10_per_peer_dumps.html - Per-RRC dumps https://ris.ripe.net/docs/40_Prototypes/15_per_rrc_dumps.html - Peer metadata https://ris.ripe.net/docs/40_Prototypes/20_peer_metadata.html Please take a look at the documentation (links provided above), try out these new services, and tell us what we can improve! We would love to hear your feedback. Since we're posting this message across multiple mailing lists, we ask you to please share your feedback on the ris-users(a)ripe.net mailing list, or write to us directly at ris(a)ripe.net rather than on this list. Kind regards, Oleg Muravskiy RIPE NCC

1 0

New on RIPE Labs: Measuring Encrypted-DNS Censorship Using OONI Probe
by Anastasiya Pak 04 Aug '22

04 Aug '22

Dear colleagues, The Open Observatory Network Interference (OONI) is a non-profit free software project that aims to empower decentralised efforts in documenting Internet censorship around the world. In collaboration with different partners, Simone Basso and colleagues publish research reports and research papers documenting cases of Internet censorship around the world. In this new article on RIPE Labs, Simone talks through the preliminary results of an encrypted-DNS censorship study currently being conducted by the OONI. Read now on Labs: https://labs.ripe.net/author/bassosimone/measuring-encrypted-dns-censorship… Best regards, Anastasiya Pak Marketing & Communications Officer RIPE NCC

1 0

New on RIPE Labs: Dealing with the Undercurrent of Unwanted Traffic
by Alun Davies 06 Jul '22

06 Jul '22

Dear colleagues, Leslie Daigle and her colleagues over at the Global Cyber Alliance have been collecting data from hundreds of sensors to get a clearer picture of how much unwanted traffic there is out there. How much counts as too much? Read more on RIPE Labs: https://labs.ripe.net/author/leslie-daigle/dealing-with-the-undercurrent-of… Best regards, Alun Davies RIPE Labs Editor RIPE NCC

3 3

RIPE Atlas, RIPEstat and RIS Quarterly Planning Q3 2022
by Robert Kisteleki 30 Jun '22

30 Jun '22

Dear colleagues, We’ve now published our quarterly for RIPE Atlas, RIPEstat and RIS. These are available at: https://www.ripe.net/support/documentation/quarterly-planning We hope that by providing these plans, we can better inform the community of the ongoing work on the services we operate and get feedback on our work. 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: Provide a simple API to get user's network info.
by Darvari 28 Jun '22

28 Jun '22

Hello, One of the main problems in tools that intend to measure censorship or want to measure the quality and security of the user's network is access to a simple API that has several important information of the user's network: - AS Namber - AS Name - Country Code - and if possible, City Name Also the user's IP to be completely erased from the data. To do this, I use an unofficial Cloudflare service that may change or be restricted at any time: https://speed.cloudflare.com/meta <https://speed.cloudflare.com/meta> I am aware that many other tools and projects need this. Because either their backend server is blocked or other services such as ipinfo, ipconfig, avast, etc, are not available in all countries due to sanctions. Therefore, I ask you to provide such a service because you have the most accessibility in the world. Best Regards, Hossein Darvari

1 0

RIPE Atlas, RIPEstat and RIS Quarterly Planning Q2 2022
by Robert Kisteleki 17 Jun '22

17 Jun '22

Dear colleagues, We are now publishing our quarterly plans for RIPE Atlas, RIPEstat and RIS. These are available at: https://www.ripe.net/support/documentation/quarterly-planning The goals of publishing our plans are to be transparent about the work we will be carrying out in the coming months, to get your input on those plans, and to hear what you would like to see us work on going forward. We will provide status updates as the work progresses and add input from the community to the pages. We will also archive previous plans so you can track how we progress with our work. 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

2 1

Join our Open House on the RIPE NCC Internet Country Report – Bulgaria, Moldova and Romania
by Alastair Strachan 14 Jun '22

14 Jun '22

Dear colleagues, We are organising an Open House on the Internet Country Report we recently published on Bulgaria, Moldova and Romania. The event will be on Wednesday, 15 June from 10:00-11:30 UTC. Note that the Open House is not limited to people from these three countries but is open to anyone interested in learning about how the region’s Internet is developing. You can find the country report at: https://labs.ripe.net/documents/292/RIPE_NCC_Internet_Country_Report_Bulgar… <https://labs.ripe.net/documents/292/RIPE_NCC_Internet_Country_Report_Bulgar…> Register for free at: https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-in… <https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-in…> I hope to see many of you at there! Best regards, Alastair Strachan RIPE NCC Communtiy Development Officer

1 0

RIPE IPmap v1.1.0: reverse-dns engine
by Chris Amin 18 May '22

18 May '22

Dear colleagues, In November of last year, we released version 1.0.0 of RIPE IPmap. The main feature of that version was the new latency engine, but we also included a prototype of the “reverse-dns” engine, which used very basic pattern matching of hostnames from PTR to provide location guesses. We are pleased to announce that with v1.1.0 the reverse-dns engine has received a major upgrade, allowing it to provide much better geolocation answers through pattern analysis of the entire IPmap “latency” and “worlds” datasets, with daily analysis performed mostly thanks to the sc_hoiho tool from CAIDA’s scamper toolkit. More information about the new engine, as well as links to information on the sc_hoiho tool and its theoretical underpinnings can be found at: https://ipmap.ripe.net/docs/01.manual/#reverse-dns As well as the new and improved reverse-dns engine, the suggestion system has been improved to better combine results from the various geolocation engines. As always, you can get started with the API with the IPmap docs at: https://ipmap.ripe.net/docs/ Note: this mail was sent to ipmap(a)ripe.net yesterday, but I'm aware that not many people have subscribed to that list (yet). If you're interested in IPmap you can sign up to that list at: https://lists.ripe.net/mailman/listinfo/ipmap Kind regards, Chris Amin RIPE NCC

1 0

MAT-WG Agenda RIPE 84
by Brian Trammell (RIPE) 10 May '22

10 May '22

Greetings, all, Here’s the agenda for MAT-WG at RIPE 84, 12:00-13:00 Wednesday 18 May 2022 in Berlin: * Welcome and Agenda Bashing * Data, Data Everywhere, And Now We Stop to Think (Leslie Daigle, 15 min) * Anomaly Alerting for RIPE Atlas (Wolfram Friele, 10 min) * Flow Monitoring in bwNet (Daniel Nägele, 10 min) * Tools Update (Robert Kisteleki, 15 min) * Co-Chair Welcome and Farewell (MAT-WG chairs, 10 min) Cheers, Brian, for the RIPE MAT-WG co-chairs

1 0

[TMA 2022 PhD School] Network Intelligence and Measurements - SIGCOMM Travel Grants Available
by Giovane C. M. Moura 20 Apr '22

20 Apr '22

TL;DR: * PhD school in Internet Measurements in Network Intelligence * SIGCOMM travel grants available! (please send to your students) * Application deadline: April 22nd, 2022 * School dates: June 27th and 28th, 2022 * Location Enschede, NL. * https://tma.ifip.org/2022/phd-school/ ===== 10th TMA PhD School Network Intelligence and Measurements June 27th and 28th, 2022 Enschede, The Netherlands https://tma.ifip.org/2022/phd-school/ After the interruption of the last two editions of the TMA PhD school due to the COVID pandemic, we are extremely happy to announce the 10th TMA PhD School, organized by the University of Twente in Enschede, The Netherlands, together with the 6th Network Traffic Measurement and Analysis Conference. Under the theme Network Intelligence and Measurements, the 10th TMA PhD School will include 4 tutorials, by 5 distinct lecturers, over a 2 days program. Lectures are accompanied by related practical lab sessions, where students have the opportunity to put into practice learned notions. Thanks to SIGCOMM, we will offer a significant number of travel grants, see the details below. Registration and Deadlines Registrations are now open, you can apply at https://hotcrp.info.ucl.ac.be/tma2022phd/. As the PhD school is popular, we encourage students to register early. Our goal is to admit as many students as possible but we do note that we have limited room availability. Application deadline: April 22nd at 23:59 UTC Tentative decision notification: April 29th PhD School Speakers The list of speakers for the 10th TMA PhD school includes: Anna Brunstorm is a Full Professor and Research Manager for the Distributed Systems and Communications Research Group at Karlstad University. She will familiarize the students with experimentation and measurements methodologies for next generation mobile networks, based on her vast experience on applied research. She will also give hands-on training on testbeds and analytics approaches, stemming from her numerous contributions in projects such as H2020 MONROE, NEAT or 5GENESIS. Emile Aben is a System architect at the RIPE NCC, Netherlands. The lecture will provide an overview of the RIPE Atlas Internet data collection system along with a review of the addressed use-cases. In the related lab students will be asked to design and lunch experiments on the Atlas measurement platform, and to process the collected data to address some given problem. Thymen Wabeke and Thijs van den Hout are research engineers with SIDN Labs (.nl registry). They research how machine learning (ML) applications can increase the security of the internet and the Domain Name System (DNS). The lecture will focus on operationalizing a ML model. There are several challenges involved in this process, such as efficiently collecting ground truth labels, analysts needing to understand model inferences, and monitoring model performance so you know when it fails and needs updating. The lecture will include a hands-on training, so that participants can try out some techniques immediately. Pedro Casas is a Senior Scientist at the Austrian Institute of Technology, where he acts as Research Lead in AI4NETS (AI/ML for Networking). He will present a broad overview on the application of AI/ML to network data analysis problems, including network security, anomaly detection, and Quality of Experience (QoE) monitoring. The lecture provides an introduction to the basics of AI/ML, going from more traditional applications to newer paradigms, including deep learning, graph-based learning, generative models, explainable AI, learning in adversarial scenarios, and more. The ultimate goal of the lecture is to motivate – for the newcomers, and to strengthen – for those already in the field, the research in AI4NETS. The PhD School program will include 4 poster sessions where students can present their own (ongoing) PhD work to other students and to the lecturers, and receive individual feedback from them. Poster sessions will take place during breaks. The program will also include an informal interactive session between students and the speakers, with the explicit goal of fostering “vertical” interaction between students and the speakers, and “horizontal” interaction between the students themselves. Students will have the opportunity to interview the speakers, asking for their expert opinion on general aspects (non-technical) of the current research dynamics in the field of traffic monitoring and analysis (e.g., how they see the prospective development of a particular research topic in the near future, or what are the key ingredients that drive the success of an experimental measurement platform, etc). The PhD school program will include social activities on both days, where students, lecturers and attendees of the main TMA conference will have the opportunity to interact informally. A social dinner would be organized on the second day. How to apply and Travel Grants The price for registration for the TMA 2022 PhD school will be fixed soon and will be below 250 Euro. This fee will be levied on all attending students, also those receiving travel grants, as the travel grant rules from our sponsors require us to ask for a small own investment. In order to apply, please submit the following as a single PDF document: the title and abstract of your poster (in the fields required by the submissions system) a current CV with contact information and e-mail address a short personal statement, including: i) a description of the research subject followed by the student, and (ii) information that the applicant feels is relevant to support his/her application, e.g., why the PhD School attendance is important to the applicant’s research and career development; In case you also want to apply for optional travel support, we ask you to also include: a letter from your advisor which should: (i) confirm the applicant’s good standing in the institution; (ii) explain why the applicant would benefit from attending the TMA PhD School the estimated expenses for attending the TMA PhD School (total, and breakdown by travel and lodging), and an indication of which cost items would need to be covered by the grant; if the applicant will be unable to attend the school without a travel grant, they should explain why this is the case (in this case the advisor’s letter should additionally explain the current funding status of the applicant and why the applicant is in need of the travel grant) The organization will prioritize awarding of travel grants to students who will be unable to attend without a grant, and additionally based on diversity and the region from which the applicant has to travel, to ensure representation from traditionally underrepresented regions. In special cases, where the registration fee is also prohibitive, the organization may decide to waive the fee at its discretion. Any decision made by the organization regarding attendance and awarding of travel grants is final. We note that reimbursements of travel grants may take up to several months to complete. Important Notes Please pay attention to the following details about the student travel grant application and reimbursement process: The School will admit a limited number of students. Students enrolled in PhD study programs will receive preference both in the admission to the School and the travel grant awarding. Students admitted to the school are encouraged to attend the TMA conference. We expect a student travel grant will significantly offset air fare and shared hotel accommodation. However, it may not fully cover these expenses, since our desire is to maximize participation by students. In order to obtain reimbursement, you must provide original receipts for air fare and hotel expenses, along with boarding passes (plane or train) for both outbound and inbound journeys. All students participating in the School are required to present a poster describing their research and to actively engage with all activities. Failing to do so will lead to admission rejection. Please provide complete contact information. You will be notified via email, so make sure your email address is correct on your application. Hope to see you all in Enschede for a fantastic TMA PhD School!

1 0

New on RIPE Labs: Detecting DNS Root Manipulation
by Alun Davies 19 Apr '22

19 Apr '22

Dear colleagues, In 2021, when reports emerged that hosts in Mexico were unable to reach whatsapp.net, it was determined that middleboxes were to blame. These devices were intercepting the queries to the root instance hosted in China and sending a bogus reply. Taking this as their starting point, Qasim Lone and colleagues have been investigating the prevalence of middleboxes using RIPE Atlas: https://labs.ripe.net/author/qasim-lone/detecting-dns-root-manipulation/ Best regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

MAT WG chair selection
by Brian Trammell (RIPE) 15 Apr '22

15 Apr '22

Greetings, all, It has been a while since we have run our chair selection process (see https://www.ripe.net/ripe/mail/archives/mat-wg/2015-February/000559.html) as we look to returning to in-person meetings in Berlin it occurred to us that now would be a good time to do so. To save you the fun of clicking through to the list archives, the process is as follows: > 1. A call for interested parties is made on the WG mailing list at three yearly intervals, or as needed > 2. Interested parties have 2 weeks to make their interest known via the mailing list > 3. The MAT-WG chairs issue a call for discussion as per normal. WG members express their approval or otherwise of the presented candidates. > 4. After two weeks the chairs declare consensus as they would do for a policy proposal Following steps 1 and 2 of this process: If you are interested in co-chairing MAT WG, please make your intent known by sending a message to mat-wg(a)ripe.net by Monday 28 March 2022; once we have a candidate list, wi’ll issue a call for discussion on the list. Many thanks, cheers, Nina + Brian (MAT WG chairs)

10 20

Fwd: MAT WG chair selection
by Brian Trammell (RIPE) 06 Apr '22

06 Apr '22

> Begin forwarded message: > > Hi Luuk, > > (As chair, running the consensus process) No, there is no reason not to go with three co-chairs for the next term; indeed (as a chair, stepping down, who has had fun with meeting logistics, and is an SRE at $dayjob) three chairs would in some ways be preferable, as it gives n+1 chair redundancy in addition to a breadth of perspective on measurement topics. > > Cheers, > > Brian > >> On 4 Apr 2022, at 09:55, Luuk Hendriks <luuk(a)nlnetlabs.nl> wrote: >> >> Hi all, >> >> On Tue 29 Mar 2022, 20:48, Brian Trammell (RIPE) wrote: >>> The call for interested parties is now closed. Thank you to our candidates (in order of received statement of interest): >>> >>> - Massimo Candela >>> - Stephen Strowes >>> - Nina Bargisen >>> >>> This opens the call for discussion on the candidates; the current chairs will call consensus on 12 April. >> >> >> Without a doubt both Massimo and Stephen are great candidates for new >> co-chairs. Perhaps this was discussed before, but is there a reason to >> not go with three co-chairs for the next term(s)? >> >> >> luuk >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/mat-wg >

2 1

Re: [mat-wg] MAT WG chair selection
by Victor Naumov 03 Apr '22

03 Apr '22

Hi All, I worked with Massimo and Stephen, both are excellent candidates. However, in the past I had a chance to work with Massimo closely on the RIPE Atlas, and I know his passion towards MAT topics, so if it goes down to a single vote my preference goes to him. On Mon, Mar 14 13:45 CET 2022, Massimo Candela <massimo(a)ntt.net> wrote: > > Dear working group, > > > On 14/03/2022 10:14, Brian Trammell (RIPE) wrote: > > If you are interested in co-chairing MAT WG, please make your intent known by sending a message to mat-wg(a)ripe.net by Monday 28 March 2022; once we have a candidate list, wi’ll issue a call for discussion on the list. > > > I'm a big fan of the MAT wg, see picture attached :). I've been to > almost all of the MAT sessions since RIPE66, and I've given > presentations in many of them. > > This wg is a fantastic venue for exchanging ideas, tools, and research > findings, and I appreciate the Chairs' dedication throughout the years. > > I would like to give back to the wg. So, I'm volunteering as a co-Chair. > > BIO: I'm an engineer focused on developing applications to facilitate > day-to-day Internet operations. I'm involved in the Internet community > as a frequent presenter, and in various community projects. In the last > 10 years I developed and contributed to tools that are commonly used by > network operators and researchers to monitor certain aspects of the > Internet performance (e.g., BGPalerter, BGPlay, RIPE Atlas, RIPE IPmap, > DNSMON, Tracemon, and more). I was a research collaborator in the > Compunet team of Roma Tre University. After, I worked in the R&D team of > the RIPE NCC. Currently, I'm contributing to the automation and > monitoring of the NTT Global IP Network. > > I'm particularly interested in network measurements, monitoring, data > analysis, and data visualization. > > > Ciao, > Massimo wbr Victor Naumov

4 3

Re: [mat-wg] mat-wg Digest, Vol 118, Issue 2
by Mandalari, Anna Maria 03 Apr '22

03 Apr '22

Hi, I support Massimo! Anna — Dr Anna Maria Mandalari Research Associate Institute for Security Science and Technology Imperial College London https://www.imperial.ac.uk/people/anna-maria.mandalari On 2 Apr 2022, at 11:00, mat-wg-request(a)ripe.net<mailto:mat-wg-request@ripe.net> wrote: ******************* This email originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for this address. ******************* Send mat-wg mailing list submissions to mat-wg(a)ripe.net<mailto:mat-wg@ripe.net> To subscribe or unsubscribe via the World Wide Web, visit https://lists.ripe.net/mailman/listinfo/mat-wg or, via email, send a message with subject or body 'help' to mat-wg-request(a)ripe.net You can reach the person managing the list at mat-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of mat-wg digest..." Today's Topics: 1. Re: MAT WG chair selection (Randy Bush) ---------------------------------------------------------------------- Message: 1 Date: Fri, 01 Apr 2022 15:16:11 -0700 From: Randy Bush <randy(a)psg.com> To: Measurement Analysis and Tools Working Group <mat-wg(a)ripe.net> Subject: Re: [mat-wg] MAT WG chair selection Message-ID: <m2sfqwjvpw.wl-randy(a)psg.com> Content-Type: text/plain; charset=US-ASCII i know and respect the really good work of massimo and stephen. but i am trying to think who is more likely to breathe some life into this somewhat soggy working group. and i would suggest that this is the primary criterion we should stress. aside from a strong technical contribution, maybe massimo has shown more leadership in this space. randy ------------------------------ Subject: Digest Footer -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/mat-wg ------------------------------ End of mat-wg Digest, Vol 118, Issue 2 **************************************

1 0

New on RIPE Labs: Bias in Internet Measurement Infrastructure
by Alun Davies 28 Mar '22

28 Mar '22

Dear colleagues, In this new article on RIPE Labs, Pavlos Sermpezis talks about analysing bias in the Internet measurement infrastructures like RIPE Atlas and RIPE RIS. Are these infrastructures biased? How much of a problem is it if they are? What does bias even look like here? Find out more: https://labs.ripe.net/author/pavlos_sermpezis/bias-in-internet-measurement-… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

RIPE NCC Open House: Feedback on our Unified User Interface
by Michela Galante 28 Mar '22

28 Mar '22

Dear colleagues, On Wednesday 6 April from 10:00 to 11:30 UTC, we invite users of RIPE Atlas, RIPE Database, RIPE Labs, RIPE NCC Academy, LIR Portal, RPKI and RIPEstat to give us feedback on our unified user interface. This Open House session will focus on the user interface that was launched in 2020. Our goal is to unify the user experience across all platforms to make it easier and faster for users to navigate our services. You can register for the event at: https://meeting-registration.ripe.net/meeting-pub/registration?0&meetingId=… More information is available on our website: https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-fe… Best regards, Michela Galante RIPE NCC

1 0