Opened 15 months ago

Closed 5 months ago

#23713 closed enhancement (implemented)

Expand parameters and fields around AS number and names

Reported by: cypherpunks Owned by: karsten
Priority: Medium Milestone: Onionoo 1.16.0
Component: Metrics/Onionoo Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: irl Sponsor:

Description

Currently one can search for relays in a specific AS with the as parameter,
but you can not search for all relays with a given as_name (big organizations have multiple ASes).

background:
I'd like to make the entries in this table clickable atlas URLs
https://nusenu.github.io/OrNetStats/#top-10-autonomous-system-names-by-cw-fraction

Note: as_names usually contain spaces

Child Tickets

Change History (11)

comment:1 Changed 14 months ago by karsten

Owner: changed from metrics-team to karsten
Status: newaccepted

Sounds useful to me. We should probably implement #21366 first to fully support AS names containing spaces. But other than that I don't see any major problems.

For the sake of consistency between field names and parameter names we might consider renaming the "as_number" field to just "as". That's also more consistent with "country" for the country code and "country_name" for the country name. This change would require a major version bump, but in this case we could easily include both fields for a few months until clients are updated. So, adding an "as" field would be the minor protocol change and removing the "as_number" field would be the major protocol change. Or maybe the latter would also be a minor change, because the field is optional. Anyway, something to consider and somewhat related to this feature request.

comment:2 Changed 14 months ago by irl

I think as and as_name are both fine, the _number does look redundant to me.

nusenu: I would encourage you though, to consider making the URLs link to as:X as this would be a more accurate search, especially as AS names would have to be a partial string search to be useful to end users. e.g. I might search for OVH instead of "OVH SAS". Exact string searches would only be useful to applications that probably have the AS number already.

comment:3 Changed 11 months ago by karsten

Owner: changed from karsten to metrics-team
Status: acceptedassigned

This still seems like a worthwhile enhancement, but I'm not going to find the time to do it anytime soon. Re-assigning to metrics-team for now.

comment:4 Changed 5 months ago by karsten

Owner: changed from metrics-team to karsten
Status: assignedaccepted
Summary: Add as_name parameterExpand parameters and fields around AS number and names

Alright, I'm planning to make the following two changes as suggested above:

  • Add "as_name" parameter, even though the "search" parameter does not fully support spaces in qualified search terms yet. Fixing that is out of scope for this ticket, and the new "as_name" parameter will be useful without full space support, too.
  • Rename "as_number" field to just "as". It's just a minor protocol update if we keep the "as_number" field for a few months.

Similar to #23914, I'd like to make another change while touching this part of the code:

  • Support comma-separated list of AS numbers in "as" parameter.

I'm moving this ticket to my list.

comment:5 Changed 5 months ago by irl

I assume here that the comma-seperated list is to match any (union)? It is possible for a prefix to be announced by multiple AS in BGP and a future data source might provide all the ASs an IP address may be found in, not just one, so a match on all (intersection) is also a legitimate use case.

The first two bullet points look good.

comment:6 in reply to:  5 ; Changed 5 months ago by karsten

Replying to irl:

I assume here that the comma-seperated list is to match any (union)? It is possible for a prefix to be announced by multiple AS in BGP and a future data source might provide all the ASs an IP address may be found in, not just one, so a match on all (intersection) is also a legitimate use case.

Well, my (possibly flawed) plan was to use comma-separated lists for unions (as=1,2,3 for relays in any of those three ASes) and repeatedly stated parameters for intersections (as=1&as=2&as=3 for relays announced by all three ASes).

The first two bullet points look good.

Okay, great, I already started writing some code for them that I'll bring here for review as soon as it's ready.

comment:7 in reply to:  6 Changed 5 months ago by irl

Replying to karsten:

Replying to irl:

I assume here that the comma-seperated list is to match any (union)? It is possible for a prefix to be announced by multiple AS in BGP and a future data source might provide all the ASs an IP address may be found in, not just one, so a match on all (intersection) is also a legitimate use case.

Well, my (possibly flawed) plan was to use comma-separated lists for unions (as=1,2,3 for relays in any of those three ASes) and repeatedly stated parameters for intersections (as=1&as=2&as=3 for relays announced by all three ASes).

This seems OK. I think Relay Search would have to explain this in the documentation as well as explaining it in Onionoo, but it's not ridiculously complicated to understand.

The first two bullet points look good.

Okay, great, I already started writing some code for them that I'll bring here for review as soon as it's ready.

Cool.

comment:8 Changed 5 months ago by karsten

Status: acceptedneeds_review

Please carefully (it was really hot here today) review the last three commits 225b875, 4e281b2, and c5eb9d0 in my task-23713 branch. Thanks!

comment:9 Changed 5 months ago by irl

Reviewer: irl

comment:10 Changed 5 months ago by irl

Status: needs_reviewmerge_ready

This looks good to me.

comment:11 Changed 5 months ago by karsten

Milestone: Onionoo 1.16.0
Resolution: implemented
Status: merge_readyclosed

Great, merging! Adding to the Onionoo 1.16.0 milestone so that we don't forget to document the change in metrics-web when we put out the release. Closing. Thanks!

Note: See TracTickets for help on using tickets.