Monday, September 13, 2010

Tussles on the Internet

David Clark et al. wrote a paper in 2002 called Tussle in Cyberspace: Defining Tomorrow's Internet. This paper, which is related to the idea of an invariant that I mentioned in an earlier post, has even more relevance today than when it was first published. Beginning with, "The Internet was created in simpler times", the paper reminds us that our networks will reflect the conflicts from our society. Competing interests will always result in some sort of conflict, and technology cannot dictate the end results. The paper recommends that architectures be designed with enough flexibility to avoid breaking under social tension.

For example, "conservative governments and corporations put their users behind firewalls, and the users route and tunnel around them. ISPs give their users a single IP address, and users attach a network of computers using address translation." The thought of firewalls and tunnels may make designers cringe with images of trenches in wartime, but the more they try to protect their protocols from being used for evil purposes, the more these designs will be defiled. As stated by the authors: "Do not design so as to dictate the outcome. Rigid designs will be broken."

The authors try (rather pitifully) to keep a neutral stance about the many ongoing struggles on the Internet. However, they eventually break out of character and give a chapter on how to keep the Internet innovative and reliable in spite of these tussles. Their recommendation is to "bias the tussle" with open architectures, fault-tolerant designs, and encryption.

Although the outcome cannot be dictated by the designers, I agree that open designs may occasionally succeed at motivating reluctant parties to allow openness. One example that I thought of during my reading is open source software (particularly under the GPL), which is often more expensive to fork than to contribute to. This effect increases with the activity and usefulness of the project. Biasing outcomes is extremely difficult to pull off, but sometimes it works.

No comments:

Post a Comment