Thursday, September 4, 2008

Interdomain Internet Routing

Hari Balakrishnan et. al. discuss Internet routing from both a technical and an economic perspective.

He begins his discussion explaining the simple properties of individual commercial entities, called autonomous systems (AS), and how the economics behind their interactions work. Specifically, he discusses the distinction of peering versus transit relationships between ASes and the importance of export and import policies, where the essence is of course "no ISP wants to act as transit for packets that it isn't somehow making money on". Ultimately, routes to paying transit customers are universally exported while routes received from providers are typically selectively exported (exported to paying customers but not peers). Routes are imported given the "customer > peer > provider" priority order, which makes sense monetarily. 

Hari continues the discussion by investigating the technical side of BGP, specifically its three design goals: scalability, policy, and cooperation under competitive circumstances. BGP is essentially a TCP application that communicates differently depending on whether or not the source and destination routers are intra-AS or inter-AS. Eventually, a router determines which routes to use based on a priority of certain attributes regarding the route, a few internal metrics (iBGP versus eBGP) and a tie-break rule. It seems like most routes, however, are really just decided via the LOCAL PREF rule, which essentially reinforces our "customer > peer > provider" ordering, i.e. we should prefer customer over peer and provider routes. 

It is hard to critique informative work like this ... nor do I have any glaring issues. In fact, I think this should definitely be included in the syllabus; it is an easy read and for people like me who had only a superficial understanding of BGP, it was very intriguing.

Hari does discuss a few open problems. The most interesting of which seems like the multi-homing issue. It seems like there has to be better technical solutions than the current solutions, and it might be fun to discuss this problem in more depth in class.

No comments: