The Economics of the Internet

Karl Marx postulated that society, for the most part, is economically motivated. Apparently, the Internet (or what drives it) is not exempted from this.

The lecture “Interdomain Internet Routing”[1] presents the different entities that collectively form the Internet and their varying relationships with one another. These entities are known as “Autonomous Systems” (AS), and these include Internet Service Providers (ISPs) and their customers. One may prefer that these ASs cooperate in a symbiotic fashion for optimum global connectivity, but this is generally not the case. The authors noted that, since most of them belong to commercial enterprises, relationships are dictated by business decisions, resulting to selective routing. I think this is understandable, though, as providing Internet traffic is not cheap, so you want to make sure that your transmission facilities are being utilized towards your own advantage.

ASs use the Border Gateway Protocol (BGP) to exchange reachability information among one another, and this in turn serve as their guide for determining whether they would share their routes with another AS or not. The paper explained that the two most common forms of inter-AS relationships are transit and peering.

Inter-AS Relationships
Transit relationships are the ones shared between providers and customers. Largely a result of business transactions, this gives customers the benefit of being able to access most, if not all, of the destinations available from a provider. Peering, on the other hand, gives two ASs access to only a number of entries in each other’s routing tables. After all, this type of relationship is usually not settled financially (as the saying goes, we always get our money’s worth), and it is more of an agreement between two parties. The connectivity that peering provides may seem limited, but its real value lies in the semi-mutual benefit that involved ASs may reap. An AS on one side of a peering relationship save on transmission cost by being able to send their packets using their peer’s routes that are connected to their customers, thus preventing the need to transit with a higher-tiered ISP. This, of course, in exchange for doing the same thing for their peer. I described this as semi-mutual because, as the paper indicated, the common traffic ratio between peering ASs is 4:1, and that is already considered as not highly asymmetrical. Maybe this is because it’s hard to find two AS pairs that share almost similar amount of customers belonging on the other end. Still, one is getting 75% more than the other! Well, if it works for them, then it works for them (but one is luckier).

Exporting and Importing Routes
The paper also discussed the exporting and importing rules applied by an ISP to its neighbors. In either case, the customer is always the king, since customer traffics provide ISPs revenues. Other rules for exporting and importing are simply a matter of making sure that they provide routes for traffic that would benefit them and that they deny any route that would only make them carriers of packets that solely serve the interests of their neighboring ISPs.

BGP
The succeeding sections of the paper discussed the BGP in a fairly detailed manner. I won’t reiterate everything here since things are already explained (and it’s a long one), so I’ll just mention some parts where I can place my insights.

One interesting section there is the communication of BGP speaking routers within an AS. In this setting, iBGP is used by the communicating routers (as opposed to eBGP, which is used for speaking with routers belonging to other ASs) in order to disseminate among themselves routes learned from other ASs. The problem lies, though, in the seemingly trivial task of spreading information. The first solution they used is the linking of every eBGP router with all other routers in an AS through iBGP sessions, resulting to a full mesh topography. In graph theory lingo, you can think of this as something similar to a clique graph, which contains |v|(|v| - 1)/2 edges, where |v| is the number of vertices in the graph. In this representation alone, n routers would mean Θ(n2) iBGP sessions maintained within an AS. Worse, clique graph is not a very accurate representation because there are internal nodes inside the graph, resulting to a larger value of e(e - 1)/2 + ei iBGP sessions, where e is the number of eBGP routers and i is the number of iBGP routers. If you’re concerned with scaling, this is not a good sign.

Other possible solutions involve the use of confederations and route reflectors. Confederation is a form of clustering of routers in such a way that a cluster is considered as a single entity[2]. Actually, based on rfc3065, these are mainly applied on ASs, but this model fits well within an AS too, plus there wouldn’t be any problems with regards to the AS_PATH value. Route reflectors, on the other hand, are routers that are responsible for passing routing information for their whole domain (an AS or confederation). Combining these two concepts, what happens is that information is passed among confederations instead of individual routers, then each confederation may have its own reflector that would spread information within its domain. This represents a cascading effect, somewhat similar to a tree structure. Sounds like an interesting idea. But come to think of it, isn’t this also the same way the Internet is structured, just on a larger scale?

Another interesting issue about BGP is the MED attribute. It can be used either as a “magnet” or a “turn-off” (sorry, I couldn’t think of a better term) for traffic. What if two neighboring ASs both wanted or disliked to carry certain packets, and they kept on adjusting their MED values until they reached to a point where they have similar values, would this result to a stalemate? Of course, I’m sure there’s a provision for this, and this attribute is not even always used. But imagine the hypothetical scenario of two Tier-1 ISPs not being able to come up with an “agreement” on a certain data transmission because of their MED values (or even other attributes) and this caused the Internet to temporarily hang. That would be, um, strange.


References:
[1] H. Balakrishnan and N. Feamster. Lecture 4: Interdomain Internet Routing.
[2] http://tools.ietf.org/html/rfc3065