Network Neutrality and flow rate fairness

If knowing my stance on Network Neutrality is really important to you before you read further along, I would like to state that I am against Network Neutrality, I think US broadband can do much better and I blame the government for the situation we are in. I don’t think Network Neutrality will help get rid of any of our broadband problems.

The Internet has been a major force in shaping the economies and culture of the world around. So much that its no more seen as a luxury but an essential medium of communication. Given its importance, its not a surprise that Network Neutrality legislation is being pushed (or at-least has been a subject of debate). Very briefly, the aim of Network Neutrality is to avoid any kind of discrimination between application traffic on a network. Any application provider on the Internet should be treated the same way as another. While such is the aim, the way Network Neutrality legislation seems to be moving forward is to regulate ISPs in a similar manner as Telecoms. ISPs will need to honor “fairness” between applications and will have to adhere to standard basic protocols for managing traffic on the Internet.

Note that the definition of Network Neutrality are as numerous as the proposals for solving it and a fairly good amount of information can be found on the Wikipedia page linked above. Basically, I see the following two opposing forces:

For Network Neutrality: The telecoms and cable companies have a virtual monopoly on the cables they have laid on our land and have been granted huge subsidies by the government to ameliorate the initial investment into basic networking infrastructure. We think that treating Internet applications “fairly” is important to our economy and hence we have the right to claim that from them.

Against Network Neutrality: The problems in Internet technology are far from being solved. There are widespread issues with security on the Internet. There is little incentive for the broadband companies to give us more security or bandwidth — escalating costs of bandwidth will retard the adoption of High Definition media. Unless we give the ISPs more control over their traffic, they claim that they can’t even solve fundamental fairness issues between applications going through a heavily loaded network leave alone other problems with Internet technology.

Before we move on, let me ask you a quick question. What do you think is the protocol that runs on Internet Links? Your first guess may be IP, which is the protocol which everybody on the Internet has to use to communicate. However, that’s not quite true. When packets move over links, its generally wrapped in a Link Layer Protocol. There are many technologies used below IP they will continue to evolve as technology improves with time. Its important, however, to note the resilience of IP which can run on such a variety of technologies with very small number of changes. These days, IP runs over Ethernet, Fiber Ethernet, SONET and Wireless (WiFi, 3G etc). A large number of “management” protocols run between the Link Layer and IP for performing other functions. In many instances, these protocols are not seen separately from Link Layer — in other cases they are. A good example here is MPLS which is traffic management protocol layer used heavily in ISPs. The evolution of technology below the IP layer is very important to sustain the growth of the Internet. Then there are other protocols or protocol extensions to IP which help in bringing more applications on the Internet or make their deployment cheaper. The reason why the Internet works round the clock is because of massive investment in innovating and standardizing infrastructure protocols. A lot of this is driven by the academia and the industry working together. IETF is an important body which helps in this co-ordination.

My basic point it that we are not helping with the evolution of the Internet if we don’t create the right incentives for people to work on these. We can’t just leave the academic community provide us solutions for mounting challenges in Internet technology. In most cases, academia is least interested in costs of operation and ISP business model opportunities on the Internet. It is very uncertain where the drive for this evolution will come from if we regulate the Internet. The bet is between a public body in-charge of Internet technologies or market forces shaping its evolution. I (subjectively) favor market forces in this case.

The recent ruckus over P2P and fair bandwidth usage illustrates the above point very clearly. The academic community has for a long time considered their solution to “fair” bandwidth allocation between applications sufficient for the purposes of the Internet. Very recently, it has been shown that such a model may not be actually good for a practical Internet. The paper “Flow Rate Fairness: Dismantling a Religion” brings out this point very clearly. It shows how the current TCP/IP way of doing networking has very skewed way of looking at fairness. Fairness is also a highly debated topic in the networking community and it definitely seems to be enough complicated for businesses do discard it all together for their operational purposes. It seems that the Industry lagged behind a bit in reminding the IETF of the problems it would begin to face if they continued with the currently prevalent fairness model.

This brings me to the other point:
If we force Network Neutrality on the ISPs then besides not having an incentive to contribute to the evolution of Internet technologies, they will be forced in a way of doing traffic (the current TCP/IP) which is far from the optimal way of operating on a network. We will leave them with a technology mess to deal with under restrictions that they cannot change it. This will cause application makers to work around it for their own good. ISPs will have little power to do anything against that once they operate under regulation. In a sense, the problem of ISPs discriminating between applications will move to some applications discriminating against others. Currently, bittorrent unfairly gets more than its share of resources from other applications by exploiting the fairness system in TCP/IP. The battle will move upward in the application layer and every application maker will want to use bittorrent like features. What’s worse is that some applications (VoIP) will suffer very badly from applications like bittorrent and they will have no way to survive in a regulated ISP world. The only way out is more regulations on applications and application behavior on the Internet… and given that, you can kiss good bye to any new applications coming on the Internet in the same way you kissed good bye to making the Internet efficient in moving data around once you regulated the ISPs.

I think that at the core, there are two problems we need to tackle:

1. If the Internet is so important for us then the government should own its basic infrastructure. It should provide via leases and contracts for any upgrades to services on it and should monitor its health. It should be able to terminate a business’ hold on the property if it feels that its not doing its job properly in maintaining it and providing services on it. In other words, it should be more like US roads or other public amenities. I really think that no government in its sane mind should give its entire property to one company to manage. That would make that company too powerful and destroy the balance in this scheme. Local areas should be able to choose their own businesses to run their own networks. If the public feels that a basic set of services on the entire network is important for the economy as a whole then the government should obtain a license for the technology and release it over the network using contractual services from businesses willing to do the work. The revenue for these businesses could come from the government and/or the consumers. The academia can also contribute technologies.
2. We should leave it to businesses and market forces to come up with a definition of “fair” using actual costs. As any business is free to run whatever it wants over the network (provided it pays for the resources) how it actually manages its costs while providing the service should be left to the business alone. If prioritized VoIP traffic is under high demand then the supply demand curve can appropriately fix an optimum price for the cost of prioritized traffic on the network. We should definitely not regulate traffic priority or regulate companies which are willing to provide us a way to do it in a better way. Note that its the job of the government to make sure that there are no monopolies in this schemes, which should be easy given the ownership of the physical infrastructure. Again, if there is public interest in a particular notion of “fair”, then the public (the government) should pay to nudge the market to a different demand supply point. Note that I am more hopeful about an evolving notion of actual operational cost on the Internet than a (contrived) notion of fairness.

I hope that I have been able to at-least convince you that the problem is not about “fair” Internet access but is more about who owns and encourages development on it.

Patch based inheritance: The revenge of the dynamic and unorganized

Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn’t.

Quite similar is the story of programming and programming languages. For the past many years now the landscape of programming languages has been the following:

Fiction (or what people predicted would be the next generation): Program Verification, Static typing and type checking in “enterprise” level code and Statically typed Object Oriented language design.

Truth (or what has come to be the reality now): Runtime type safety, No static type checking in the program, dynamic and less verbose programming languages, “enterprises” which move quickly to these languages seem to gain huge productivity from programmers.

The advent of scripting languages into the mainstream has proven beyond doubt the world of programmers would favor “no types” than “better types”. In most cases, type systems generally come in the way of programming than assisting it — especially in environments geared towards rapid prototyping.

I kind of feel the same about OO programming too. Especially the inheritance aspect of it. This is beyond static type checking. I feel constrained when I am asked to extend the functionality of a class by just overriding its methods. Sometimes I would really like to change the behavior of a method very slightly… not exactly accomplished by overriding (and mostly rewriting it). In some cases it can be achieved by dividing the original method into smaller parts and overriding one of them… but by then the interfaces are laid out and the damage has already been done. In other cases, even this approach fails.

Many OO advocates pride themselves in carving out the correct set of interfaces such that the problem above really never occurs in practice. While I surely don’t doubt their skills, I still think that a very large fraction of programmers (may be close to all) have come across instances when even after carefully laying down interfaces, future evolution of the software didn’t exactly follow.

So here’s a somewhat radical idea. What if we forget inheritance the way we know it? Lets assume that we are operating in a dynamic OO language. The inheritance is based on the concept of a patch (just a regular diff between similar lines of code). To derive from a parent class you copy the source, change it according to your needs, rename the class adding a dependence declaration pointing to the parent and take a diff of the body of the derived class with respect to its parent as its source code. Upon compilation, the compiler uses the parent’s source code to dynamically generate the derived class’ source code and then compiles it.

This approach does come with advantages which I will argue are beyond traditional inheritance. The derived class now has the potential of changing the behavior of the parent in any way it feels. The process of derivation from another class is now truly “dynamic” (in the sense of — left to the programmer, the language and the compiler get out of the way). This advantage IMHO is a huge win. It is not necessarily more fragile than normal class inheritance. In both cases changing the parent class in some way may or may not conflict with the derived class. The compilation itself becomes simpler because implementing this is almost as simple as applying patches. The patch application test serves as a sanity check similar to the checks with inheritance (non conflicting member variables, etc).

Another advantage of this approach is that we have now really made inheritance and polymorphism orthogonal to each other. Previously, the derived class included the parent class’ signature in it. It contained all its methods and member variables and the public ones would be accessible. Thus, even though inheritance could allow you to re-use a class and completely change its behavior, the fact that the parent’s methods are still accessible made that logically inconsistent. Think of a Queue class which supports enqueue and dequeue at both the head and the tail. Its perfectly fine to derive a Stack class from it which just has push/pop. Its implementation involves using the Queue’s enqueue and dequeue at either the head or the tail for the push/pop operations but very importantly, also changing its interface to push/pop! This is not possible with traditional inheritance but is possible with patch based inheritance.

I hope I have atleast convinced you that prevalent OO programming is not exactly a good way to program.