NIRA is a new inter-domain routing architecture that allows a sender to encode the route a packet should take to arrive at its destination. Currently a sender can only encode the destination of a packet; the routers that carry the packet to its destination decide the path it should take at each hop. User choice in packet routing could provide the infrastructure needed to offer several new services on the Internet. Some new services I was able to think of include:

• ISPs could allow users to choose between multiple backbone providers and switch between providers at will. This could lead to increased competition among backbone providers as users become able to adjust their Internet plans dynamically based on price, quality of service, and other factors.
• ISPs could specialize in different QOS's related to voice, video, gaming, and other uses of the Internet for which standard TCP connections provide a less-than-optimal user experience. Users could then purchase standard Internet services using one route but purchase a different route for specific applications like video and voice conferencing or online games.
• Route choice could provide incentives to help ISPs transition to pay-as-you-go services. ISPs are currently struggling under the current unlimited monthly services model to remain profitable due to the uneven distribution of actual Internet usage among users. By allowing users to purchase from multiple different providers offering different QOS levels for different applications, users may become more acclimated to the idea of paying for the directly services that they use.
  

For me, the largest barrier to a technology such as NIRA succeeding in the current world is related to usability. Right now users don't have to think at all about the route their packets take throughout the Internet. If a new technology such as NIRA forces this choice on end users, then it must offer benefits that are significant enough to offset the new burden the technology places on them More likely, existing technologies like browsers and browser plugins would be augmented to make the choice intelligently for users so that they don't have to think about it beyond possibly an initial setup.

It's hard to tell from a superficial analysis how beneficial route choice would be for the growth of the Internet and for society as a whole, but it is an interesting feature to ponder new possibilities with.

Architecture Design Trade-offs

Most new networking designs have trade-offs; they offer new features and improvements but bring with them their own unique costs and caveats. It is little wonder then that agreement cannot be reached on how best to evolve the architecture of the Internet. The research paper on NIRA, a new inter-domain routing architecture, is one example of an Internet proposal upgrade. The proposal is elegant, relies on existing ideas and deployments like IPv6 as much as possible, and offers feature that could be useful for society. Specifically, the protocol aims to give users the ability to choose between available routes between a source and destination. As a side effect, it will also exhibit improved scalability relative to the existing inter-domain routing protocol BGP.

Of course, NIRA is not without potential flaws. First, it allocates IPv6 addresses in a specific way so as to limit other potential uses for the same address space. Second, it's protocol for communicating topology changes and user up-graphs has a per-message overhead linear with the number of domain-level links in a user's up-graph. Third, the network state a user must maintain is theoretically exponential in the depth of a user's up-graph. And last of all, if NRLS updates, analogous to DNS updates, are frequent they could also result in scalability issues as the Internet grows.

On one hand, the authors argue effectively that all of the above potential issues are unlikely to be realized in practice. On the other hand, the protocols of the original Internet also met their most important design goals, but at the same time have been stretched in ways their original authors never imagined. Is NIRA's added value important enough to integrate in the next Internet? Would its design weaknesses eventually become serious problems? As with the current Internet architecture, only time will tell!

The Lawmaker's Dilemma

Reading economic papers on network neutrality and discussing the issues in class made me to wonder how lawmakers manage to get anything done. The issues are deep, complex, and spans multiple fields including technology economics, and politics. As a computer scientist I have a fairly deep understanding of the technical issues behind net neutrality and the effects of such regulation on software companies and network providers from that perspective, but I admit ignorance on most of the economic arguments brought to bear by Yoo, Lessig, and others. Interestingly, in one Berkeley paper I read I found significant fault with several of the technical issues mentioned along with their interpretation in the debate.

A lawmaker with potentially limited understanding of the issues, or, more importantly, the ramifications of his or her decisions, seems to have no way of rendering a correct verdict given the conflicting views presented by different schools of thought on net neutrality. If the intellectuals can't come to a solid agreement, should lawmakers be expected to succeed where the experts have failed? To me, this foray into politics further strengthened my position that a government should seek to be as minimal as possible while ensuring the rights of the people. Net neutrality is too complex, the consequences of legislation too difficult to predict. Let a good strong economic engine flesh out the issues before executive action is taken.

More than Two Sides to Network Neutrality

After reading two different economics papers on net neutrality, I learned to my surprise that there are more than two sides to the network neutrality debate! From these two papers alone I saw three major themes in the debate, one favoring a free market and two involving very different kinds of regulation. The free market argument, led by Christopher Yoo at Vanderbilt, asserted that the currently proposed neutrality regulations would cause more harm than good by limiting the freedom of network providers to innovate, to differentiate themselves, and to absorb the congestion costs of the Internet. In effect this would hinder them from competing with one another and would reduce the incentive for companies to invest in network infrastructure. Furthermore, according to Yoo, price discrimination based on type of service requested would be the optimal strategy to control Internet usage in a way that benefits both providers and consumers.

On the opposite end, neutrality regulation advocates, as exemplified by Lawrence Lessiag at Stanford, have a strong opinion on how the Internet should work in that it should be a "dumb" pipe used to transport data between endpoints. Like other utilities such as highways and electricity, discrimination should not occur based on purpose or type of use, source, or destination, as such discrimination would greatly reduce the overall value of the Internet to society for the benefit only of the network providers. In order to prevent any such future abuses of network infrastructure, the government should intercede now by outlawing this behavior.

Lastly, Douglas Hass argued in 2007 that an analysis of the history of the Internet reveals that control over its direction has always been primarily dictated not by any national or local ISPs but by the purchasing power of users themselves. He gives a few high profile examples of attempts, perceived or real, at violating net neutrality and the backlash responses that have kept the Internet mostly in line. Furthermore because of how rapidly Internet technology has evolved, both at the infrastructure and application level, Hass believes we should not presume at this time to know what is best for the Internet in terms of neutrality. Instead, he advocates regulations that enforce transparency in the Internet services customers purchase, including transparency related to any kind of traffic discrimination a network provider might perform. This will allow users to be informed about their decisions and continue to drive the evolution of the Internet through their purchasing power.

Of all these opinions, I currently favor the last, although I now have a greater appreciation for the complexity of the issue. My biggest issue with the transparency approach is that it will be very difficult to define and enforce the regulations needed to ensure ISPs reveal all that they should about their network policies. However, if such transparency could be enforced, it alone would seriously regulate company behavior relative to neutrality simply based on the fact that their actions will be placed in the open for public scrutiny. Also, in the worst case, such regulation would reveal any glaring violations of net neutrality immediately as they occur, so that if more regulation is eventually needed it can be applied quickly and effectively.

As much as I admire the noble ideas of network neutrality, I also believe that the government already has its hands full regulating our selfish behavior as companies and as citizens. If unverifiable economic theory is the only proof of needed regulation, then perhaps it can wait until stronger proof is brought to light.

BGP is well-known for its faults. To me, it is interesting that the protocol is so different than TCP/IP, a protocol pair that has managed to scale so well as the Internet as grown. Using the deficiencies of BGP described in the paper "HLP: A Next Generation Inter-domain Routing Protocol", here a several ways in which the two protocol families differ.

- Scalability. TCP has scaled well as the number of users on the Internet increases because it has little to no intermediate state of interest to any other connections. TCP has had a difficult time scaling as available bandwidth and connection latency have both increased, but sender-only additions have been made to address this issue. BGP, on the other hand, doesn't scale as well. BGP routers must maintain state linear with the size of the Internet, and the number of globally visible state updates also grows linearly to the Internet size to synchronize this state.

- Convergence. TCP converges on one thing only: packet drops. Even though packet drops are related to a single piece of intermediate state, router queue size, the drop events themselves are local in scope, which greatly simplifies the transmission rate convergence process. BGP, on the other hand, as mentioned above, maintains a significant amount of global shared state. Furthermore, sender-side additions to TCP have greatly increased its ability to converge more rapidly to a healthy transmission rate, whereas no such improvements have been made to BGP.

- Fault isolation. Because of its initial use for military communication, the TCP/IP stack was designed to continue to operate in the face of local failures through the means of storing state on the ends. BGP, on the other hand, frequently requires global state updates to handle local faults.

Overall, the primary difference between the two protocol families is that one keeps all of its state on the ends and the other keeps complex state at the core of the Internet. While this analysis may not lead to improvements in BGP or inter-domain protocols, it is interesting to compare the two types of protocols to help understand the origins of BGP's current flaws.

Practical Routing Research

A while ago I shared a single Internet connection between 3 different apartments in a complex. However, I found that most of the time I only received a small fraction, less than 1/100th, of the advertised bandwidth for the link. We eventually figured out that 1 of the three apartments was doing something to consistently steal the majority of the bandwidth. I had no idea how they were managing to do so, but I decided to try to research and see if there were any fairshare enforcement policies that I could turn on with the home router that we were using. Unfortunately, I wasn't able to find anything. I couldn't figure out if I simply didn't have the right search terms or if home routers didn't in general support such a feature. It seemed like an easy thing to do; simply maintaining some address or connection-based state and ensure that all connections receive an equal share of the available bandwidth.

Having had the above experience, I was very happy to read the research paper "Promoting the Use of End-to-End Congestion Control in the Internet". Although the main point of the paper is to introduce new mechanisms for inducing end-to-end congestion control through incentives, the article also discusses the core principles behind Internet fairshare. As the paper explains, there are two ways a connection can obtain more than its fair share of bandwidth. First, it can ignore the rules of congestion control. An example is any application that communicates through UDP. Second, the application can open multiple connections to perform the work of one connection. For instance, if all three apartments were using the network simultaneously but the application in one apartment opened up 10 connections simultaneously, then that apartment would obtain about 83% of available bandwidth. Some routers do implement per-flow scheduling using techniques such as weighted round-robin, but they are only guaranteed to work on a per-hop basis.

With the understanding I gained from the paper I am now better equipped to handle a similar problem in the future. I have a better background needed to choose the appropriate search terms to figure out if my router supports the relevant features. Furthermore, I would be better equipped to analyze packet traces on the network to determine the cause for the drop in bandwidth for two of the three apartments. While learning these things may not have been the main objective of reading the paper, it was still very enjoyable to associate what I was learning in class with solving problems I've had in real life.

Renaissance of TCP's

Will we one day reach a point where TCP algorithms are so varied and specific that TCP streams could flexibly adapt to connection-specific conditions and applications could decide what kind of TCP protocol they want and when? After learning in class about the variety of modifications and additions proposed to TCP over the past decade, it almost seems natural to evolve TCP in that direction.

For instance, certain algorithms like SCTP or HSTCP were designed to handle a specific scenario like efficient bandwidth utilization on long fat links, but were shown to perform unfairly in more standard usage scenarios. In a more dynamic TCP environment, a TCP implementation could adapt itself to measured conditions like high RTT and low congestion and switch congestion avoidance algorithms entirely and completely transparently to the client application.

Another use case of dynamic TCP could be application-driven TCP. As an example, authors in one paper we read claimed that the current implementation of TCP is not optimized for P2P applications. We also read of another algorithm specifically designed for the data center. If an application was allowed to select per-stream protocols, they could then choose the algorithm that best suites the needs of the application itself and the data it is sending. As a further possibility, an application, when installed, could install a new version of TCP that it prefers in some or all scenarios.

This flexibility and ubiquity of TCP opens up many issues related to fairness, correctness of implementation, efficiency of dynamic algorithms that generate metrics an application can respond to, and so on, but they also open up the possibility for a much more flexible transport layer that could adapt to the needs of individual connections or applications, which may help improve overall connection efficiency on the Internet.

Compound Ideas

The paper A Compound TCP Approach for High-speed and Long Distance Networks describes a novel TCP algorithm to utilize high speed and long-delay networks more efficiently while maintaining inter- and intra-protocol fairness. For me, the most interesting part of the paper is the build-up from the "previous work" section to the section describing the new algorithm itself. Through the two sections one learns that the paper's novel contribution is simply the combination of existing ideas in new ways. More specifically, compound TCP basically combines HSTCP, an aggressive loss-based congestion control algorithm, with delay-based information very similar to that used by the Vegas and Fast TCP algorithms. Even more interestingly, CTCP isn't even the first to combine the two approaches; TCP Africa also attempted a similar strategy. Yet, despite the apparent simplicity of CTCP relative to previous work, it apparently improved on existing approaches enough to become a standard available option new versions of windows. To me, this paper serves an excellent example of incremental evolution in the research community.

The Past and Future of Internet Research

As I've spent time studying pieces of the Internet research literature I've been surprised that the majority of it has been entirely based on empirical observation, and in the infancy of the Internet, observation on live systems. For instance, congestion avoidance algorithms came about after an episode that caused a portion of the network to drop its throughput one thousand-fold. Van Jacobsen, a noted researcher and the owner of an affected segment of the network, decided to analyze and fix the problem through a hands-on debugging session. Although it appears that over time people have began to use simulation software to test hypothesis more rigorously before deployment, these tests are still inherently observation-based.

This style of research contrasted greatly with that of Feng and Vanichpun on TCP Vegas. In their 2003 research paper they construct a mathematical model of Reno and Vegas connections competing with one another for bandwidth. With this model they could predict the probability that a particular packet would be dropped, the average window size and queue size of a connection, and most importantly, the ratio of throughput of the two connections. Using this model they were easily able to tweak Vegas parameters to cause the two connection types to be fair with one another, something that no one had accomplished previously. The empirical experiments that followed simply served the role to verify the correctness of the model. If the researchers did not perform this rigorous analysis of the two connections, they would have had only brute-force methods at their disposal to try to discover an optimal parameter set for TCP Vegas.

Because of this paper I believe that continued progress on Internet architecture research will become increasingly reliant on constructing such models and performing such analyses. Distributed concurrent autonomous systems are inherently complex and The Internet itself continues to grow in complexity over time. Discovering models that allow us to predict and understand aspects of this system more thoroughly will enable us to discover new ideas we would otherwise be unable to find.

TCP Algorithms and Test Suites

The story of TCP Reno and TCP Vegas could easily be used as a poster story for the test-driven development camp. TCP Reno implemented an at-the-time new technique for quickly recovering from transient network congestion called fast recovery. However, after people were already convinced to implement and deploy TCP Reno on hosts around the world, researchers discovered a flaw in Reno that resulted in significantly poorer performance than TCP Tahoe, its predecessor, when a consecutive sequence of packets were lost simultaneously.

TCP Vegas, on the other hand, suffered from a related but different problem. The authors of Vegas made claims of serious performance increases to the Internet if their new algorithms were implemented and deployed. Unfortunately, because Vegas was so different in its approach many people had a difficult time believing that these performance enhancements would be observable in a production system. Furthmore, many worried that Vegas would cause currently unforeseen problems with the Internet if deployed and might not play well with existing TCP implementations.


Both of these stories may have had a happer ending if their were a large suite of test cases that any new TCP algorithms or enhancements could be tested against. These test descriptions could be ran on either simulation software, partially-simulated environments, or real hardware. These tests should be broad enough to cover all of the common traffic patterns found on the Internet as well as important edge cases that an algorithm must handle to be sufficiently robust. Furthermore, tests could be used to determine how a new TCP algorithm interacts with existing deployed solutions. Lastly, the test suite would provide a common ground for researchers to communicate with. Not only could a researcher both verify for himself and others the validity of his or her new ideas, but if more questions or concerns arose then the test suite could simply be extended with new tests that explored these concerns.

Having a suite of tests has proved invaluable for many core infrastructure technologies just as compilers. Applying such a philosophy to what is quite possibly the most important infrastructure in the world should lead to increased productivity in researching new ways of improving TCP.