Re: [mat-wg] Possible new RIS Beacon? (Alternating visible pair)
Dear Ben, On Mon, Jan 22, 2024 at 06:16:28PM +, Ben Cartwright-Cox via mat-wg wrote: > On my seemingly never ending task to find all "stuck" BGP sessions, I > feel like there is an interesting thing that could be done for the > RIPE RIS Beacons, and that is a pair of prefixes that alternate > between being visible and invisible (IE: unannounced). > > I looked at the current estate of beacon prefixes and couldn't find > anything that would fit this use case already. Good news - I think this is already covered by existing beacons! :-) Reading https://ris.ripe.net/docs/routing-beacons/#current-beaconing-setup """ For all beacon prefixes below we have a 2 hour up - 2 hour down schedule. Specifically: Announcements at 00:00, 04:00, 08:00, 12:00, 16:00, 20:00 (UTC) Withdrawals at 02:00, 06:00, 10:00, 14:00, 18:00, 22:00 (UTC) """ Make sure to focus on the 'type = beacon' prefixes, and use 'type = anchor' as baseline: e.g. if 'anchor' is missing but you see 'beacon', something is off. The above beacons have been used in the past to study the zombie phenomenon: https://www.iijlab.net/en/members/romain/pdf/pora_anrw2021.pdf Using these beacons in a semi-real-time fashion in your monitoring service seems productive. Kind regards, Job -- 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] MAT WG chair selection
On 2022-04-13 21:07, Gert Doering wrote: On Mon, Apr 11, 2022 at 01:18:23PM +0200, Brian Trammell (RIPE) wrote: Given these themes, and explicitly asking the community to check my own biases here, I???d like to ask the community if there is support and consensus for appointing all three candidates (Massimo Candela, Stephen Strowes, and Nina Bargisen) as co-chairs of the RIPE MAT WG. Support Seconded. Kind regards, Job -- 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] MAT WG chair selection
Dear all, Disclosure: * Massimo and I are former colleagues at NTT/AS2914 * Stephen and I currently are colleagues at Fastly/AS54113 Seeing fine folk with strong appetite to contribute to the MAT working group: On Mon, Mar 14, 2022 at 01:45:40PM +0100, Massimo Candela wrote: > I would like to give back to the wg. So, I'm volunteering as a co-Chair. > [snip] On Thu, Mar 17, 2022 at 06:44:34PM -0400, Stephen Strowes wrote: > I'd also like to put myself forward to co-chair MAT WG. > [snip] Knowing they both have experience working at the NCC itself, also after having switched tracks subsequently continued to collaborate with NCC staff, and the wider measurements & analytics community; I envision that appointing both as co-chair is worth the group's consideration. Given both their track records and their interest to take on this volunteer work, a unique opportunity is presented to this working group. +1 +1 https://sobornost.net/~job/why_not_both.gif Kind regards, Job -- 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] MAT WG as an advisory body for RIPE NCC tools
Dear all, On Mon, Oct 21, 2019 at 08:49:41PM +, Massimo Candela wrote: > On 17/10/2019 17:27, Brian Trammell (RIPE) wrote: > > I would propose that we make the role of MAT WG in providing > > information and advice to the RIPE NCC's tools teams more explicit. > > In this proposal, mat-wg@ripe.net mailing would be considered a > > primary channel for proposals for features for RIPE Atlas. What other channels exist today? I know of some: - https://www.ripe.net/mailman/listinfo/ripe-atlas/ - hallway discussions - issues filed in github Perhaps other channels exist as well? It is hard to control what channels exist, but we can try to make sure they all are inputs to the same people. I think it is a great idea to confirm with RIPE NCC that their R staff closely monitor all discussions on this mailing list (and engage where they can contribute) as part of their normal duties. Kind regards, Job
Re: [mat-wg] Jedi feedback (Was: color blindness and color meaning association)
Hi emile, On Wed, May 24, 2017 at 04:36:03PM +0200, Emile Aben wrote: > 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? I would love to, but as it stands I can barely dress myself without picking conflicting colors and causing a scene. ;-) I recommend we look for someone (professional or hobbyist) who have more affinity and experience with composing color palettes. > 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. "IXPs would favor paths going over the IXP" - who would've thought! :-) > I think you are correct in pointing out that this is not necessarily > the right thing to do in all contexts. Yes, there will always be challenges in presenting the data in a fair and useful way. In a country with a incumbent monopoly, the incumbent might argue that they are the real internet exchange and that nothing is the matter. If we want to use the tool to further the development of Internet in underserved regions, I think it is important to establish a primary data visualisation goal: "is local traffic locally exchanged?" - then as secondary goals we can perhaps highlight _how_ traffic is exchanged: - is there an intermediate ASN between src and dst? (that might warrant a separate color) - is an IXP used? (that might warrant a symbol on the field in the matrix) - if traffic leaves the country, what happens? Is it exchanged in a foreign country, but ASNs who are also present in the country being measured? (a firm warning might be in order for that one) - if traffic leaves the country, how many ASNs are crossed, is an IXP used, and is the IXP used by the receiving or sending party? - is the source ASN or the destination ASN present in multiple countries? There are quite some dimensions, some of which are trivial to observe (lookup a traceroute IP hop in PeeringDB) and some will require correlation with other data sources such as latency triangulation or BGP views. To me the primary question "is local kept local? is most interesting, and its less relevant whether this happens through a shared layer-2 fabric or direct cross-connects. While an IXP is usually very easy to observe in a traceroute: it is actually one of the less interesting datapoints. IXPs are just one tool in the toolbox, and depending on a number of factors they are an economically sound utility or not. If Jedi can be transformed into a tool to facility with research/reports such as done here https://www.linux.it/~md/text/peering-italy2014.pdf that is where a lot of value can be gleaned. > 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 :) Cheers, will do! Kind regards, Job
[mat-wg] color blindness and color meaning association
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
