Papers on the Evolvability of the Internet Infrastructure:

Related web pages:
Papers about Research Questions for the Internet.
References on Layering and the Internet Architecture.

Topics so far: Case Studies, Addressing, DNS, Evolution, IPv6, Middleboxes, Multicast, QoS, Routing, Security, Transport, Web, Other.

Case Studies:

These changes-in-progress can be thought of as case studies in the evolvability of the architecture:
• IPv6.
• IPsec.
• MPLS?
• Multicast.
• QoS (intserv or diffserv).
• telephony over IP.
• Tranport-related changes:
  ECN; changes to TCP; SCTP; TFRC and equation-based congestion control.

Addressing:

• Dave Plonka, "Embedding Globally Routable Internet Addresses Considered Harmful"
  
  • "What does this unintentional Denial-of-Service flood indicate about the viability of some public Internet services?"
  • "Can the Internet routing infrastructure be improved to enable less disruptive solutions to such problems?"
  • "Are incidents such as this a likely side-effect of ubiquitous, low-cost, perhaps even disposable Internet hosts?"

DNS:

• John C. Klensin, Role of the Domain Name System, draft-klensin-dns-role-01.txt, 2001, internet-draft, work in progress.
  "Protocols tend to be deployed at a just-past-prototype level, typically including the types of expedient compromises typical with prototypes... Applications that are "almost good enough" prevent development and deployment of high-quality replacements." - Section 1.4.
  Section 2, "Signs of DNS overloading": "The DNS is becoming overloaded (semantically if not in the mechanical ability to resolve names)."

• Randy Bush, Are We Overloading the Saddlebags on an Old Horse?, IETF, San Diego, December 2000.

Evolution and Deployment:

• D. Thaler and B. Aboba, What Makes For a Successful Protocol, internet-draft draft-iab-protocol-success-01.txt, work-in-progress, November 2007.
  "The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success."

• Mark Handley, Why the Internet Only Just Works, BT Technology Journal, July 2006.
  "To conclude, in many ways the Internet only just works. The number of ways in which it only just works seems to be increasing with time, as non-critical problems build. The main question is whether it will take failures to cause these problems to be addressed, or whether they can start to be addressed before they need to be fixed in an ill co-ordinated last-minute rush."

• Mark Gaynor et al., The Real Options Approach to Network-based Service Architecture, HICSS 2001
  "Our model shows the value of a two-tiered structure: the outer layer allowing easy experimentation acts as an incubator, the inner layer allows market selected successful experiments to migrate into the most effective way to manage the chosed service."
  "It is important to understand how and why the Internet has been so successful in creating services that meet market need.... Understanding the past will help us understand the implication of current important architectural effectors that break the e-2-e paradigm."

• Lawrence Lessig, The Internet Under Siege, Foreign Policy magazine, Nov.-Dec. 2001.
  ``The Internet promised the world-particularly the weakest in the world-the fastest and most dramatic change to existing barriers to growth. That promise depends on the network remaining open to innovation.''

• David Reed, The End of the End-to-End Argument, April 2000.
  "In many areas of the Internet, new chokepoints are being deployed so that anything new not explicitly permitted in advance is systematically blocked."
  "I would argue that we need more than ever to understand [the end-to-end argument] and to apply it as we evolve the network... Future potential is hard to visualize, but our inability to make out the details should not justify locking the doors against new ways to use the network."

• Walter Willinger and John Doyle, Robustness and the Internet: Design and Evolution, March 2002.
  "The objective of this paper is to provide a historical account of the design and evolution of the Internet... We argue that .... anyone interested in the Internet should be concerned about complexity, robustness, fragility, and their trade-offs."

  David Meyer's web page on Some Light Reading on Complexity and the Internet has pointers to more papers in this area.

• Jim Gray, Distributed Computing Economics, IEEE TFCC Newsleter, July 2003.
  "Computing economics are changing. Today there is rough price parity between (1) one database access, (2) ten bytes of network traffic, (3) 100,000 instructions, (4) 10 bytes of disk storage, and (5) a megabyte of disk bandwidth. This has implications for how one structures Internet-scale distributed computing: one puts computing as close to the data as possible in order to avoid expensive network traffic."

IPv6:

• IPv6, Transition Mechanisms, 6Bone.

Middleboxes:

• K. Moore, Recommendations for the Design and Implementation of NAT-Tolerant Applications, internet draft, draft-moore-nat-tolerance-recommendations-00.txt, 22-Feb-02.
  "It is the focus of this document to provide recommendations to authors of new protocols about the effects to consider when designing new protocols such that special handling is not required at NAT gateway points."

• D. Senie, Network Address Translator (NAT)-Friendly Application Design Guidelines, RFC 3235, January 2002.
  "While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation)."

Multicast:

• MBONE Deployment Working Group.

• S. Bhattacharyya et al., An Overview of Source-Specific Multicast(SSM) Deployment, draft-ietf-ssm-overview-02.txt, internet draft, work in progress, 2001.

• C. Diot at al, Deployment Issues for the IP Multicast Service and Architecture, IEEE Network, January/February 2000.
  "We examine the issues that have limited the commercial deployment of IP-multicast from the viewpoint of carriers."

• P. Sharma and R. Malpani, IP Multicast Operational Network Management: Design, Challenges, and Experiences, IEEE Network, March 2003.
  "The lack of appropriate network management tools for IP multicast has proven to be a major barrier to its deployment".

QoS:

• Gregory Bell, Failure to Thrive: QoS and the Culture of Operational Networking, LBNL, September 2003.
  "Understanding the culture of operational networking can help to illuminate the question of why QoS has floundered. Network administrators have a well-founded aversion to complexity, in part because they experience failures attributable to design complexity on a regular basis."

• Brian Carpenter, Kathleen Nichols, Differentiated Services in the Internet, Technical Paper, February 2002.
  "This disregard for the administrative boundaries of networks flaws all four approaches listed above" [referring to IP precedence and TOS, IBM's SNA (Systems Network Architecture), the Internet Stream Protocol (ST), and Integrated Services].

• G. Huston, Next Steps for the IP QoS Architecture, RFC 2990, November 2000.
  Section 3.12: "How does the widespread deployment of service-aware networks commence? Which gets built first - host applications or network infrastructure?"

Routing:

Security:

• Ross Anderson, Why Information Security is Hard - an Economic Perspective, 2001.
  "The management of information security is a much deeper and more political problem than is usually realized; solutions are likely to be subtle and partial, while many simplistic technical approaches are bound to fail. The time has come for engineers, economists, lawyers, and policymakers to try to forge common approaches."

Web Caching, Content Distribution, and Middleboxes:

• B. Carpenter, Middleboxes: Taxonomy and Issues, RFC 3234, Informational, February 2002.
  This document does not directly discuss the ways that middleboxes both enable and hinder the evolution of the Internet architecture, but it lays down the terminology as a first step.

Other:

• David D. Clark and Marjory S. Blumenthal, Rethinking the design of the Internet: The end to end arguments vs. the brave new world, August 2000.
  "This paper looks at the Internet and the changing set of requirements for the Internet that are emerging as it becomes more commercial, more oriented towards the consumer, and used for a wider set of purposes... We argue that the open, general nature of the Net, which derived from the end to end arguments, is a valuable characteristic that encourages innovation, and this flexibility should be preserved."

• Agile Internet Evolution?
  L. Williams and A. Cockburn, Agile Software Development: It's about Feedback and Change", IEEE Computer, June 2003.
  "The Manifesto for Agile Software Development describes the four comparative values underlying the agile position:
  
  • individuals and interactions over processes and tools,
  • working software over comprehensive documentation,
  • customer collaboration over contract negotiation, and
  • responding to change over following a plan."