REX Usage Report

REX, the RIPE NCC's prototype Resource Explainer service has been collecting usage statistics ever since we made the service publcy available. Here's a short analysis on what we've seen so far in terms of usage. Note that we've excluded requests coming from the RIPE NCC's own network, in order to avoid some of the skew our own tests might have introduced.

REX clients

In the last four weeks we could observe roughly 4400 requests towards REX. The following graphs show the distribution of requests using IPv4 and IPv6, in absolute numbers, in unique numbers, and in relative percentages, respectively.

Since RIPE Labs is really young yet, it's easy to see that so far the promotional events generate the most interest. In particular, the effect of the RIPE59 meeting in Lisbon, and the official launch of RIPE Labs on 6 October is clearly visible.

It's interesting to note that users of REX are generally more IPv6 capable than the average Internet users - roughly 20% of the queries are using IPv6, and on 6 October we actually saw more IPv6 than IPv4 clients!

REX queries

REX explains different aspects of IPv4 resources. Here's a breakdown on how often have the different pages been accessed:

• index/opening page: 14%
• responsible RIR: 8%
• resource holder: 9%
• routing: 26%
• DNS: 9%
• activity: 10%
• blacklists/spamlists: 13%
• GEOIP: 10%
• printable: 1%

The default setting in REX is to start the report with the routing information page, which might be the reason why that page has the most views. Or, it may simply be the most interesting for users... after all, we don't know about any other service that give you a 10 year overview of routing data in just 2 seconds on the average!

Talking about defaults: on the index page, REX offers some help to the user by trying to figure out the user's network, by looking up the IPv4 prefix related to the user's IP address. We figured that many times people will be interested in the report about their own network, so this is a good default. It turns out that people are using this feature in roughly 30% of the cases.

Finally, an interesting background information: since, as you can imagine, compiling such a report is far from trivial (as sometimes you have to search in billions of records), each page tries to estimate how much time is needed to finish with the contents. If this guesstimate is above a second or so, then we produce a "please wait" page, until the real page is ready. Since it's always better to positively surprise the users, and we didn't have enough real-life statistics yet to calibrate this feature, our guesstimates are usually way worse than the actual loading times. In fact, our overall average guesstimate so far has been 18 seconds, while the overall average page load time was about 2 seconds. So there's still room for improvement!