Frequently Asked Questions
- How can I provide corrections or feedback to information in AS Rank?
Please send an email to
asrank-feedback@caida.org with your name,
organization, and corrections. If you are providing corrections for an organization, please provide
the AS Rank URL that points to that country along with any change to its name, country, or set of
operating ASes. For individual ASes, we accept corrections on the set of ASes which are their providers,
peers, or customers.
- How often is AS Rank updated?
We aim for a monthly update update to the topological data.
We update the Organization name and country roughly every three months,
but the project has no dedicated funding, so it is best effort.
- How are ASes ranked?
We rank ASNs by the number of ASes in the customer cone. To break ties, we sort by the number of prefixes
if the number of IP addresses in the customer cone, then the global AS degree (number of AS neighbors), and finally by transit degree.
Formally, an AS's rank is equal to one (1) more than the number of higher-ranked ASes (so that the
highest ranked AS has rank 1).
- Why is one AS ranked Higher than another AS?
An AS is ranked higher than another AS, if that AS has a larger customer
cone. The customer cone size is considered in order of the number of ASes, prefixes, and addresses. A
customer cone size is the number of ASes seen in unfiltered paths after a link between the target AS
and one of its customers. If AS A is ranked higher than AS B, then we saw more ASes in paths after a
link between AS A and AS A's customer than we did in paths after a link between AS B and AS B's
customer.
- How is prefix and address customer cone defined? How does this affect overall ranking?
An AS's prefix-level customer cone is the union of the prefixes announced by all
ASes in its AS customer cone (which by definition includes the AS itself). The address-level customer cone
is the set of addresses covered by the prefixes in the prefix-level customer cone.
- How do you infer peers, providers, and customers?
We infer an AS's customers, peers, and providers using
the method defined in section 4 of our IMC 2013 paper:
"
AS Relationships, Customer Cones, and Validation".
It makes three assumptions: (1) an AS enters into a provider relationship to become
globally reachable, (2) there exists a peering clique of ASes at the top of the
hierarchy, and (3) there is no cycle of p2c links. The algorithm works top-down, starting
with paths that cross the peering clique at the top of the hierarchy,
inferring p2c links when it observes paths that suggest a transit relationship.
- How do you compute customer cones?
We describe our algorithm for computing the customer cone
here
and (in excruciating detail) in our IMC 2013 paper:
"
AS Relationships, Customer Cones, and Validation".
Our inference algorithm relies on public BGP data from RouteViews and RIPE RIS. Importantly, per the figure, we do not infer an AS's
customer cone based on paths observed directly from that AS. Rather, we use paths observed from the peers and providers of the
AS in question. The reason for this filtering is that an AS selectively announces paths: to its customers, it may announce everything,
but to its "upstream" providers or peer ASes, it will announce only paths to its customers. Thus, we need to observe a
path through one of the AS's inferred providers or peers in order to infer the destination prefix (and its origin AS) is in the customer cone of that AS.
- How do I improve my AS ranking?
Our inference algorithm relies on public BGP data from RouteViews and RIPE RIS.
The best way to increase the number of ASes we can observe in your customer cone is to make those ASes more visible to these
public route collector projects. That is, announce more AS paths to your providers or peers who contribute feeds to
RouteViews
or
RIPE NCC RIS.
- Can you correct an inaccurate inference if I provide a correction?
We can
change an inference for an existing interconnection relationship if you provide
us ground truth, but we cannot
add interconnections that we do not observe in BGP.
In other words, we can update our Operator Feedback database with a list of peers and customers you provide, but that does
not guarantee that the interconnections will appear in our observed set of relationships -- only that if the interconnection
does appear, it will match the relationship you provided.
We are open to other ideas to improve the accuracy of our inferences, but sustainability of
the project requires an automated, scalable method to infer the cone based on publicly available data.
Please email comments or questions to asrank-feedback@caida.org.