distribution of peering sessions carried by core versus non-core routers

distribution of peering sessions carried by routers (core versus non-core)

Question (distilled from nanog (operator) commuinty): How many peering sessions are carried by a `backbone router'?

[CAIDA] answer: The topology/reachability data we have collected suggests that half of all `backbone' routers (i.e., those routers in the largest bi-directionally connected component of the Internet as observed through a month of skitter data, 21nov-18dec 00, from 17 skitter monitors) [if you're lost by now, just go look at the pretty pictures below] have no connections to other ASes than their own.
Another 1/3 have connections to one AS.
8.5% connect to 2 ASes;
The remaining 8% connect to more than 2 ASes.

In our observable Internet topology (including the backbone, see above `observable by skitter' definition), the number of ASes to which an IP address is connected is distributed like:

AS outegree      #IPs  Exceed
     1 		271640  30749
     2 	 	 19363  11386
     3 	  	  4781   6605
     4 	  	  2309   4296
     5 	  	  1302   2994
     6 	    	   810   2184
     7 	   	   511   1673
     8 	   	   373   1300
     9 	   	   234   1066
    10 	   	   183    883
	  ...................
    84 	     	     1      2
   101 	     	     1      1
   108 	     	     1      0
    # Total IPs 302389

Most of these IP addresses (90%) connect to only one AS, and for a huge majority it will be their own AS. (i.e., NOT a peer).


Question: are there some natural knees in the outdegree distribution that set apart `tier's of providers?

[CAIDA] answer: We recognize that the notions of Tier 1 and Tier 2 typically involve phrases such as `transit-free' or `settlement-free', although we have not observed consensus on the exact definition. (There's been a bit of "I know it when I see it" in this space.)

In seeking more objective taxonomy, for most any connectivity measure of AS size, one can see gaps on a logarithmic scale, meaning that ASes naturally split into groups separated by a factor larger than 1.4 (40% difference). These `AS constellations' change from one measure to another, although the top players remain more or less the same. In addition, constellations are sometimes more numerous than just three tiers of providers, so one cannot immediately map them to such tiers.

Example below of how many times a given AS appeared as transit versus originating a prefix.

Figure 1: scatterplot of ASes on UOregon Route View data,
x-axis: number of times this AS appeared as transit for a path.
y-axis: number of times this AS served as origin AS for a path.
ASes with large transit count are individually marked in their own color symbol (upper right)
The other color symbols identify density (number of ASes characterized by that (x,y) value), which is present mostly at 0 transit count, i.e., stub ASes.
Note the 3 groups (tiers) of ASes that naturally emerge:
1 AS way up high (the red square on upper right); 10 a binary order of magnitude below that one; followed by a gap on the transit x-axis scale.

note also that obviously we have all AS names for the 'big guys' below
but not sure folks want those published so we anonymize it.


Figure 2: Different metric below, but also neat that 3 groups (tiers) of ASes naturally emerge from the data, with 1 AS way high, and 8 in the first group below that. Metric is: `how many times this AS appeared in a path from all RouteViews routing tables'


CAIDA's topology measurements (which reveal far more comprehensive coverage than the best available routing table data) also yield compelling tier-ing of ASes just based on quantitative empirical assessment of observed indegree, outdegree, origin vs transit prefix count, etc, using skitter (topology) data with RouteViews to assist with mapping of IP addresses to ASes.

Figure 3 shows gaps between AS groups on a plot that compares coverage of UO RouteViews route table vs skitter topology data. (point: in general, 17 skitter monitors obtain a lot more connectivity information than even 40 diverse core routing tables)


Yet another cool example of natural `tiering' of AS data, but with different metric, we use the number of inbound AS paths (a generalization of indegree) in the figure below.

This graph only uses 16-AS-hop-count path lengths (including self-intersecting paths); the y-axis shows a deviation from the geometric progression, if we compute the same metric for higher (17) hop count paths. (If you didn't understand this paragraph, just note that you could make remarkably good guesses as to the identity of the few ASes on the lower right of the graph.)

if you're not sick of this kind of stuff yet you also might like stub AS analysis
(underlying motivation: does every stub AS really need its own AS number?)


andre broido and kc