Hello, We have been working on refreshing the data and algorithms behind CAIDA's as-rank project. We have published AS-relationships and AS-rankings computed for June 2012. We are currently seeking further validation of our rankings and relationship inferences. http://as-rank.caida.org/ The core of the algorithm is the inference of business relationships. Over the past two years we have received a significant amount of ground truth from operators through the corrections facility provided within AS-rank: in particular we obtained >1200 p2p relationships as a result of our previous algorithm that assigned many more customer/provider (c2p) relationships than ASes had in reality. Our intuition is that network owners are a lot more concerned when we infer a provider relationship that is actually a peer relationship, but are less motivated to validate other inferences. We have validated our algorithm against available ground truth and find our relationship inferences have a 99.1% positive predictive value (PPV) for c2p and 94.7% for p2p for the validation data we have available. Because customer cone computation depends on the accuracy of our c2p inferences, we are reasonably confident in our computed rankings. We are now soliciting further feedback in any shape and form offered. The as-rank website provides the ability for operators to submit corrections through the right-most "corrections" button on an individual ASes information page, and relationships ground-truth is solicited through that channel, if at all possible. Other feedback, on or off-list, would also be appreciated. If you are curious as to why a particular relationship was inferred, please get in contact with me. Some ASes have advised of a particular business relationship in the past, but when I drill down into the data it turns out they have a misconfiguration and are leaking routes to a peer. At a minimum, this might be a useful sanity check for some ASes who may be providing free transit without realising it. In the future, we plan to annotate each relationship with examples as to why it was inferred the way it was, but we have not yet got that far yet. Thanks, Matthew Luckie CAIDA
No IPv6? On Thu, Sep 6, 2012 at 6:46 PM, Matthew Luckie <mjl@caida.org> wrote:
Hello,
We have been working on refreshing the data and algorithms behind CAIDA's as-rank project. We have published AS-relationships and AS-rankings computed for June 2012. We are currently seeking further validation of our rankings and relationship inferences.
The core of the algorithm is the inference of business relationships. Over the past two years we have received a significant amount of ground truth from operators through the corrections facility provided within AS-rank: in particular we obtained >1200 p2p relationships as a result of our previous algorithm that assigned many more customer/provider (c2p) relationships than ASes had in reality. Our intuition is that network owners are a lot more concerned when we infer a provider relationship that is actually a peer relationship, but are less motivated to validate other inferences.
We have validated our algorithm against available ground truth and find our relationship inferences have a 99.1% positive predictive value (PPV) for c2p and 94.7% for p2p for the validation data we have available. Because customer cone computation depends on the accuracy of our c2p inferences, we are reasonably confident in our computed rankings.
We are now soliciting further feedback in any shape and form offered. The as-rank website provides the ability for operators to submit corrections through the right-most "corrections" button on an individual ASes information page, and relationships ground-truth is solicited through that channel, if at all possible. Other feedback, on or off-list, would also be appreciated.
If you are curious as to why a particular relationship was inferred, please get in contact with me. Some ASes have advised of a particular business relationship in the past, but when I drill down into the data it turns out they have a misconfiguration and are leaking routes to a peer. At a minimum, this might be a useful sanity check for some ASes who may be providing free transit without realising it. In the future, we plan to annotate each relationship with examples as to why it was inferred the way it was, but we have not yet got that far yet.
Thanks,
Matthew Luckie CAIDA
participants (2)
-
Matthew Luckie -
Richard Barnes