Adding Filter bottom table based on selected country/time range in Global Report

[mohamedawnallah]

Hey @romain-fontugne,

I've created a simple diagram depicting the flow and design of the filter bottom table, which you can view in the attached image.

I want to initiate a discussion on a couple of points:

1. Severity Counts as Columns: Should we consider adding columns for severity counts, such as "Low Severity Counts," "Medium Severity Counts," and "High Severity Counts"? This could enhance data visibility and analysis.

2. Filtering Based on Severities: IMHO, if we decide to add severity columns as discussed in point 1, implementing the "Filtering Based on Severities" feature would become redundant.

I'm eager to hear your thoughts and opinions on these matters! Please feel free to share your insights.

Thank you!

[romain-fontugne]

Hey,
Thanks for initiating this discussion.

The goal of the tables is to show more information that we currently have in the charts. For example, the current charts hide the second 'asn' information that is available in hegemony alarms and the 'endpoint_name' for network_delay alarms.

So I think we should try to expose as much data as we can in the table. I see two options:
1- we can try to have one big table with more or less 'raw' data from the APIs
2- Or have one table per alarm type (we can reuse the tables we already have below the charts for IHR alarms) which will be more tailored for each alarm type.

option 2 is surely more work, but I think it is also a bit more user-friendly

[mohamedawnallah]

In option 2 that means every time we integrate a new alarm type/data source we have to make new N tables (equal to the number of the new alarm types). I think this kind of one-to-one relationship would be more cluttered over time. What do you think?

[mohamedawnallah]

Another suggestion. Currently, we have two tables in Hegemony and Network Delay Alarms. We can make use of the one-to-one relationship between these tables and alarm types within a single view, similar to the IODA Dashboard. The IODA Dashboard offers three views: Country View, Region View, and ASN/ISP View, allowing users to switch between them while utilizing the same space. I believe this approach would provide us with considerable flexibility regards the alarms table, for example, incorporating switches for various alarm types such as Hegemony Alarms, Network Delay Alarms, MOAS Alarms, Sub-MOAS Alarms, DEFCON Alarms, Fake PATH Alarms, PING Alarms, BGP Alarms, and UCSD Telescope Alarms. Implementing these switches in this manner would help us save a significant amount of space on the Global Report Page, add specific aggregated attrs columns for example average deviation metric, and create a more user-friendly and extendable interface. What do you think?

[mohamedawnallah]

Additionally, this approach would facilitate the integration of the Network Disconnection Alarms Integration. By adopting this method, we can potentially combine the Network Disconnections World Map with our existing World Map for Aggregated Alarms and incorporate the associated table seamlessly.

[romain-fontugne]

Yes, that's a very good idea. I usually look at one type of alarms at a time because it is more intuitive to look at them separately. Having different views would help for that too

[mohamedawnallah]

@romain-fontugne I started to work on option 2 by making a reusable table for each alarm type. Now I'd like to know what you expect from each alarm-type table, the order of columns (if it matters), and if any aggregated metrics e.g. (Median Deviation, ... etc.) would be helpful to include.

I've outlined a sample table for each alarm-type table:

Hegemony Alarms Table

Origin AS	AS	Origin AS Name	AS Name	Origin Country	Origin Country Code	Country	Country Code	Data Source	Nb. Alarms	Median Deviation
AS262714	AS28271	Empresa Municipal de Informatica sa	DataCorpore Servicos e Representacoes	Brazil	BRA	United States	USA	IHR	10	35.21

Network Delay Alarms Table

Startpoint AS	Endpoint Type	Startpoint AS Name	Endpoint Name	Startpoint Country	Startpoint Country Code	Endpoint Country	Endpoint Country Code	Startpoint Address Family	Endpoint Address Family	Data Source	Nb. Alarms	Median Deviation
AS262714	CT	DataCorpore Servicos e Representacoes	Amsterdam, Noord-Holland	Brazil	BRA	Netherlands	NLD	IPv4	IPv4	IHR	50	28.14

Moas Alarms Table

AS Victim	AS Attackers	Data Source	Nb. Alarms	Nb. Ongoing Alarms	Nb. Trust Worthy Alarms	Nb. Prefixes	Prefixes	Largest Sub-prefix	Median Duration	Median Suspicion Level
AS269534	AS262714, AS262814	GRIP	220	13	20	2	154.6.28.0/24, 149.18.106.0/24	154.6.28.0/24	30 min	60

Submoas Alarms Table

AS Victim	AS Attackers	Data Source	Nb. Alarms	Nb. Ongoing Alarms	Nb. Trust Worthy Alarms	Nb. Prefixes	Prefixes	Largest Sub-prefix	Median Duration	Median Suspicion Level
AS269534	AS262714, AS262814	GRIP	220	13	20	2	154.6.28.0/24, 149.18.106.0/24	154.6.28.0/24	30 min	60

Defcon Alarms Table

AS Victim	AS Attackers	Data Source	Nb. Alarms	Nb. Ongoing Alarms	Nb. Trust Worthy Alarms	Nb. Prefixes	Prefixes	Largest Sub-prefix	Median Duration	Median Suspicion Level
AS269534	AS262714, AS262814	GRIP	220	13	20	2	154.6.28.0/24, 149.18.106.0/24	154.6.28.0/24	30 min	60

Edges Alarms Table

AS Victim	AS Attackers	Data Source	Nb. Alarms	Nb. Ongoing Alarms	Nb. Trust Worthy Alarms	Nb. Prefixes	Prefixes	Largest Sub-prefix	Median Duration	Median Suspicion Level
AS269534	AS262714, AS262814	GRIP	220	13	20	2	154.6.28.0/24, 149.18.106.0/24	154.6.28.0/24	30 min	60

Ping Alarms Table

AS	AS Name	Country	Country Code	Data Source	Alarm Type	Nb. Alarms	Median Deviation	Median Historical Deviation
AS28271	DataCorpore Servicos e Representacoes	Brazil	BRA	IODA	Active Probing (ping-slash24)	110	31	21

BGP Alarms Table

AS	AS Name	Country	Country Code	Data Source	Nb. Alarms	Median Deviation	Median Historical Deviation
AS28271	DataCorpore Servicos e Representacoes	Brazil	BRA	IODA	110	31	21

UCSD Telescope Alarms Table

AS	AS Name	Country	Country Code	Data Source	Alarm Type	Nb. Alarms	Median Deviation	Median Historical Deviation
AS28271	DataCorpore Servicos e Representacoes	Brazil	BRA	IODA	Network Telescope (ucsd-nt and merit-nt)	110	31	21

I'd like to discuss the aggregated metric for deviation across alarm types:

IHR Deviation Aggregated Metric

I've found that in the IHR Global Report, we're using Average Deviation. What about using the Median instead so that It would withstand against outliers if any?

Grip Deviation Aggregated Metric

I'd suggest using Median here also to withstand against the outliers if any.

IODA Deviation Aggregated Metric

They are using the Median method by default.

[romain-fontugne]

Thanks, the tables look good to me.
Just a few suggestions:

1. I think we don't need the data source in the table (the user probably already knows that when selecting the type of alarm)
2. I'd like to change the order of the columns so that information from one entity are altogether. For example, for hegemony alarms we can have Origin AS, Origin AS Name, Origin Country Code next to each other then AS, AS Name, Country Code
3. if possible it would be nice to keep the overview switch we currently have in global report tables. This is very handy and actually we already have a component to visualize IODA data too. (we have nothing for GRIP so we could deactivate the overview or put a link to GRIP website)

[mohamedawnallah]

Thank you for the feedback. Let's proceed by adding the overview switch after making a PR for the alarm-type tables. This approach ensures that adding the overview switch remains decoupled from the main tables.