Re: [mat-wg] [routing-wg] RIPE Labs post: Does The Internet Route Around Damage?
Hi Simon, Thanks for your suggestions for further research. More inline :) On 2023-11-29 17:26, Simon Leinen wrote: We analysed last week's AMS-IX outage from the perspective of RIPE Atlas, to shed some light on the question if the Internet routes around damage. Our analysis is here: https://labs.ripe.net/author/emileaben/does-the-internet-route-around-damage-edition-2023/ Great analysis, thanks! A few questions/observations/suggestions for further analysis by aspiring routing researchers... On IXP-less backup paths: "The main alternative in our data are paths without IXP. This could be a direct lateral peering that is not IXP-mediated, or using transit instead of the IXP." Would it be possible to distinguish between those cases? Maybe by looking at any additional ASes that show up in the new paths, and trying to detect provider/customer relationships using some known approach. Yes, I'm curious about that too. For ease of analysis I don't do AS lookups (just IXP LAN lookups) for this type of use-case so analyses take significantly less time to run. Adding AS-lookups would open up the type of analysis you mention. Intuitively the second case seems more "normal", because if you had a direct peering (PNI), then why would you have preferred AMS-IX in the first place? But of course it's possible that those non-IXP-mediated peerings are over slower links or otherwise inferior. Thanks for that intuition, that helps trying to understand this esp. for individuals like me who don't configure BGP interdomain routing every day. On the belated NL-IX rerouting: This indeed looks like an intentional change of routing preferences; looking at the steep/vertical increases, probably done by a single or a few large providers. Now I'm of course very curious who did this (and was able to shift about 15% of all Atlas traceroutes around :-). Or it is an issue of the bias of the probes and destinations that I used for this analysis. This is an issue I'm currently looking into. Happy to share more details about the analysis. kind regards, Emile Aben 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/mat-wg
Re: [mat-wg] [routing-wg] RIPE Labs post: Does The Internet Route Around Damage?
Hi Daniel, On 2023-11-29 18:27, Daniel Karrenberg wrote: Thanks for the great work as usual. Would it be possible to extend it by looking at measurements other than traceroute that could get us even better insights into what proportion of packets did not get there and how quick the rerouting happened. I assume that adding other measurement types would significantly increase the number of data points and the time granularity. Thanks for the suggestion. For the error-rate part the analysis doesn't need traceroute, so anything that measures end-to-end between the selected source/destination pairs can indeed be used as an estimator for the error-rate. Most obvious would be pings that run more frequently than the traceroutes on RIPE Atlas typically. kind regards, Emile Aben RIPE NCC To amplify: i am interested in the dark red areas here. Daniel --- Sent from a handheld device. On 29. Nov 2023, at 13:54, Emile Aben wrote: Dear colleagues, We analysed last week's AMS-IX outage from the perspective of RIPE Atlas, to shed some light on the question if the Internet routes around damage. Our analysis is here: https://labs.ripe.net/author/emileaben/does-the-internet-route-around-damage-edition-2023/ Kind regards, Emile Aben 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/routing-wg -- 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
[mat-wg] RIPE Labs post: Does The Internet Route Around Damage?
Dear colleagues, We analysed last week's AMS-IX outage from the perspective of RIPE Atlas, to shed some light on the question if the Internet routes around damage. Our analysis is here: https://labs.ripe.net/author/emileaben/does-the-internet-route-around-damage-edition-2023/ Kind regards, Emile Aben 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/mat-wg
[mat-wg] RIS beacons
Dear colleagues, Following on from discussion during the MAT WG session at RIPE 86, I wrote up a RIPE Labs article looking at why RIS beaconing is useful and how we can improve the existing setup to do more: https://labs.ripe.net/author/emileaben/ris-beaconing-shining-a-light-on-bgp-dynamics/ kind regards, Emile Aben 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/mat-wg
[mat-wg] The Resilience of the Internet in Ukraine - One Year On
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-ukraine-one-year-on/ kind regards, Emile Aben 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/mat-wg
[mat-wg] Improved timeliness of RIS dump files
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. -- 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
Re: [mat-wg] jedi.ripe.net unresponsive
Hi Denis, I can confirm that the service is not available from outside of the NCC. We are migrating this service, and older versions of the ixp-country-jedi visualisations are still available at http://sg-pub.ripe.net/emile/ixp-country-jedi/history/ This service doesn't have production status, so it's unlikely I can get it back up running outside of office hours. kind regards, Emile Aben RIPE NCC Op 2021-11-20 om 18:19 schreef Denis Fondras: curl -vhttps://jedi.ripe.net/ 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
[mat-wg] RIPE Atlas measurements documentation wiki
Dear all, We're trying something new! We have a part of our public RIPE Atlas github pages dedicated to documenting RIPE Atlas measurements better. Read all about it, including an example around measuring RPKI repositories, of how this is useful here: https://labs.ripe.net/Members/emileaben/tracking-rpki-repository-performance-with-a-ripe-atlas-measurement-bundle or directly go to the 'RIPE Atlas measurements bundles' wiki: https://github.com/RIPE-Atlas-Community/ripe-atlas-tips-and-tricks/wiki/Measurement-Bundles Kind regards, Emile Aben RIPE NCC
[mat-wg] Reminder: RIPE NCC Open House: RIS in Focus
Dear colleagues, This is a reminder for the RIPE NCC Open House session on Mon 20 October 10 UTC: RIS in Focus Event details and registration are here: https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-ris-in-focus Hope to see you there, to help us shape our routing information system RIS! kind regards, Emile Aben RIPE NCC
Re: [mat-wg] color blindness and color meaning association
Hi Job, Thanks for your detailed feedback. We'll take that into account in further developments around the tool. Remember this is a prototype (code is available at: https://github.com/emileaben/ixp-country-jedi ). If you have a colour scheme that you think would work better for all cases, you can submit a pull request there. Or we can work together on improving this in a mini-code-sprint sometime soon? Couloring IXPs as green was done because this tool was initially developed in an IXP context; it was presented at EURO-IX and Netnod meetings, and my understanding was that the IXPs would favour paths going over the IXP. I think you are correct in pointing out that this is not necessarily the right thing to do in all contexts. There is already work underway to look at direct vs. indirect interconnections in the tool. Our research intern Petros Gkigkis is going to show a sneak preview of that at the upcoming GRNOG meeting ( https://www.grnog.gr/?lang=en ) this Friday. And of course there will be RIPE Labs articles about further developments like this. So keep an eye out at https://labs.ripe.net :) kind regards, Emile Aben RIPE NCC On 24/05/17 15:15, Job Snijders wrote: > Hi all, > > TL;DR - red/green color palettes should be avoided in data > visualiations, please pick something else! > > Yesterday I saw Christian Teuschel present on the "Jedi" tool at SINOG, > and two things stood out: > > A) the data visualisations do not attempt to accomodate for people >who are color blind, in fact, the worst colors possible were >picked > > B) by using using common traffic light colors (green, orange, red) >an implicit judgement is made on the meaning of the data (traffic >crossing an internet exchange was seemingly favored over private >peering) > > To point (A) - red–green color blindness which affect a substantial > portion of the human population. In the US, about 7 percent of the male > population (or about 10.5 million men) and 0.4 percent of the female > population either cannot distinguish red from green, or see red and > green differently from how others do (Howard Hughes Medical Institute, > 2006). There are quite some pointers as to how to design color palettes > which accomodate everyone. > > > http://www.somersault1824.com/tips-for-designing-scientific-figures-for-color-blind-readers/ > http://blog.usabilla.com/how-to-design-for-color-blindness/ > > B) As I understand the "Jedi" tool, it shows matrixes of what traffic > between atlas probes leaves the country, and what traffic remains within > the country - offering insight into a reflection on a country's internal > routing arrangements. I'm a big fan of keeping local traffic local, so > the tool certainly has value. > > However, the tool displays traffic which passes over an IXP within the > country as green, and traffic that says within the country but didn't > cross an IXP as "orange". Since the majority of internet traffic flows > over direct, private interconnections between ASNs, signifying that > traffic as "orange", has the potential to be taken as a "wrong", rather > then as an arbitrary datapoint. I suggest that the Jedi tool either uses > the same color for ixp and non-ixp "within country" traffic (and perhaps > a small icon is used to signify the additional data attribute that an > IXP was observed in the traceroute), or that the jedi tool uses entirely > arbitrary colors that have no inherent meaning like the traffic light > colors do. > > Kind regards, > > Job >
