David Clark, et al. (the ubiquitous Al, a guy who really gets around, a true multidisciplinarian) wrote a paper called “Tussle in Cyberspace: Defining Tomorrow’s Internet”.

One of the tussles that define the current Internet is the tussle of economics. The providers of the Internet are not in the business of giving service away. For most, it is a business, run to make a profit. This means they are competitors, and look at the user, and each other, as a customer and a source of revenue. Providers tussle as they compete, and consumers tussle with providers to get the service they want at a low price.

How can we, as engineers, shape the economic tussle? In fact, we have great power to shape this tussle, but first we have to understand the rules that define it. A standard business saying is that the drivers of investment are fear and greed. Greed is easy to understand—it drove hundreds of billions of dollars worth of investment in telecommunications over the last decade, much of which now [2002] sits at risk of bankruptcy. But fear is more subtle. The vector of fear is competition, which results when the consumer has choice. The tussle among providers and consumers in a competitive landscape is the most basic attribute of a marketplace. Most economists of a “western” bent would argue that competition is good: it drives innovation, disciplines the market, insures efficiency, and removes the need for intervention and regulation of a market. To make competition viable, the consumer in a market must have the ability to choose. So our principle that one should design choice into mechanism is the building block of competition.

A year later, Clark followed up with a paper that altered our understanding of end-to-end design principles. In it, he said:

Perhaps the most radical idea from this analysis is that the simple, end-to-end transparency model should be replaced with the more complex idea of controlled transparency. This implies active elements in the network, which in turn implies a tussle over who controls these devices. It also implies that we need to specify what impact these devices have on the semantics on which the applications depend on.

Subtle stuff.