Frequently Asked Questions
  1. How can I provide corrections or feedback to information in AS Rank?
  2. How often is AS Rank updated?
  3. How are ASes ranked?
  4. Why is one AS ranked Higher than another AS?
  5. How is prefix and address customer cone defined?
  6. How do you infer peers, providers, and customers?
  7. How do you compute customer cones?
  8. How do I improve my AS ranking?
  9. Can you correct an inaccurate inference if I provide a correction?
  1. 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.
  2. 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.
  3. 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).
  4. 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.
  5. 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.
  6. 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.

  7. 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.

  8. 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.